Bringing Developers into Your Zero Trust Strategy

by in CyberRes

When it comes to implementing zero trust principles across their environment, one of IT’s biggest challenges are services delivered via API’s. While IT has full control of online interfaces presented to users, they are often unaware of accessibility offered via APIs. Too often, the interface for these services is a black box for IT, which poses a major problem to the teams responsible for securing their information.

Three areas come to mind where security voids will more likely exist because they are under-secured by IT:

  • Native mobile applications – last year, analysts counted1 over 218 billion mobile app downloads by over 7 billion users. Today, smartphone users spent less than 8% of their usage time in a browser; meaning, that information and services action is mainly through these applications. When you consider how many of these applications are financial, healthcare, or retail centric, you get an idea how much information is moving around via the APIs that support them.
  • Microservices – spurred on by the growth of SaaS-based services, the transition to microservices has been growing steadily. In turn, this trend has provided fertile ground for further investment in container management technologies like Kubernetes that further enhance the benefits of a microservice architecture. According to an O’Reilly survey about Microservices Adoption, a third of organizations who participated in their survey claim that they are migrating the majority of their systems over to microservices.
  • By their very nature, microservices proliferates the number of API interfaces for both the interaction between them as well as external consumption.

Bringing Developers into Your Zero Trust StrategyThe Complexity of API Security

In this era of API’s growing window of vulnerability, the elusive question is how to protect against this threat. The barrier to more effective security is largely organizational.


In many organizations, development teams are part of business units responsible for evolving business models and garnering avenues of revenue. While they may be moderated to some extent by IT or security, they often work for a department or division flush with cachet and influence where they work by their own rules and business processes.

Whether it’s a mobile app, set of microservices, or any other development effort, their projects are usually conducted independently from IT operation teams, who will later be responsible for their management. And while their priorities overlap with IT Operations to varying degrees, it’s all too common for their relationship to resemble a “throw it over the wall” model.

Security and IT Operations

To ensure their solution behaves and performs as intended, business owners routinely deploy and manage their environment on their own. Once the product owners are satisfied that their objectives are met, they hand off their environment over to Operations. Hopefully, the security team has been involved throughout the entire development lifecycle. Still, often they don’t have the visibly or sponsorship needed to ensure that security is baked into the initial design and development of the new service. This model of development also complicates and potentially compromises central IT from effectively reaching their security goals. It would be rare for these teams to provide a set of specifications for each and all APIs built in their solutions.

Raising API Security

For now, I’m going to assume that central IT’s ability to impose security requirements onto to divisional development teams to be spotty, which leads to the discussion on how an organization can achieve its zero trust security goals. My suggestion is for IT to try more carrots and fewer sticks

Raising risk awareness across the organization

One service that central IT can provide relevant divisional business entities is to provide periodic breach updates in the form of frequency and business impact. Verizon’s annual Data Breach Investigations Report (DBIR) is a first-rate source for up-to-date worldwide breach trends and Ponemon Institute offers the most thorough analysis of cost and business impact. Specific to APIs, the Open Web Application Security Project (OWASP) foundation is focused on improving software security for web-based applications. Their broad membership and active chapters make them a primary source of web app breach information, including those involving APIs.

Raising risk awareness across the organization

Together, IT and security teams have the fodder they need to educate their organization on the latest Breach trends and cost report from Ponemon Institute, sponsored by IBM, offers worldwide trends and cost models that organizations can apply to their own environment.

Normalizing API Best practices

While central IT doesn’t have a prayer imposing any type of development best practices on individual teams, they do have the opportunity to coordinate across divisions to create some type of standard of API security standard, everything from design, penetration testing, to monitoring. A good segue to this discussion is the risk reports reviewed in the previous section. They may help the app teams align on what practices fit their situation.

Offering Security Services for APIs

As development teams work towards defining their set of API security standards, a portion of them will assuredly benefit from leveraging identity and access management technologies. As such, here are some common security practices that are covered by NetIQ’s platform:

  • Secure API’s – NetIQ Secure API Manager (SAPIM) can serve as a security gateway, protecting access by using OAuth authorization tokens to verify the identity of the requesting API
  • Design a least privilege posture for API’s – this same gateway configuration enforces specific authorization scopes assigned to it
  • Require strong authentication practices with multi-factor authentication and passwordless technologies. This means keeping credentials out of the application code itself.
  • Protect against API sourced denial of service attacks – SAPIM allows you to define limits to each API, controlling the amount of bandwidth that can be consumed over a defined period of time.
  • Monitor usage – use Access Manager’s Analytics Server to provide analytics for many different items such as failed authorizations.

The key ingredient to success is for each development team to understand how these security services will take a lot of pressure away from them. The security gateway alleviates the need for developers to build the security elements listed above natively into their applications, removing a significant amount of effort, complexity, and domain knowledge. The NetIQ platform itself provides a level of security sophistication not possible within the application itself. It offers a centralized risk service that organizations can use to enforce their organization’s security policies, as well as machine learning capabilities designed specifically to identify security blind spots that would otherwise be missed.


While central IT often doesn’t have the clout to impose control of API interfaces used throughout its organization, NetIQ does provide a security foundation that development teams should find useful. And considering the dramatic increase of information transferred and consumed via API’s, development teams should find this security platform useful.

Checkout this quick Secure API Manager demo and overview video found on NetIQ Unplugged.

Have technical questions about NetIQ Secure API Manager? Visit the NetIQ Secure API Manager User Discussion Forum. Keep up with the latest Tips & Info about Secure API Manager. Do you have an Idea or Product Enhancement Request about Secure API Manager? Submit it in the Secure API Manager Idea Exchange. We’d love to hear your thoughts on this blog. Log in or register to comment below.


Identity & Access Mgmt