Zero Trust is a great framework to protect our IT assets, operations, and data. It has gained a lot of attention and many followers since the idea was first introduced by John Kindervag, and it has helped organizations as they mature their respective IT security programs. Even government agencies were directed to “advance toward Zero Trust Architecture” in President Biden’s Executive Order on Improving the Nation’s Cybersecurity. Although interest is strong and the effort to improve is meaningful, the outcome will be less than expected if API security is not included. And I rarely hear anyone discussing API security as part of their Zero Trust architecture.
Many organizations focus security on end users and their devices, policies and processes, firewalls, antivirus software, and Intrusion Detection/Protection Systems. But they don’t pay attention to what their applications are doing. Take the recent Spring4Shell vulnerability as an example.
The API was modified to create a new entry with a malicious payload. To the traditional security hardware, which applies a simple logic test, the API looked normal; it was trusted. The simple logic test failed to identify the changes in the API and recognize the vulnerability. Without human interaction to identify and reconfigure equipment, Spring4Shell could have caused significant damage.
Can we always count on identifying zero-day vulnerabilities so quickly? How many other APIs could be easily modified and used to bypass security systems? Spring4Shell should be a wake-up call to all those concerned with cybersecurity that APIs are a real vulnerability.
The number of applications we use every day has exponentially increased and that growth shows no sign of slowing down. APIs are presenting an ever-larger attack surface. According to Gartner’s August 2019 report, API Security: What you need to do to protect your APIs, “By 2022, API abuses will move from an infrequent to the most-frequent attack vector”. Recent surveys bear that out: a large percentage of organizations experienced API security incidents over the last 12 months, often involving data breaches or loss. Without robust API security, any efforts to enable a Zero Trust architecture will be incomplete.
Government agencies are often slower to adopt technological changes due to a variety of reasons, including budgetary considerations as well as a methodical approach to risk/reward evaluation. However, with regard to API security, government agencies don’t have the luxury of time. The threat landscape is changing rapidly and with the increasing emphasis on Zero Trust, now is the time to include APIs as part of that framework. We should build appropriate API security into systems now before more threat actors expose the vulnerabilities and we’re left picking up the pieces after an event.