Why is API Security So Hard?

When I was a software developer and the Head of Automation, our goal was to integrate everything. Build API's where they didn't exist and integrate systems, where we quickly learned "not all api's are created the same.. and sometimes the API we were provided were a "hack" at best.

What is an API - An API (application programmatic interface) means any application interface which is created for the purpose of "integrating" systems so they can pass information one-way or bi-directional.

Challenge #1 - Not All API's are the Same - Resulting in Inventory Challenges

MANY OPTIONS TO CREATE AN API

• Web or Network Sockets - Ports to communicate (UDP,TCP)
• URL based connections - Web Services - Soap, Rest
• Database connections - Inserts, Stored Procedures
• File interactions - Creating files, modifying existing files, moving files
• Message buses - Sending messages such as Kafka, MQ, Tibco, etc
• Status Changes - Scheduled jobs complete, updating the status to trigger a process
• Web Interface - Sending form based submissions to mimic a user. POST/GET
• Robotics - Moving the mouse and keyboard to mimic a user. This can be very problematic as it is like automating flying a plane with almost no sensors. So it is almost like flying a plane blind.

For each interface you need to think about how to interact with it, what can break over time.

Challenge #2 - API's were Not Always Built in the Initial Application Design

• Older application typically were not built with API's in mind, which means that "what you expose" and "how you expose it" can be done in a variety of ways making it harder to secure.

- Web Integration - Can be exploited with bad input and special characters

- File Integration - Can be exploited if humans gets access to the system

- Message Integration - Can be exploited with a denial of service attack

• Newer applications - More applications are providing API's where the common phrase is "eating your own dog food" which means developers are building api's and then using their own api's to build the rest of the application. The benefit being less maintenance and when you add a feature it can be used in the frontend and backend.

- The disadvantage is an API that you NEVER want used

Challenge #3 - Conflicting Requirements - Speed vs. Agility vs. Security

API's can offer amazing flexibility such as polymorphic inputs which is about to figure how to interpret information sent to it, however this flexibility can also be used abuse the system. Below are some of the key drivers for the need for API

• Business - Speed to create customer innovation and unique experiences
• Customers - New features, single interface to take actions across systems
• Developers - Provides a faster way to develop systems with more flexibility
• Security - The Right amount of control , however often this creates friction

Challenge #4 - Common Bad Practices - It takes too much time to setup right

1. One Account is used for all integrations. This means one API if not secure could provide access to features or data from another API

RECOMMENDATION - One Account per API / per Integration

2. Lack of Toxic Access - One account can take an action and has the rights to

approve the same action as the account is running not like a user but with

full rights of the system.

RECOMMENDATION - Accounts should be designed for 1 specific purpose

BEST PRACTICES

1. Provisioning - Automate the process to create accounts and permission them with least privilege for a specific API feature
2. Credential Protection - Automate the process to on board accounts into a password value and rotate them periodically and automatically based on a schedule
3. API Gateways - Leverage a gateway to centralize controls including authentication, access rights, logging and denial of service attacks
4. Application and API Firewalls - Ability to stop common exploit attacks
5. Input/Output protection - Restrict to "only expected input/output"
6. Protection of authentication/authorization - Protect weak protocols
7. Rate limiting - Denial of service protection
8. Least Privilege - Ensure what an API can do is restricted to its purpose
9. Defensive Coding - Only expose the parameters and limit direct access
10. Code Signing - Restrict
11. Data Classification - Ensure your sensative data is encrypted and segregated
12. Versioning - Ensure you know what is changing, by whom and can roll back
13. Continuous Detection - Runtime Protection
14. Training and Education - Educate customers on the importance of API and developers on the available patterns and best practices to speed up development
15. Block Bad Commits - When you see code being check in that is insecure, block it and redirect the developers to a quick and easy solution they can use

SecDevOps Focused Approach

The best API have clear functions, documented input parameters, sample output, comes with sample code in multiple programming languages, is easy to consume and secure by design. That means the credentials must be protected and timebound providing only the least amount of access for the action.