The Quest for Software Defined Cloud Governance – Introducing GSL

Preface
The missing piece – Customization
First try – General Purpose Language (aka Internal DSL)
Next try – External DSL
Meet Dome9 GSL – Governance Specification Language
The language syntax
The domain model
Execution Engine
Getting Started
Wrapping it up
Future Followup Posts

Preface
For the last 6 years Dome9 has built automated continuous monitoring and enforcement systems for public cloud users. From Security Groups tamper protection to audit trail and cloud security alerts. We even launched the Compliance Engine late last year to provide holistic cloud configuration vulnerability checks against industry best practices, common benchmarks (like CIS Foundations for AWS) and compliance standards (such as PCI).

The missing piece – Customization
Common feedback we received from our users was focused on:

– Can we filter out non relevant checks?
– Can we customize the alerts?
– Can we write custom checks that will model our own organizational requirements?

Customization is a common challenge in almost any industry and technology stack. Solving it is a fine balance of trade-offs between engineering, (expressiveness) power, integration complexity and end-user simplicity.

So the quest for customization technology has begun…

First try – General Purpose Language (aka Internal DSL)
The first stop was at “Let’s provide our users with a place to write some code that will utilize the cloud providers’ API and assert on configuration correctness”. This approach makes sense as it is powerful – you can express any computation in general purpose computing languages like Java/Python/Ruby. In fact AWS themselves are using that same approach in their Config Rules service and so does some of our competition in the cloud security and compliance space.
The downside of this approach is that you need to be a software developer to write compliance tests and assertions.

Sadly, many of the security & compliance professionals are not software developers who can write production grade code that the org can rely upon. This leads to friction-heavy cycles between the security, compliance and governance requirements, their implementation, their verification and their auditing – leaving a lot of room for miscommunication, misinterpretation – Chinese Whispers style.

Next try – External DSL
Unlike a general purpose computer language (or internal DSL), an External DSL is a custom-built language, tailored to represent knowledge in a specific domain.
By looking at competitor X’s ‘custom signatures’ – we were surprised to see that even a trivial test such as ‘check that CIFS protocol is not allowed from the entire internet’ had about 100 lines of non trivial code – dealing with AWS SDK, that platform SDK, error handling and results transformations. Phewww…

By using an external DSL we estimate we can reduce 95% of that complexity by creating a concise, minimal representation of the problem domain: security group, inbound policy, the port UDP:445, entire-internet exposure. That’s it.

External DSL allows us to build better tools and even rule-builder user interfaces, further reducing user’s friction.

On the trade-off / cons side, with less complexity we have less power. An external DSL is usually not a full blown Turing-complete programming language, so there might be complex cases that cannot be answered.

Another important aspect is the domain model. Such DSL involves specifically crafted domain model – the objects that the environment exposes. This is unlike using the raw API of the cloud providers and getting access to its entire querying capabilities.
This means there will always be some delta between what is currently available in the DSL garden and what is is available by raw cloud APIs.

Our goal was never to provide the most generic, powerful and configurable solution. AWS have successfully done this, as you might expect, in their role as a cloud infrastructure provider. We on the other hand, have the benefit of being laser focused on a different (narrower) mission – how to empower our users to express governance, security and compliance policies in the easiest and most efficient way.
Meet Dome9 GSL – Governance Specification Language

Let’s start at the end. Here is the comparable GSL rule to the previous CIFS example:

It contains 91 characters and in fact solves a much more complex problem (verifying instance’s effective security policy that is governed by its NICs and multiple attached security groups).
GSL FTW!!!

The language syntax
As a purpose-built language for cloud assertions it is only focused on this task.
Its syntax is:

<Some Entity Type> [optional filter] should <some complex expression reasoning about properties, collections etc…>

Where the entity type is the type of service / entity we wish to reason about (IAM user, Instance…)
The filter will narrow down the entities to be tested (example: Instance where tags contain [key like ‘pci’] should… do something…
The test expression: the main logic of the rule. This will check value of properties, iterate over collections and search for existence / absence of items, perform all sorts of comparisons, wildcard searches etc…
The expression syntax was inspired by SQL and the SmallTalk language, allowing to efficiently process, filter and traverse data, while having the expression readability as a main goal. The idea is that even your compliance auditors would be able to reason about your automated tests…
The complete language reference can be found here.

Some other examples:
IamUser where firstAccessKey.isActive should have firstAccessKey.lastUsedDate after(-90, ‘days’)
SecurityGroup where name=’default’ should have inboundRules isEmpty() and outboundRules isEmpty()
Iam should have passwordPolicy.maxPasswordAge>0 and passwordPolicy.maxPasswordAge<91

In addition to the language constructs that facilitate the building of even complex expressions, we have augmented the language with functions. These pre-built functions allows our users to express domain-specific computational tasks. For example : analyzing a firewall ACL list (like the one found in an AWS NACL or in an Azure NSG) and computing the ‘effective policy’ that it represents. This computation is not possible using raw GSL syntax and is very complex to achieve using general language.

This approach allows us to redefine the Power (expressiveness) vs. Complexity equation by providing a simple syntax that is augmented by specific compute heavy functions.

The domain model
The cloud entity model is usually very relational as entities are tied to other entities. For example Instance -> NICs -> Security Groups.

The Dome9 system provides a specialized entities model which has all relevant relations already populated. So back to our example – an instances entity will not only have a list of NIC IDs, but rather it’ll have a full blown relation tree – ready for the user to reason about!

Execution Engine
The Dome9 system allows the user to create ‘bundles’ which are containers of rules.
Each bundle is essentially a JSON file that contains a set of related policies – together with metadata such as name, description, severity, and more.

Some of the bundles are managed by Dome9 – in fact, these are the same compliance packages that we exposed 5 months ago as part of the Compliance Engine launch.
We were dogfooding this technology for quite some time as all our compliance packages were built using GSL.

The system allows you to execute an assessment using a specific bundle against one or more target cloud accounts to test.
Executing assessments can be done either interactively via the UI or via API, so it can be embedded in complex automated workflows.

Getting Started
Part of the Dome9 ARC product family, the Compliance Engine is a capability unto itself, as is Network Security and Advanced IAM Protection. If you are an existing Dome9 customer and do not have access to the Compliance Engine please get in touch with us.

You’ll find it in the Compliance section accessible from the top menu

Next, we’ll create our first bundle which would be the core ruleset of our corp IT.

Click on the ‘New Bundle’   button and provide some details:

OK, we now have an empty container, let’s add our first rule.
For the sake of this exercise let’s write a rule to verify that we only use hardened instance images – vetted by our security team.

Click ‘Add Rule’ and fill in the relevant info. We’ll fill the ‘Rule Logic’ field on the next step.

Now, click in the text area of the Rule Logic field.
We can type in a GSL rule, but as noobs we’ll choose the easy route – the Rule Builder.

The builder will constantly adjust its UI according to the entity / property / collection that is currently in scope.
Use the rule-builder controls until you get to something like

Now it’s time to test our rule. Select any relevant account and click ‘Test’

Wow – it seems that many of my instances are not complying…That makes sense when I’m using sample/made up AMIs…

Click one of the failing entities’ Preview links to review its properties and verify that the rule is correct. Happy? Click Done and then save the bundle.

That’s it. We now have our bundle with the first rule. Rinse and repeat to add more rules…

You can now execute your custom bundle (same as executing the canned bundles) by clicking on the ‘Run Assessment’ and selecting the relevant environments to be tested.

Wrapping it up
We are now exposing the Custom Rules EA (early availability) capability to our customers.
This technology will introduce many security and compliance professionals to the automated compliance and governance game, and will enable organizations to take their security, compliance and governance posture to the next level.

This is only the beginning and we can’t wait to show you what we are building on top of this technology stack.

Stay Tuned,
Roy and the Dome9 Security team

Future Followup Posts
The quest for continuous compliance
The quest for continuous governance, active remediation and intro to Cloud-Supervisor
The quest for static analysis of soon-to-be-deployed environments and the Rugged DevOps pipeline