When one talks about API security the focus is typically on public facing APIs. As digital transformation efforts take hold internal API also become critical attack vectors and must be properly protected. Programmableweb.com, a leading source on all things API, lists upwards of 20,000 APIs in their API directory. APIs have therefore become an important attack vector.
Emergence of Security as Code and DevSecOps
As businesses embraced digital transformation, moved to the cloud, and adopted a microservices-centric architecture, they began pushing the envelope on release frequency. This led them to adopt a DevOps model, in which Development and Operations teams began to work closely together. Infrastructure as a service allowed for the popularization and widespread use of Infrastructure as Code (IaC). Resources no longer needed to be specified out months in advance, ordered and physically racked in data centers. Instead, programmatic APIs could be utilized to create brand new resources on demand. Those resources could be automatically scaled up or down. Infrastructure could now be completely created and managed using code. IaC removed the friction and toil associated with teams manually provisioning and managing fleets of servers, databases, operating systems, containers and at this point, all infrastructure associated with software applications. Dev and Ops team are no longer separate teams, but rather working together to build and scale applications together.
Security as code similarly sees a migration to security and policy as code to remove the toil and friction associated with securing software in an IaC mindset. Security and policy as code began with standard software testing of areas like permission boundaries. These unit and functional tests were Security as Code before being labeled as such. Security as Code also rose out of the desire for automation from internal and external red teams and pentesters to automate all of the things. Known as DevSecOps or DevOpsSec, this methodology has become the way organizations can enable collaboration, agility and security, early and often across their entire infrastructure.
API Security
In line with DevSecOps best practices, security must be incorporated throughout an API lifecycle – design, development and deployment. The OpenAPI Specification (OAS) 3.0, a standard API description format for RESTful APIs, introduces the concept of securitySchemes that allows one to specify, at design time, how an API must be protected. Below is an example securityScheme:
"securitySchemes"
: {
"petstore_auth": {
"type": "oauth2",
"flows": {
"implicit": {
"authorizationUrl": "https://petstore.swagger.io/oauth/dialog",
"scopes": {
"write:pets": "modify pets in your account",
"read:pets": "read your pets"
}
}
}
},
"api_key": {
"type": "apiKey",
"name": "api_key",
"in": "header"
}Once the API spec is ready, an application developer implements the logic behind the API including the required protection. During deployment, teams may decide to include an API gateway to proxy the service. In this case, protection can be offloaded to the API gateway. Popular API gateways such as Kong and MuleSoft allow one to deploy policies that protect the endpoints they are proxying. More recently, in cloud native environments, the idea of a microgateway has taken hold. A microgateway is a lightweight proxy that gets injected alongside every microservice and implements protection. Envoy is a popular, open source microgateway.
Errors in implementing the DevSecOps flows described above can lead to catastrophic data breaches. For example, even though an API specification requires authentication a developer may forget to implement this requirement or forget to deploy the appropriate policy in the API gateway. The result is an API that is exposed to the public and from which potentially sensitive data can be exfiltrated. Such attacks happen very rapidly. A recent article described how an unsecured endpoint, deployed as a honeypot, had 175 attacks within 8 hours of deployment.
To bring focus to API security challenges the OWASP API Security Top 10 Project was launched in 2019. The project is designed to empower organizations, developers and application security teams to better manage security risks associated with APIs. These are different from the OWASP Top 10 for web applications. Enterprises must look to secure against both and ideally complement them with data layer security for protection in layers.
Augmenting API Security with Data Layer Security
An unsecure API can be catastrophic because it can leak sensitive information. While an API Gateway is the right place to implement authentication and authorization one must complement this with data layer security. By implementing observability, control and protection right next to the data layer, Cyral complements API security products. Just like API gateways intercept application requests, Cyral has built a unique technology to intercept requests to databases, pipelines and data warehouses.
Cyral’s Security as Code approach enables it to plug into a user’s CI/CD pipeline and tools for a seamless experience thereby enabling security in layers. To learn more about how Cyral can enable organizations to embrace cloud-native architecture and API-first designs securely, register for a demo.
