4 min read
Google has always been a leader when it comes to security culture and their approach to managing a secure development lifecycle is no exception. This article introduces Google’s Binary Authorization for Borg (BAB), and will show you how you can implement the same binary authorization system to ensure that production software and configuration deployed in your organization is properly reviewed and authorized.
What is Binary Authorization for Borg (BAB)?
As with any security-centered culture, Google understands that insider risk represents a significant threat to the security of user data, and that the only way to ensure compliance is by employing a zero-trust model. BAB is Google’s internal technology for ensuring their secure development process is being followed.
“At Google, we want to do as much as we can to minimize the potential for Google personnel to use their organizational knowledge or access to user data in an unauthorized way一this includes running an unauthorized job”
At its heart, BAB is a pre-deployment check that production software and configuration deployed at Google is properly reviewed and authorized. The way it works is to require all services to define a BAB policy which is then automatically checked as part of the DevOps pipeline.
Some of the checks that can be automated in BAB include:
- Is the binary built from checked in code?
- Is the binary built verifiably?
- Has the binary passed all test and qualification steps?
- Is the binary built from code intended to be used in the deployment?
By incorporating these basic checks into the development pipeline, Google ensures that all production jobs automatically comply with security requirements.
Benefits of BAB
Adopting BAB has helped Google:
- reduce overall insider risk
- support uniformity of production systems
- dictate a common language for data protection
- programmatically track compliance requirements
These benefits can be realized in unexpected ways, as described by Google itself:
BAB simplified what were previously manual compliance tasks. Certain processes at Google require tighter controls on how they deal with data. For example, our financial reporting systems must comply with the Sarbanes-Oxley Act (SOX). Prior to BAB, we had a system that helped us manually perform verifications to ensure our compliance. Post BAB, many of these checks were automated based on the services’ BAB Policies. Automating these checks enabled the compliance team to increase both the scope of services covered and the adoption of appropriate controls on these services.
How to implement BAB with Kosli
The good news is that you don’t need to work at Google to get the advantages of compliance automation. Kosli provides the necessary primitives for tracking binary compliance data and automating change processes in exactly the same manner as Google’s BAB – without changing any of your existing tools or processes.
There are three basic steps to implementing BAB in your own projects:
- Identify security policies that you wish to enforce on production binaries
- Instrument your existing DevOps pipelines to collect necessary compliance data
- Add gatekeeping step to your release process to verify compliance with your policy
This is what the result would look like in a typical DevOps pipeline:
Advanced Security Scenarios
As with BAB, once you have basic compliance automation with Kosli you can start to look at more advanced policies and scenarios. At Google, they have specified three interesting approaches, each with increasing security:
- Deploy-time audit: auditing but not enforcing policy at deployment
- Deploy-time enforcement: enforcing policy at deployment by gatekeeping
- Continuous verification: checking running production systems are compliant
Having a ramped approach like this allows teams a lightweight way to get started, while offering a clear path towards continuous compliance.
In Summary
With BAB, Google has implemented a tech-savvy approach to security compliance automation. Adopting BAB has allowed Google to reduce insider risk, prevent possible attacks, and also support the uniformity of production systems.
At Kosli we use Artifact Binary Provenance as the foundation of our audit trails. It allows us to identify what’s running in production, and how it got there, to achieve Continuous Compliance.
