Application programming interfaces, or APIs, enable applications to exchange data and functionality easily with other applications and users in or outside an organization. Examples of APIs you may be familiar with are travel sites with pull-in information on reservations from various sources, IoT applications that allow your phone to talk to your refrigerator and Google maps pulling in location information.
They are quickly becoming common because of the benefits and convenience they offer, and as such are also becoming favorite targets for hackers. A recent survey from Cloudentity noted 44% of surveyed organizations experienced considerable security issues with APIs including data leakage and exposure of private information. To add fuel to the fire, studies also found that organizations are not confident in their ability to properly secure APIs (only 2%), attacks are significantly increasing (up to 6x over a year of study), and demand for API programming continues to grow. No doubt these trends are the reason the FFIEC has included guidance on API development security and management in the new AIO booklet.
If you are considering APIs to enhance your integrations or mobile services, please consider the following advice to build in these controls prior to go-live:
- Build in zero trust as the principle of securing significant APIs: I know this is a big ask given all the distributed types of platforms, users, and information involved. Zero trust means we have no automatic trust of any user, site, computer, service, or provide any data element without proper authorization. So, if this API is critical to your operations or handles NPI, this upfront effort will pay dividends in the future to prevent breaches and outages.
- Identify and manage vulnerabilities: This seems straightforward, however, somehow vulnerability management keeps showing up in the articles and studies I read. For example, Cloudentity’s study states that broken object level vulnerabilities are responsible for exposing tens of millions of records and their associated personally identifiable information. So, do that penetration test prior to going live and identify and mitigate vulnerabilities continuously afterward.
- Validate Input: In an API, information is requested and distributed so input is going to happen from a variety of sources and users. It is important to define what is a valid request and limit acceptable requests to just that. Anything not matching a valid request should be dropped and not passed along. This basically ties back to the old web application vulnerability, cross-site scripting (XSS).
- Limit the data available to only that which is necessary: This means not only limiting the data available via the API, but also mitigating those pesky vulnerabilities which show system backend software versioning as it gives the hacker an express lane to available vulnerabilities. This means also limiting data by user going back to that zero trust and the good old principle of least privilege.
- Limit the rate of requests allowable: Flooding and/or distributed denial of service attacks occur when a hacker simply sends an unmanageable amount of requests from single or multiple sources in an effort to take down the service. Being prepared by rating these to a manageable level and dropping the rest of the requests will prevent outages caused by these types of attacks.
A great way to ensure you have the proper controls and mitigations in place is to perform a risk assessment prior to go-live. Examiners are beginning to look for these ahead of your annual risk assessment so performing one ahead of your API deployment is a great idea. Here’s a previous blog post to help refresh your memory: The Regular Risk Assessment Revolution.
If you need help with your risk assessment, please contact us at support@bedelsecurity.com.
Sources:
https://www.darkreading.com/vulnerabilities-threats/api-security-issues-hinder-application-delivery