In the virtual “… as a code” world there is no place for compromises and exceptions. Infrastructure as code has served as the catalyst for the broader “as code” approach, providing simpler ways to drive digital innovation and scale. There is one problem though: human nature and perception. Any "virtual" entity is harder to control and less transparent by nature. This has led to a rise of configuration and automation tools to deal with the complexity. The “..as a code” approach makes it structured, unified, easier to grasp and control at a much larger scale.
Application security has subsequently followed infrastructure, with "security as code" first coined a few years ago. Since then a couple tools have appeared enabling the broader adoption of the idea, but the coverage is far from ideal. Security is a large domain that is compromised of a number of elements from network security and application security to identity and access management. Add in the division between customer security and enterprise security and the landscape becomes pretty complex.
IT leaders are now focused on one specific area in particular—API security. As IT teams modernize their legacy applications, their reliance on APIs increases significantly requiring a concerted effort to protect their applications by securing their APIs. Reports like OWASP's Top Ten API Threats drive further attention to the growing sophistication of API attacks.
Despite this there is still not many tools that address API security in a comprehensive manner and even less that are designed in the “as a code” spirit. It's because API security itself is structured problem. Holistic API security requires treating APIs as full entities and thus providing them with identities, authorization, authentication, governance, DLP, and bot detection. It's why we at Cloudentity talk about modern IAM as being focused on APIs. And why our products are geared towards DevOps and DevSecOps roles.
Getting back to API security, among the areas mentioned above, one is exceptionally important. OWASP Top Ten API Threats immediately hint to it with the first threat in the list. API protection starts with strong authorization. We've written in the past why API Gateways—which just sit on the edge of the system—aren't enough to protect against API threats. API authorization is the central tenant of Cloudentity's platform and has been our focus for many years. To have a truly effective API security program, it must be part of your system tissue - interwoven into the DevOps processes, embedded into business domain, integrated with existing API Management solutions and other other cybersecurity tools like WAFs, and intelligent enough to adapt to risk signals.
How do we then extend "..as a code" trend to API security and make it simple for DevOps and DevSecOps teams to deploy?
Authorization Policy Stored as a Configuration
The ability to express any access control rules and store them as configuration is absolutely essential. Why is it essential?
Easier to Manage
When stored as a configuration the policy can be extracted and control can be granted to the right group of people, avoiding having policy hardcoded into applications and making it difficult to manage access control across the application ecosystem. We find that security professionals are eager to adopt fine-grained authorization policies to protect APIs but are often met with hardcoded access rules making it hard to control, audit and time-consuming to update. Fine-grained authorization is necessary to combat against emerging API threats and is why object level (aka fine-grained) authorization tops the OWASP Top Ten list.
Version Control
Just like code, policy can change and adapt over time. By storing policies as part of the configuration, teams can leverage their existing version control and change management solutions to leverage it in CI/CD pipelines, manage changes over time and easily adapt to new requirements from internal stakeholders or external events like new regulations.
Improved Transparency
Because easy to read configuration promotes transparency, eliminates human errors and makes them accessible and editable anywhere. Older policy languages like XACML add complexity, make policies hard to edit, interpret and thus make them prone to errors. Policies should be easy to assembly from self-explanatory building blocks. Effective policy creation and unambiguous interpretation should be possible in any YAML or JSON editors.
We've made a few sample policies available for review in GitHub.
Automation Readiness
The policy language shall promote automation, so that policies can be easily adapted to changing threats. The modularity of the authorization policy language and usage of JSON/YAML are huge automation enablers. Adding any additional checks to the authorization policy in an automated fashion is as simple as adding JSON fragments with use of a common library supporting this notation.
Keep the Strategy Inclusive
DevSecOps aren't the only team that contribute to API security effectiveness. It is absolutely fundamental to make policies transparent and understood by others – security engineers, privacy engineers, data loss prevention engineers, GRC, etc. They will not be looking or editing YAML policy files.
To keep the strategy inclusive, policy management must be visualized and editable in a WYSIWYG way, so that non-development team members and stakeholders have frictionless insight in authorization policies and be able to easily modify them if needed.
Central Management and Distributed Enforcement
Regardless where access decisions and enforcement happen, policies need to be easily accessible and easy to manage.
System architectures and authorization evolve much quicker than most traditional cybersecurity tools.
Currently many authorization policy decisions and enforcement take place at the authorization server, while the services make only super simple checks during resource access. Usually any more sophisticated check at the transaction level requires coding and hardcoded storage of the policy. This scenario is even more complicated in microservice architecture where policies controlling interactions between services need to be stored and enforced. Management of these policies and enforcement is traditionally left to security team members, which have varying level of coding experience and knowledge.
The right approach should let you give comprehensive, centralized control over the policies, even if distribution and enforcement is divided between transaction and token minting. Moreover, hardcoded policies should be eliminated as much as possible to minimize Security Misconfiguration as stated in OWASP API Security Top 10.
These policies should be distributed to policy decision and enforcement points in the authorization server, at the edge using API Gateway or at the microservice level.
DevSecOps Pipeline Integration
Ease of integration with the pipeline is a must. For continuous delivery to continued unhindered, security must also be continuous and adaptive. Wherever new service versions are rolled out, the revised versions of policies must be rolled out along with them. To create an ideal environment for DevOps and security engineers to make it happen, the policy configuration must be easy to manage and deploy. Utilizing tools like HashiCorp Consul to store policy as part of the configuration makes it easy to adapt security as part of the DevOps cycle.
WAF and Security Infrastructure Integrations
Modern Web Application Firewalls are extremely important for API security. WAFs block traffic that is undoubtedly malicious, however part of the traffic can be passed through “conditionally” and decision can be deferred to the authorization policy at the API level. By adding an additional authentication step as part of that "conditionality", legitimate users that would be outright blocked by the WAF are instead asked to complete an additional measure of security and allowed access once verified.
Data Classification and Loss Prevention
API Security extends beyond just protecting the APIs. At their core APIs are simply tools to exchange data. Protecting against excessive data exposure requires understanding what data is accessible by your APIs and accessing whether that data must be shared.
APIs must be tagged with the data they use and data must be protected with policies just like the APIs. The ability to control which data APIs are sharing as part of the configuration is an important piece of data loss prevention.
Visibility and Intelligence
Continuous and adaptive risk and threat analysis (CARTA) requires a constant state of vigilance. Extending a CARTA style approach to your APIs and OAuth authorization server is necessary to anticipate threats and respond appropriately. For API authorization, this means not just tracking successful authorization transactions but also failed attempts. Since significant API authorization burden is on authorization server, the tracking should also cover the process of minting access tokens required for API consumption. A spike in failed attempts anywhere might suggest on-going attack such as a brute-force attack and should be monitored even if the attack is prevented through strong authorization policies. Tying cybersecurity signals, like the ones generated by WAF providers, to authorization provides a means to upgrade authorization request and prevent attacks from bots or actors.
Enabling authorization as code and provides a scalable and holistic approach to API security. Interested in learning more? Sign up for a demo today and get immediate access to the Cloudentity platform to try it out.