Self-Regulating

Discover Possibilities

The examples referenced thus far have deliberately been kept as simple as possible so as not to unnecessarily stress InSpec newcomers. The feature scope of the software is fairly large, as you can see by looking at the list of resources [3] already included with InSpec. These resources include line-by-line interpretation of most common configuration file formats, as well as sample code for classical Linux services, along with ready-made modules for a variety of services from the systemd universe (e.g., for firewalld). The health state of the packaging system can be checked on RPM- and DEB-based distributions with the yum and apt directives. Many resources for legacy security topics like SELinux are also included. With on-board tools, InSpec can test automatically whether an administrator has switched SELinux to permissive mode on a target system (i.e., whether it has effectively been disabled).

The newer InSpec versions, in particular, offer many features for public cloud environments. Compliance extends over several levels. Both the account in the cloud environment and the workload running under the account need to be compliant. For AWS, Google Cloud, and Microsoft Azure, various factors of the cloud environment can be checked automatically for compliance.

Don't Reinvent the Wheel

Up to this point I have described how InSpec works and how to create profiles for your environment. However, before you start from scratch and build a complete environment, you might first want to step back. New code is rarely more stable than its predecessors, and InSpec has many prebuilt profiles online that offer a basic set of features, thanks mainly to the DevSec project, a group of admins who offer basic compliance checks in the form of their baseline directories for both Windows and Linux. For some additional services such as PostgreSQL, the project's GitHub contains additional baseline modules that also check basic facts. Even better, if you discover that your systems do not or do not fully meet the current compliance standards in Linux, you will also find Cookbooks for Chef or Playbooks for Ansible that help you resolve the worst problems.

InSpec can't do everything (e.g., define compliance rules that the software needs to monitor). In larger companies, the majority of the specifications will come from central policies, and some places even have InSpec profiles for internal rules. Where this is not the case, the admin needs to put some thought into creating profiles. However, you do not have to reinvent the wheel. The Linux Foundation offers a free manual [4] for compliance on Linux systems, which contains many important basic rules, along with many other instructions and tips for compliance under Linux on the Internet, especially in the context of certifications such as government-mandated auditing procedures, IT security standards for cloud computing, or the Payment Card Industry Data Security Standard (PCI DSS), which has a detailed manual [5] from Chef (Figure 4).

Figure 4: Chef explains in a guide how InSpec monitors systems for PCI DSS compliance.

Conclusions

InSpec proves to be a practical tool for automated monitoring of compliance on systems. The tool makes compliance easy for the admin. Chef delivers InSpec with ready-to-use parsers for the configuration files of common services, and the framework's declarative script language is quickly learned because it is very intuitive. The major part of the admin work consists of mapping your own compliance requirements. And even here, the baseline repositories with basic compliance tests do part of this work. If you are gearing your compliance for specific certifications, local compliance institutions or Chef can help you set up additional protections.