Chef Software’s InSpec 2.0 Compliance Automation Tool Helps Organizations Maintain an Up-to-Date View of Compliance Status
Software developers are urged to include security throughout the development cycle. This requires testing for compliance with both house rules and regulatory requirements before an application is released. Compliance testing is difficult, time-consuming and often subject to human error.
A January survey by Seattle-based software automation firm Chef Software shows that 74% of development teams assess for software compliance issues manually, and half of them remediate manually. Chef further claims that 59% of organizations do not assess for compliance until the code is running in production, and 58% of organizations need days to remediate issues.
Now Chef has released InSpec version 2.0 of its compliance automation technology. InSpec evolved from technology acquired with the purchase of German startup company VulcanoSec in 2015. The latest version improves performance and adds new routines. Chef claims it offers 90% Windows performance gains (30% on Linux/Unix) over InSpec 1.0. New in version 2.0 is the ability to verify AWS and Azure policies (with the potential to eliminate accidental public access to sensitive data in S3 buckets); and more than 30 new built-in resources.
The S3 bucket compliance problem is an example of InSpec’s purpose. Earlier this month, two separate exposed databases were discovered in AWS S3 buckets. Last week, FedEx was added to the growing list, with (according to researchers) a database of “more than 119 thousands of scanned documents of US and international citizens, such as passports, driving licenses, security IDs etc.”
In each case — and the many more examples disclosed during 2017 — the cause was simple: the databases were set for public access. The potential regulatory compliance effects, however, are complex. Just the EU General Data Protection Regulation (GDPR, coming into effect in May 2018) would have left FedEx liable to a fine of up to 4% of its global revenue if any of the ‘international citizens’ were citizens of the EU. FedEx revenue for 2017 is approximately $60 billion.
In all cases the cause was most likely simple human error. But this discloses a bigger problem within secure and compliant software development: it involves multiple stakeholders with different priorities and, to a degree, different languages of expression. “Compliance requirements are often specified by high level compliance officers in high level ambiguous Word documents,” explains Julian Dunn, Chef’s director of product marketing.
“But at the implementation level you have the DevOps folks who are in charge of the systems — but they don’t understand ambiguous Word documents. What they understand is code, computer systems and the applications. There’s a failure to communicate because everyone uses different tools to do so — and that just slows down the process.”
InSpec 2.0 can verify AWS and Azure policies (with the potential to eliminate public access to sensitive data in S3 buckets); and more than 30 new built-in resources. It provides a simple easy-to-understand code-like method of defining compliance requirements. These requirements are then regularly checked against the company’s infrastructure, both cloud and on-prem. A few lines of this code language would solve the S3 bucket exposure problem: “it { should have_mfa_enabled }” and “it { should_not have_access_key }”.
Another example could be a database that compliance requires has access controls. For a Red Hat Linux system, the InSpec code would include, “control “ensure_selinux_installed” do”, and “it { should be_installed }”.
InSpec then regularly checks the infrastructure and detects whether anything is not compliant or has slipped out of compliance with the specified rules. It is part of the InSpec cycle that Chef describes as ‘detect, correct, automate’. Detection provides visibility into current compliance status to satisfy audits and drive decision-making; correction is the remediation of issues to improve performance and security; and automation allows for faster application deployment and continuous code risk management.
“We help the customer in the automate phase with pre-defined profiles around the common regulatory requirements,” explains Dunn. “But InSpec is fundamentally a generic toolkit for expressing rules and positive and negative outcomes from those rules — so it deals with everything from soft compliance (rules of the house) all the way through to GDPR, PCI, SOX and so on.”
But there is a further benefit. Software development has embraced the concept of DevOps to avoid siloed software development and deployment. Increasing security compliance regulations are now driving the concept of DevSecOps, to bring the security team into the mix. InSpec automatically involves security and compliance with the code development process — a fully-functioning DevSecOps environment able to improve rather than inhibit the agility of software development is an automatic byproduct of InSpec 2.0.
Related: What Security Teams Need to Know about DevOps
Related: Where DevOps Could Be Increasing The Attack Surface
