Most organizations today use hundreds of applications in their environment, and with that they employ hundreds of APIs to connect these to the necessary web servers. Due to the flow of sensitive information, it’s crucial to manage policies that ensure controls are in place to only authorize appropriate access, as well as actions that can be taken with that access.
Before we dive in on the subject of API Security, I want to define exactly what I’m talking about here because often people immediately think of the OWASP top 10, vulnerabilities around SQL injection and so on. Preventative steps and solutions that address those vulnerabilities are certainly crucial, but what I’m referring to is the practice of establishing attribute-based access control (ABAC) policies around what actions can be taken, by who or what (be it an identity or another application), and under what context/conditions. For security-centric organizations, it is important to establish modern approaches to writing authorization policies that can scale with your API development strategy and team.
Until recently, the manner in which most organizations tackled this challenge was by writing ad-hoc policies developed and managed in silos across the organization. Whether developers leverage languages such as Python or REGO, or use something more specific to authorization such as ALFA (Abbreviated Language for Authorization), a domain-specific language often used in writing access-control policies, available via the Organization for the Advancement of Structured Information Standards, there is a need to clearly define policies that include those attributes that need to be considered, under what conditions and even in relation to each other.
Policy-as-code does this by removing security silos and combining configuration and compliance into one step. This enables organizations to employ testing and validation of the policies as part of a centralized process that also captures version control. Since developers are dealing with hundreds of applications, this approach also increases the speed and efficiency compared to a manual approach of addressing each API and application individually.
Now with respect to simplifying API security, there are a number of aspects a policy-as-code approach brings to organizations.
Establishing Best Practices
First, policy-as-code enables organizations to consistently adopt many best practices we see around authorization directly within the development life cycle. APIs should never be viewed with a set-and-forget mindset but rather treated as a key element of your software development life cycle. By approaching them in the same manner as you would approach any new code, you can ensure proper testing and post release monitoring is done.
Shift Left
Many organizations continue to have conversations as to how they can Shift Left and bring security to the beginning of the development process. Leveraging a policy-as-code approach brings access considerations to the beginning of the development process, which again provides a more comprehensive approach to simplifying API security. Too often, especially when dealing with custom one-off development for a specific application, security is the afterthought. Leveraging an API to solve the business problem becomes the priority and at the 11th hour, the project comes to a screeching halt as only then someone from the security team is made aware. The result – there’s now an exercise in fitting controls into the solution after the fact and as we know that is exponentially more expensive than building the right policies in from the start of development
This is a real problem and in a recent survey conducted by 451 Research, 35 percent of respondents said they have delayed projects due to API security concerns, with 87 percent of respondents believing that integrating API security testing into developer pipelines could have prevented delays.
It’s All About Policies
The third key benefit to this approach is that since you are now capturing all these policies in a centralized repository, your team can learn from and leverage other team members’ more complex, dynamic policies. In fact, you want your policies to be dynamic, as the whole point of security doctrines such as Zero Trust is to leverage as many attributes as necessary to understand the context of a request and determine the appropriate response. A policy that is dynamic and able to pivot due to additional attributes is incredibly valuable not only from a security perspective, but also because it enables your business to continue with some caveats, such as PII being anonymized in certain conditions, as opposed to simply denying the user access outright and forcing business to stop.
By leveraging a policy-as-code approach organizations can actually go one step further and take the authorization process out of the APIs and applications to externalize it in one central policy decision point (PDP) for all applications within an organization. This means that instead of every development team having to master the ABAC concept, they simply write a standard API that is used to connect to a main ABAC REST API.
That way, whenever a new API is needed or a change is required, one development team can easily do that ABAC coding in the one central location of which all other teams connect to. For example, if a change must be made due to a new compliance law coming into effect, it can be made in this one location for all applications that have policies affected by the law.
The bottom line is that a policy-as-code approach is good for all aspects of the business. It means better API security practices, less delays for the business in getting their projects completed and it empowers developers to tap into and build upon a growing library of dynamic policies within their organization. Considering that API attacks rose by 681% in the last twelve months, the time to start moving to a policy-as-code approach is now.
