With the changes in EU regulation that GDPR introduces, specifically relating to the processing of EU citizens’ personal data, organisations are facing fresh challenges in how they prove compliance. GDPR brings particular burdens with the ‘Privacy by Design’ mandate that requires data privacy be part of the system design process from day one.
In previous GDPR blog posts I’ve spoken a lot about specific use cases, such as GDPR scanning in an application delivery pipeline. In this post, I will describe how the InSpec language makes it incredibly easy to develop your corporate compliance profile over time, adding additional standards as they become relevant for your business. This approach makes it very simple to include a GDPR standard, or superset of, in your existing InSpec based profiles.
InSpec, the open source testing and compliance framework from Chef, allows us to define traditional security controls in a high level, human readable language. We can then execute these control code blocks against our various systems (servers, containers, virtual machines) to audit and report on their state.
As you can see in the example below, the controls often found in standard documents, very easily map into the InSpec language.
By grouping these executable security controls together we can form ‘profiles’ reflecting a security standard; either an in-house security baseline, or perhaps an industry standard such as PCI DSS, or ISO 27001.
To learn more about how InSpec can execute audits against your systems, check out this video on GDPR Detection and Correction:
Once an organisation begins to redefine compliance requirements in InSpec code they’ll gain from the following:
For me, the stand out benefit is the ability to adapt quickly to change as new security requirements impact a business. GDPR is a perfect example of this. Organisations need to move quickly, but adapting to GDPR can be time consuming. By evolving existing processes, especially InSpec based auditing, it’s possible to remain agile without compromising on security.
InSpec’s flexibility is a huge benefit. It natively supports inheritance, control skipping, and customisations- as you would expect of any code base! It’s very easy to include community and Chef supported test sets (profiles) in an existing InSpec code base.
By taking this approach, adding GDPR specific tests to a profile is quick and simple allowing GDPR auditing to form part of your existing auditing process.
Learn more about profile structures in the Compliance Automation track on Learn Chef.
Here’s an example of how you would add a (sample link in this case) GDPR profile to an existing InSpec profile.
Firstly, add the following to the profiles inspec.yml file.
depends: - name: gdpr-example url: https://github.com/grdnrio/gdpr-example/archive/example.tar.gz
Now that the dependency is specified it’s possible to include the upstream profile into a set of tests.
include_controls ‘gdpr-example’
When executing a compliance scan the external GDPR profile will be retrieved from the remote location specified, for example GitHub.
Now GDPR scanning will automatically be applied as part of an InSpec and chef-client based auditing process.
By redefining our compliance requirements in InSpec code we can easily apply auditing at scale, and on a very short scan cycle. We also have the flexibility that comes with any code base – it’s simple to make changes.
What makes InSpec special is the ability to pull in profiles from any location to immediately make them part of an audit and testing lifecycle. By applying this principle, adding GDPR scanning to your existing efforts becomes trivial.
You can find an example of profile inheritance here: https://github.com/adamleff/inspec-profile-wrapper-example
Stay tuned for updates about GDPR testing profiles from Chef.