TAKE A HOLISTIC APPROACH TO API SECURITY
When you read about API security, you often see references to OpenID Connect and OAuth as the secret sauce to address the problem. However, the API security problem has a much wider scope, and those standards help address only parts of the problem. API security needs to be approached as a whole to address all security goals, including attacks protection, ensuring confidentiality and integrity of transactions, and the availability of the API infrastructure.
Additionally, OAuth should be further boosted with a dynamic authorization model, which is external to the applications and can address the issue of fine-grained access to data exposed through APIs
ASSESS RISK BEFORE DEFINING API SECURITY
Not all APIs are equal. The security level that an API requires depends on the sensitivity of the data and operations applied to that data, who can access the API, and in which network zone the API is deployed. By defining a threat model and assessing the risk for each API, you can ensure that the API security policies are adequate for each API and prevent high-risk APIs from being deployed on poorly secured infrastructures.
Our platform is designed so that you can assign a risk score to the policies and to the deployment infrastructure, and ensure that APIs are adequately protected based on their risk level.
REUSE PROVEN, AND STANDARD-COMPLIANT API SECURITY POLICIES
API security is hard. There are many ways you can get your security policies wrong, even when following a standard. Take OAuth, for example: a plethora of RFCs and profiles related to threats models, best practices, token theft, and Open Banking. Which configuration is right for you? What happens when new threats or new best practices are discovered? Reusability of predefined, pre-tested policies is at the heart of our platform. Leverage our OWASP, FAPI, Open Banking, and Healthcare packages, adapt the policies to your specific needs and rest assured that our security specialists have paved the way towards better API security for you.
DISTRIBUTED ENFORCEMENT MODEL, COMPATIBLE WITH MICROSERVICES ARCHITECTURES
Security has traditionally been enforced at the edge through a gateway pattern. But modern applications have redefined the rules of the game: applications often rely on multiple internal, public, or partner APIs. In addition, the adoption of microservices architectures has multiplied the number of API endpoints to protect. These architectural changes require security to be handled as close to the API as possible.
Our runtime architecture allows you to deploy and scale a single cluster of Guardian at the edge of the network, or dozens of Guardians as micro-firewall in front of microservices. It’s your choice.
INTEGRATE SECURITY FULLY AS A PART OF DEVOPS INITIATIVES
Security flaws are injected at many different levels of the API lifecycle: in requirements, during development, and during deployment. It is proven that detecting and fixing vulnerabilities during production or post-release time is up to 30 times more difficult than earlier in the API lifecycle. Security should be easy to apply during development by attaching pre-defined policies to APIs and ensuring that tests are performed as part of the continuous delivery of the APIs.
Our unique tagging mechanism lets developers easily describe the level of security their APIs require. Those tags automatically translate into corporate security policies, as defined by the security teams.
FOSTER COLLABORATION ACROSS API SECURITY ACTORS
API security is a cross-functional part of the IT organisation but IT security teams are rarely part of the development and deployment process of APIs. The security teams are often invited late in the game to review security in a rush, with limited time to fix potential vulnerabilities or put in place the proper protection layers in front of APIs. It is critical to manage APIs in a central place where the various stakeholders can see new APIs that are being deployed and enforce corporate security policies and processes.
Our APIPub is the central application when all actors from API product managers and security architects to developers and operators meet and agree on risk assessments, configure the policies to apply at the corporate level, and define the infrastructure configuration.