Prevent human error in security: Dave meet STIG, STIG meet Dave

My Linux product consists of many security features, each of which, when added to a running embedded Linux system, can increase security. It is also monitored against security vulnerabilities, so it should be fail proof, right? Well, like the security features shown in the cartoon, any of them can easily be defeated by ‘Dave.’  But this doesn’t mean that they don’t have value.

But for that value to be realised, the features need to be used.  Firewall logs need to be reviewed.  Login records need to be analysed.  Configuration options need to be specified in ways that are secure.

All those things are driven by procedures and policies.  If there are no security-focused procedures and policies for the people interacting with the computer to follow, then many of even the most useful security features fall below the cost effectiveness line.

Those procedures and policies fall into what I call the certification layer. Every good security-based design includes multiple, independent layers of security. And certification is one of those layers, even though it does not necessarily correspond to any code running on the system.

The certification layer consists of a review of the system itself, the environment, and the operating procedures used in conjunction with the deployed system.  For me, the actual certification that you get at the end is the least important aspect.  That simply shows others that it has been reviewed.  But the selection of components included in the system, how the system interacts with the environment, and the procedures used to monitor the system are all extremely important for high assurance of system security. And having an expert review those things is certainly worthwhile.

Certification can be very expensive.  But most of the benefits of certification can also be achieved by use of a STIG, or Security Technical Implementation Guide, for system configuration.

STIG technologies were developed based on requirements from DoD and DISA to maintain security of IT infrastructure.  Currently, STIGs, along with other NSA Guidelines, are the configuration standards for DOD IA and IA-enabled devices and systems.  A STIG, combined with the associated SCAP implementation (Security Configuration Automation Protocol), provide industry best practice system configuration details to lock down the system.  Automated packages such as OpenSCAP provide tools to test compliance, mostly automatically.  Here is an example OpenSCAP output from Wind River Linux Security Profile:

With the overwhelming number of connected devices, STIG requirements are designed to meet common security requirements across multiple industries. From power grid to automotive, medical, industrial, and more, Wind River is following this industry best practice, helping ensure that our products are always kept safe, even in the event of human error.

Courtesy of Wind River.