Our Enterprise API Security Solution
TLS, OpenID and the OAuth standards address only part of the API security problem. Every week, APIs that have authentication and encrypted traffic get breached. Modern enterprises often have hundreds of microservices, each exposing an API to communicate with other microservices and the outside world, all rapidly changing through agile development processes. Ensuring that each and every microservice at each and every iteration is following authentication, authorization, and transport best practices and that no edge case or attacker-crafted request can break an API is hard. With 42Crunch you can do just that!
How a DevSecOps Approach Delivers Reliable API Security. Download our FREE “API Security in the Enterprise” Whitepaper
API Security by Design
When you read about API security, you often see references to TLS 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 the confidentiality and integrity of transactions, and the availability of the API infrastructure.
OpenAPI (formerly known as Swagger) is the industry standard that was born out of necessity to generate standard machine-consumable API documentation. The standard has been adopted by the industry and became a way to define API contracts between API providers and API consumers.
The 42Crunch platform helps developers ensure their API contracts follow all security best practices, API implementation is complying to the contract, and no calls or responses outside of the contract can ever happen.
With 42Crunch, you do not have to rely on security by obscurity, manually configured rules, or hope that some sort of anomaly detection can report an attack. Instead, 42Crunch enforces a positive security model so that you know your APIs have been designed and implemented following stringent security standards, and they are protected in real-time across each and every microservice involved.
Developers are powering modern businesses. With agile iterations and microservices architectures, they move quickly to be the first and the best when serving the company’s customers.
42Crunch technology gets integrated right into developer tools, including integrated developer environments (IDE) and continuous integration / continuous delivery (CI/CD) pipelines, to provide security checks where developers are and when they need them.
The checks come not just with the security scores but also with detailed information on exploit scenarios and remediation steps. With this practical information at hand, developers no longer have to guess what API security is. They follow the reports and know that they have done the security part of their job in the best possible way.
Security specialists often have to step in after the APIs have been deployed to production. They then have to figure out how to configure externals tools with some sort of static rules and policies to provide security. Or they have to go through various log management, monitoring, and anomaly detection tools trying to find the real breaches among false positives and legitimate traffic.
With 42Crunch, there is no more guesswork required. Security and Developers finally speak the same language, agree on the same security standards, have a shared understanding of the APIs exposed by the company, the security level of each API, and next steps required to improve it.
Reuse Proven, And Standard-compliant API Security Policies
Our API security team comes from a wide background of WAF, API management, and whitehat security companies. We are one of the active members of Linux Foundation OpenAPI Initiative and reviewers of OWASP Top 10 for API Security. With us, you can be sure that your APIs are checked against the latest known risks and follow the latest best practices.
All checks are based on the industry standard OpenAPI specification, and we have documented each and every one of them on our API Security Encyclopedia.
Distributed Enforcement Model, Compatible With Microservices Architectures
API 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 API firewall with each and every microservice following the sidecar model. Even if attackers manage to get into your network and exploit East-West traffic, your systems are still going to be well protected.
The API Firewall has been written in C, its image is less than 20 MB, and its overhead is well under 1 ms.
Integrate API Security Fully As A Part Of Devops Initiatives
API 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.
Foster Collaboration Across API Security Actors
API security is a cross-functional part of the IT organization 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.
42Crunch gives everyone in the company a common security language and shared understanding of the APIs that the company has, their current state, security levels, production protection status, and any required further security improvements.