Review: How InSpec 2.0 delivers comprehensive compliance

Over the years, many government agencies, regulatory groups and even industry organizations have created compliance rules that govern how technology should be configured for a certain task or network. For example, any merchant that uses credit cards must become compliant with the Payment Card Industry Data Security Standard (PCI DSS). Healthcare providers must submit to Health Insurance Portability and Accountability Act (HIPAA) rules. And anyone who does any business within Europe now needs to comply with the General Data Protection Regulation (GDPR) or risk major fines. Even if there are no specific regulations imposed within a sector or on a business, there are quite a few well-written best practices like the NIST Cybersecurity Framework that can benefit any organization.

The problem with most of these regulations and guidelines is that they can be difficult to interpret, much less successfully implement. Some of the statutes are comprised of iron-clad rules that almost seem designed to make technology implementation more difficult. Others are fuzzy, commonsense sets of advice with little real-world guidance on how to achieve them.

The InSpec 2.0 platform from Chef is designed to both make sense of regulatory and technical guidelines and ensure that a network is protected according to those rules. Almost every other program that CSO has reviewed that included compliance had it as an extra, almost a bolted-on addition behind security. InSpec 2.0 instead looks at compliance as its primary mission, tailored to the specific rules and guidelines that a company wants or needs. And while compliance does not always equal security, most guidelines exist for a reason, so getting every server, endpoint and app into compliance with relevant regulations is, if nothing else, a great starting point in achieving robust cybersecurity.

InSpec 2.0 can be installed in several different ways. If an organization is using the Chef Automate program to configure its nodes, InSpec can work with those installations that essentially become agents for the program. But agents aren’t required. We tested InSpec using a single installation of the program running on a workstation, and used it to scan a large test network. All we needed was the credentials for the machines being scanned. And InSpec was quick too, returning queries about 300 compliance issues across dozens of clients in just a few seconds.

Pricing for InSpec 2.0 is currently based on the number of nodes being protected and scanned for compliance issues. However, now that InSpec supports cloud deployments and virtualization environments where new nodes can be spun up and dropped from the network continuously, which was one of the new features added in the 2.0 product, the company admits that its pricing model needs to be updated and something new will be coming, but was not quite ready at the time of this review.

Getting started with InSpec 2.0 was not difficult, though it did require a baseline understanding of coding, or at least the general principles of programming. Out of the box, there were 98 various compliance profiles in the online repository that customers could apply to their InSpec consoles. These compliance profiles are sets of queries designed to help achieve parity with all of the major certifications, regulations and best practices currently in use today. The program does a very good job of explaining what guideline is being tested against, and sometimes more importantly, why specific tests are recommended.

John Breeden II / IDG

Queries are basically simple programs designed to test one aspect of a compliance statute. For example, a best practice when using cloud environments is to have folders in place to house secret and confidential files that are separate from your public folders. To test if a set of folders exists is the first part of a simple query. Then the same script also checks to see if they are properly configured. Such a query would look like this for an Amazon Web Services (AWS) cloud deployment:

describe aws_s3_bucket(bucket_name: 'my_secret_files') do  it { should exist }  it { should_not be_public } it { should have_access_logging_enabled } end

In this example, a node would fail compliance if the secret folder did not exist, if it was flagged as public, or if access logging to the folder was not enabled.

A query like this can be selected from a pre-installed list within a compliance profile and then sent out to a node or a range of nodes by InSpec 2.0. Users who know code, and who are intimately familiar with compliance regulations can create their own queries easily enough using the above format. There is also a robust community of users who submit both queries and full compliance profiles to a community site to be shared. Chef evaluates the community-created content and provides metrics about how many people are using each submission, and if it’s fully compatible with the program.

John Breeden II / IDG

Reports are straightforward, with results grouped by severity. In the example above, having the secret folder set as public would be more of a problem than simply not having access logging turned on, so administrators can fix the most important issues first. There is also a more graphical overview layer, so that executives can track how their organization is doing in terms of compliance without needing to be an expert on the regulations or technology involved.

John Breeden II / IDG

InSpec 2.0 improves on the original program in a few major ways. The first is that it works with AWS and Microsoft Azure cloud deployments, even going so far as to enable scanning of all assets within a public or private cloud at the same time. Second, because it allows for application-level scanning, it empowers security groups to scan for compliance issues on apps while they are still in development. This way, apps can be verified as fully compliant with all relevant regulations before they are even deployed. The new program also enables scan schedules, so networks can be scanned for compliance issues on regular intervals, which is particularly important in cloud environments or advanced infrastructures using software-defined networking that are constantly in flux.

Most companies end up scrambling during the weeks leading up to scheduled compliance audits, trying to do too much at once and likely compromising some security for the sake of rapidly patching compliance issues. Or they simply fail at compliance, only realizing that they are in danger following an attack, or after getting an unpleasant notice from a government regulator.

John Breeden II / IDG

Chef’s InSpec 2.0 can completely change that situation. It enables incremental compliance to build up over time, and prevents compliant nodes from slipping back into non-compliant states, or new nodes and apps from breaking those hard-fought compliance certifications. Neither surprise nor scheduled compliance audits would generate any stress because organizations would know exactly where they stand on compliance at all times.

In a way, a program like InSpec can help make compliance achieve what it was designed to do: act as a baseline and bulwark for true cybersecurity. It does this by breaking down cryptic compliance standards into real world, practical suggestions regarding technology configurations, and then constantly testing to ensure that the standards are always upheld. Using a program like Chef’s InSpec 2.0 will not only keep organizations from violating complex rulesets like GDPR or HIPAA, but can improve cybersecurity standards across an entire enterprise.