I’ve seen multinationals time and again set up governance and centers of excellence (COE), like sentinels looking down on IT, waiting to sign off on a release after new code passes a few tests. Code is just tossed over silos without consideration to the tools that act as the security and reliability of any transformation.
But that approach risks costly security breaches, one of the biggests threats your enterprise faces today. And API security is often at the core of these breaches. In fact, by 2020, API abuses will be the most frequent attack vector that results in enterprise data breaches, according to a recent prediction by Gartner analyst Mark O’Neill.
Clearly, API governance is essential to the success of your digital business. By following strategic API security, monitoring and open cultural practices, you can turn your COE from a corporate buzzword to a long-term stabilizing strategy.
The Mistake Most Companies Are Making
Companies have gotten pretty good about knowing when something is going wrong with their system and when they need to fix a bug. But that’s not enough data make informed decisions. You need to know the health not just of a specific project but the whole developer life cycle of a product. You have to know your current state. You need proper visibility into the traffic running through your apps and infrastructure. You need to know error patterns.
And you need to solve issues before your customers notice anything.
Sadly, enterprises are still very project-driven instead of product-driven, with budgets and deadlines tied to delivering project features, not holistically examining a product and its capabilities. A lot of brands have been unsuccessful in their API journeys and their so-called digital transformations. They don’t see APIs adding value, and they’ve lost track of the return on investment.
Therefore, most enterprises check their API security at the end of the life cycle. They run regression tests to see if it works or not. Then, if it passes a confined set of tests, it’s magically secure. This last-mile mindset is behind personal healthcare data, payment information and billing address leaks making headlines daily.
API security must be everyone’s responsibility at every step of your life cycle, and it should be built into your product design itself. Governance can work only when API security is considered from the start, with the right set of tools in place, so your team is armed and ready to fight these battles.
How to do API governance right
Governance should be about creating a mindset throughout an organization rather than being treated like a set of people who create processes. It must be more than just assuring a certain set of projects run in a certain way, but also making sure the projects add value. Any successful enterprise transformation needs feedback early and often, bridging the gap between the consumer and the provider.
While we say we’ve embraced DevOps culture and we try to employ security best practices at the end, there’s still far too much pressure to meet delivery dates. It becomes impossible to continue to deliver at the speed the market requires while still manually performing some security tests right before release.
The solution is to automate your API security best practices into your entire API life cycle. To function right, you need to have in-house systems or subscribe to a system that is already doing that as part of an ecosystem. It’s a top-down approach that knows what questions to ask and when, and makes use of a powerful security toolkit.
Asking the right questions
Governance in the API space means constantly asking:
Why do I need this API?
Who are my API’s consumers?
What are their user patterns?
Do they really need this API?
What is the behavioral pattern for this API?
What is my ROI?
Does this API actually add value to my consumers?
How is this API being integrated with my partners?
Which devices are calling this API?
What barriers are there for people to access this API?
How could my API gateways be compromised?
What is being cached on local browsers?
How many retries are permitted when trying to access your API?
Knowing when and how to ask questions
When you have a small product, you could probably continue to ask these questions through manual work. But once your company is scaling, you start to lose track of data and cut corners to meet deadlines. API security needs to be built into your API modeling, both into your test-driven design and into your conversations with every part of the business.
You need to be constantly asking: Is this sensitive information? API governance is about having different security policies for internal APIs, external APIs, open-source APIs and partner APIs.
API analysts will be tasked with building an API specification under OpenAPI (formerly Swagger) and they will just focus on the UI, the interface, what data models they need, and, especially, what the consumers are demanding. But their focus on features, features, features, is a threat to most companies, as they overlook essential vulnerabilities. This has them building sensitive data into their API headers and query patterns. Too few are asking the right questions, reviewing the security and necessity of data.
You need to consider that this API and the user ID passing through it as part of the query parameter are passing through browsers with caches and cookies aplenty. Everyone should be asking themselves: Do I really need user ID as part of this API? And, if I do need it, should it be part of an encrypted payload?
You also need to be asking: Where are these requests coming from? You need to be designing APIs based on the systems and devices they are getting integrated to, as they are a growing threat from hacks, which risks sensitive information.
Having the right toolkit for a security-first culture
A proactive company applies a self-learning system that leverages artificial intelligence to gather information about how your systems are behaving and then collects patterns. It draws your attention to these patterns and even implements actions in response, like shutting down vulnerable systems or the clients risking them.
A team is only as successful as the set of products it has at its disposal. With that in mind, every API Security Toolkit should include:
AI-powered API security. Self learn and self create the rules, built to recognize and respond to the attacks proactively.
Right sets of issue alerts. The right people know as soon as things are awry.
Dashboards. It’s critical for teams to see the patterns, and these information radiators contribute to a security-first mindset.
Data governance. Ensure that the data is being transmitted in a secure way, being exposed in a way that aligns with your security policies.
API gateways. These are important for API orchestration and integration.
Firewalls. Protect against threats like SQL injection attacks.
You need to inject security into your 360-degree view of your API life cycle from the start at all levels: planning, designing, developing, testing and release management. Every day there’s a new threat out there in the open. You’ve got to make sure you’re learning every single minute.
Security has to be part of your user story, not just a checkpoint in your release plan. As you use tooling to recognize user patterns, you should also use it to help contribute to that user story, developing a sequence of use cases from API keys to tokens to audit logs and more. This doesn’t just give you empathy into your users, but it gives you—and your tooling—insight into potential risks to your systems.
And within a DevOps enterprise, everything is about making sure those tools can be used by everyone. The power of IT no longer should be siloed for just IT, but should be connected to the business value. This is where tooling with good dashboards come in. If something is down, everyone who needs to know knows right away, long before your customers do.
Fixing poor API governance retroactively
What about the enterprises that haven’t built security from the start? I’ve certainly walked into enterprises where there’s already a bunch of services out there for APIs to consume. There’s no time like the present to change your ways. Security must create a sense of urgency within your organization. You should make a point to revisit your API security in your next immediate sprint.
One problem that I’ve repeatedly seen is that key players like CIOs don’t even know an API exists until it’s already been hacked. You can’t govern what you don’t know exists. Proper enterprise-grade API tooling is needed to give you a full overview of what APIs you have and are connecting to and the resources and information they expose. Tooling can even enable continuous API discovery, so, while you’re giving your developers DevOps autonomy, you are aware of every open-source or subscription API they are connecting to.
Then you need to monitor these APIs. This is where these self-learning security systems are incredibly valuable. This tooling detects the current anomalies and starts feeding this intelligence not only back into your systems coverage, but into your new company culture of security first—instead of public embarrassment later.
Take charge of your API security
These companies you keep seeing in the news for data leaks? They are reactive. When you don’t have the right kind of systems in place between your consumer and provider, you’re just waiting for something to go bad. You’re just reacting, searching where the service denial attacks are coming from. It creates distrust with your consumers, and they won’t want to share their personal information with you.
A successful company must be proactive. You need to integrate security into your governance at each and every stage of your agile process. Having a continuous learning mindset around API security is the only way to proactively succeed.