How OPA Helps Simplify Compliance and Create Custom Compliance Rules
Compliance with regulatory standards is essential for cloud environments, not only to meet legal requirements and to meet security and trust standards, but also to manage risk and data governance. All organizations operating in the cloud must demonstrate verifiable proof of such a robust security program. To do this means complying with multiple compliance regulations across cloud service providers.
When it comes to compliance, it can be a tedious and manual undertaking to ensure that all regulatory requirements are met. However, to ensure more seamless compliance application and to allow for custom compliance capabilities, Lightspin has been using policy as code, and more specifically Open Policy Agent (OPA) to simplify and streamline this process for organizations.
What is Policy as Code (PaC)?
Policy as Code (PaC) is an approach to managing policies that treats them as code, which can be versioned, tested, and managed using software development best practices. PaC involves writing policy rules in a high-level programming language, such as JSON or YAML, which can be evaluated and enforced by a policy engine.
The goal of PaC is to improve the efficiency and effectiveness of policy management by applying software development practices, such as version control, automated testing, and continuous integration, to the management of policies.
PaC enables policy rules to be defined and managed in a consistent manner while allowing policies to be developed, tested, and deployed with greater speed and accuracy.
What are the benefits of PaC?
- Consistency: PaC ensures that policies are consistently applied across different systems and applications, reducing the risk of non-compliance and security incidents.
- Efficiency: PaC enables policies to be developed and deployed quickly and efficiently, reducing the time and effort required to manage policies manually.
- Scalability: PaC can be used to manage policies across many systems and applications, making it easier to maintain consistency and compliance.
- Automation: PaC enables policies to be evaluated and enforced automatically, reducing the risk of human error and ensuring that policies are always being applied correctly.
One example of PaC in practice is Open Policy Agent (OPA). OPA uses Rego, a unique language that can encode policies and runs as a service. OPA is an open-source tool that in their own words “is purpose built for reasoning about information represented in structured documents. The data that your service and its users publish can be inspected and transformed using OPA’s native query language Rego.”
Why use OPA and Rego?
The Lightspin Team started to see that to meet compliance requirements many different organizations were working in OPA and writing in Rego, making it a logical move to also adapt this engine.
OPA and Rego simplifies the ability for Lightspin to write and quickly check compliance rules. OPA’s Rego language can easily can be used to find data in a JSON file or document. It also provides flexibility so that Lightspin can easily scan rules and ensure they meet the compliance requirements whether they are written in JSON or Python. OPA’s Rego rules can run against the relevant doc types per language so new rules don’t need to be constantly rewritten per format.
To use OPA, developers do need to learn an additional language, but Rego is easy to learn and extends support to structured documents like JSON. Below are two examples of how the Lightspin team has applied Rego rules:
AWS – Minimum password length should be 14 days or higher
AWS – Check whether the server certificate has expired
While Rego rules are more restrictive in terms of how developers can write their code than with other languages, Rego rules are more unified and therefore have more agile and universal applications. Rego rules can be used to find data – in a JSON or document. As such, Lightspin can add a Rego rule and then is able to save each result and aggregate them. For instance, if an organization has 100 accounts and we want to check that all accounts have MFAs in place, the Rego rule can run and check whether this is true. If 30 out of these 100 accounts have MFAs enabled, the organization would be 30% compliant to this regulation. Rego rules will go through compliance requirements one by one, across clouds and across regulation types – whether GDPR, HIPAA, CIS, PCI, SOC2, and more – and the rule needs to be written only once and then applied across all.
Lightspin’s approach to compliance
Lightspin looks at compliance as a combination of engineering and research tasks – it takes time to understand how compliance rules and regulations should be set up and applied to each cloud service provider (CSP). The team then must examine if for each CSP we are already collecting relevant data to answer the specific compliance requirements, and if not, new collectors will have to be created.
This approach powers Lightspin’s ability to examine the most pertinent cloud compliance requirements, and by using OPA, Lightspin can create custom compliance much more easily.
What do we mean by custom compliance?
Compliance is an essential aspect of operating in the cloud. However, some organizations want to be able to make specific rules to apply to their internal users – that may be more granular than the broader compliance considerations.
Lightspin’s approach to compliance through use of OPA means that we can more easily create and apply custom compliance. Customers can write their own rules and they save them in their tables, and then Lightspin can apply and scan for these rules.
For example, an organization may determine that they want their users to change their passwords every 90 days. The end user in the organization can create a rule, check their syntax, and then run it against existing assets. This rule can be saved and then applied to every Lightspin scan of their environment. The beauty of using OPA in this instance is that it allows for much more agility and the ability to make changes dynamically – there is less permanency to the code. With Python for example, making edits or updates to the code would require changes to the core code of how the platform is constructed and would therefore be far more complicated to apply.
Compliance with context
It is important to bear in mind that being compliant doesn’t mean your organization is secure. While Lightspin helps organizations meet their compliance requirements, compliance risks are anticipated threats. Attackers see through compliance to locate the weaknesses within. They take advantage of configuration vulnerabilities caused by weak configurations and misconfigurations in the cloud, akin to the exploitation of application vulnerabilities due to oversights and bugs in code. With Lightspin, users are provided the ability to further investigate each security group in their environment and determine if it needs to exist. Lightspin’s quick visual cues help bring focus and clarity to security and compliance frameworks.
Ready to get more information and see how Lightspin’s approach to compliance can help you better secure your environment?
Set up a demo today to see the Lightspin difference
*** This is a Security Bloggers Network syndicated blog from Lightspin Blog authored by Becca Gomby. Read the original post at: https://blog.lightspin.io/how-opa-helps-simplify-compliance-and-create-custom-compliance-rules