Page 5 - Campus Technology, May/June 2018

SPONSORED REPORT |
SECURITY AND THE INTERNET OF THINGS
GAMECHANGER
HARDEN YOUR APIs
RETHINKING HOW TECHNOLOGY IS USED IN EDUCATION
Attackers increasingly seek entry into organizations that don’t protect their API endpoints.
APPLICATION PROGRAMMING interfaces (APIs) are highly effective shortcuts for apps to quickly get the re- sources they need to run smoothly. And just as any such doorway should be locked when nobody is around, so too should APIs be secured to prevent opportunistic break-ins.
The typical app is no longer a monolithic program. It’s a set of micro-services that handle different aspects of the job. Every time a student requests an Uber ride or posts a Snapchat from a mobile device, an API is there to handle the mission-to-mission communication. And according to secu- rity experts, each one represents an attack surface.
So where do the vulnerabilities exist in the API scenario? Let’s start with the protocols. Most communication between a client application and the API service uses one of two lan- guage-neutral formats as containers for the messages being exchanged—JavaScript Object Notation (JSON) for RESTful- based APIs and XML for SOAP web services. Data requests to these APIs must often be accompanied by an identifier, such as an API key or authentication token.
If these keys are the same on both the encryption and
decryption sides, are commonly known, or are stored in the application in some obvious way, hackers can exploit them to intercept the API transaction and manipulate or reveal confi- dential information. Avoiding this type of “man-in-the-middle” attack requires asymmetric encryption, in which different keys are used to encrypt and decrypt.
Then there’s the issue of excessive API calls or slow POST requests, both of which can generate a flavor of distributed denial-of-service attacks by overrunning the capacity of the application server. Any security service in place to prevent too many calls going to common web domains needs to also scrutinize the number and pace of requests heading to more obscure API server domains.
A third problem area is weak authentication and authoriza- tion processes for confirming users, parameters, and tokens. If the API can’t tell who’s a legitimate user and who’s a fake, a cybercriminal could virtually take control of a given API to wreak havoc.
That’s what a software developer in Norway did purely as a test. He was learning how to hack his own applications in
a security class and peered into APIs for his Nissan Leaf. He realized the API was providing access anonymously, but passing back personal information, such as the vehicle ID number. By manipulating VIN information, a hacker could tar- get a Leaf anywhere in the world for remote charging, climate control, and to uncover the number and distance of trips. If the car allowed for remote unlock or start, like some vehicles do, the results could be disastrous. The best approach is to authenticate as if nothing going into or coming out from APIs is to be trusted.
The right kind of security solution treats APIs like any other kind of endpoint. It helps the organization control how the API should be used, recognizes and protects the unique proto- cols of APIs from web attacks, and provides reporting to help security professionals see how and where the campus com- munity is using the APIs.
APIs aren’t going away. They make life too convenient for that to happen. IT leaders at smart campuses are realizing they need to incorporate protections to address this special form of lockdown into their security planning.