Today we delve into the world of Application Programing Interface or “API” security. These interfaces are typically used to share information between applications, such as a CRM like Salesforce and mobile applications that your sales team may want to use. These are sets of tasks and instructions prebuilt into Salesforce that you can ‘call’ to present data on the phone. APIs are used everywhere – even if you don’t know it. If you are writing an application that will run on Windows, you are often making API calls to perform functions. As cloud and mobile computing continue to grow, API calls become more prevalent and more critical.
Consider where APIs may be in use within your organization. Do you think there may be regulated and sensitive data in the CRM that you need to secure and protect? Likely some of the APIs in use today go right to the heart of the most critical data you have. So how do you get the functionality, yet keep the data secure?
First, you need to monitor your APIs. In traditional applications, we would put a firewall on the perimeter and put a limited exposure of the app in a DMZ, then limit that to only certain ports or services to delve into the data. With APIs that whole architecture is turned on its head. These API calls come straight into the heart of the data. So rather than think of it as traditional security, we need to look at it like code. We need to monitor the code for flaws (like those covered by the OWASP top 10) and also monitor the transmissions looking for injection attempts and brute force attempts.
Next, APIs should use strong authentication. Since common authentication methods like password-based and biometrics authentication cannot be used in machine-to-machine environments, the technologies to consider include cryptographic authentication, challenge-response, and one-time password (OTP). The task gets even harder when the API is between the backend and mobile devices. Native mobile apps present non-browser environments. No cookies, custom protocols and encodings, different sockets management like keep-alive are supported. Furthermore, clients’ devices are completely different, ranging from cheap Android phones to the latest generation iPhones.
Normal API traffic is automated, therefore the attacks are also automated. In the old days of web apps, we just tried to identify and block ‘bot’ like behavior. With APIs the behavior is bot-like by design and the challenge is to determine a good bot from a bad bot without degrading performance of the good bots. You might think the answer is to just look at the payloads and make a “good/bad” decision, but unfortunately because of the complexit,y many ‘good’ calls look like what we would traditionally look like attacks due to the nature of how many calls must be encoded.
With all these challenges what CAN you do?
First of all planning your API architecture with security in mind is critical. There are numerous API gateways and engines that help monitor and examine the traffic making API calls. Companies like OKTA and SALT are examples, but there are many more. And then assimilating these products into our monitoring, alerting and incident response programs. Don’t forget the human, we as cyber defenders must be learning all the time. It’s easy to see why all of us in information security need to learn, or at least understand, coding because infrastructure is turning into code more and more.