I’ve seen multinationals repeatedly set up governance and centers of excellence (COE), like sentinels looking down on IT, waiting to sign off on a release after a new code passes a few tests. Code is just tossed over silos without considering the tools that act as the security and reliability of any transformation.

But that approach risks costly security breaches, one of the biggest threats your enterprise faces today. And API security is often at the core of these breaches. In fact, by 2022, 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.

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 to make informed decisions. You need to know the health of a specific project and the whole developer life cycle of a product. You have to know your current state, need proper visibility into the traffic running through your apps and infrastructure, and see the error patterns.

And you need to solve issues before your customers notice anything.

Sadly, enterprises are still project-driven instead of product-driven, with budgets and deadlines tied to delivering project features, not holistically examining a product and its capabilities. Many brands have been unsuccessful in their API journeys and 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, it's magically secure if it passes a confined set of tests. 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 develop processes. It must be more than just assuring a specific set of projects runs in a certain way and 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 should automate your API security best practices into your entire API life cycle. You need to have in-house systems or subscribe to a system already doing that as part of an ecosystem to function right. It’s a top-down approach that knows what questions to ask and when and uses 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 consumer’s usage patterns?
  
• Do they need this API?
  
• What is the behavioral design for this API?
  
• What is my ROI?
  
• Does this API 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 APIs 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 has 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, incredibly, what the consumers are demanding. But their dedicated focus on 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 with very few asking the right questions and reviewing data security and necessity.

You need to consider that this API and the user ID passing through it as part of the query parameter pass through browsers with caches and cookies aplenty. Everyone should be asking themselves: Do I need a 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 into, 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 plans are behaving and then collects patterns. It draws your attention to these patterns and even implements actions in response, like shutting down vulnerable systems before the clients risk them.

A team is only as successful as the set of products at its disposal. With that in mind, every API Security Toolkit should include:

• AI-powered API security: Self learns, and self creates the rules built to recognize and respond to the attacks proactively.
• Straight sets of issue alerts: The right people know as soon as things are awry
  
• Dashboards: Teams must see the patterns, and this information radiator contributes to a security-first mindset.
  
• Data governance: Ensure that the data is being transmitted securely, 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 with 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 everyone can use those tools. 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 comes in. If something is down, everyone who needs to know knows right away, long before your customers do.

They are 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 are already many 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 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 complete overview of your connecting APIs 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 precious. This tooling detects the current anomalies and starts feeding this intelligence not only back into your system's 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 wrong. 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 stage of your agile process. A continuous learning mindset around API security is the only way to succeed proactively.