Computer security is problematic today, is expected to get worse for years to come. The security field is widely acknowledged to be suffering from a shortage of qualified security experts. Many people believe that significant improvements in automation are the only way to address this growing problem. Compared to the level of automation that system management has experienced in recent years, security has been estimated to be at least a decade behind.
For a variety of reasons, the security community is reluctant to share information around attacks, incidents and responses. These include legal reasons, public relations reasons and a certain amount of general paranoia that comes with the territory. By contrast, comparatively few barriers exist with respect to sharing hardening and other security best practices. There are a number of collections of security best practices – some are freely available (like NIST STIGs) and a few are available for a fee, and some are integrated into commercial tools. However, none of these sources is an open community with the ability for a wide variety of experts to quickly collaborate, create and curate a common body of mechanically-observable security best practices.
Automating IT Best Practices
The IT Best Practices project was created to help support security automation efforts. We aim to collect, categorize and curate mechanically-verifiable best practices for servers, services and networking, in support of the idea of “best practices as code”.
This collection of best practices will help projects like Assimilation and Lynis and SecComFrame have a common source for mechanically-verifiable best practices in one place. Such best practices are key to providing more automation in security validation.
Odd as it may seem, validating best practices is much simpler than explaining them. The hard work is in collecting the text that explain what a particular practice is, why it matters, and how to bring yourself into compliance with it, and to provide translations in multiple languages. Since each implementation to actually validate best practices is going to be different, we’re collecting the descriptions of best practices, and how to correct them rather than the code to validate them.
Although our interests are primarily security-related, the community is open to all kinds of mechanically-verifiable best practices.
Even though they aren’t doing much yet, we’ve purchased the domain name itbestpractices.info for the project, and we have a placeholder README in our GitHub project. You’ll likely notice a strong correlation between the README and this article ;-).
We are starting this effort to support the idea of “best practices as code”. The DevOps meme “infrastructure as code” meant that your configuration was more reliably set up in a consistent way – but there were no concept that systems and services were set up in a good way – just a consistent way. Our “best practices as code” initiative bridges that gap, by providing a set of best practices to compare your infrastructure and configurations to, and in the end, tools which help you do that.
Concentrating On Security Best Practices
Given that security is a significant problem, it is no surprise that we’re initially concentrating on “security best practices as code”. Verifying that a particular practice is followed is typically as simple as checking to see that a particular feature is turned off or on, or that some value matches some regular expression. As noted before, explaining these best practices is typically much more time-consuming, with paragraphs of text to explain a single line of code.
This allows us to share the difficult work of explaining these practices, and avoids arguing about the best method for implementing these checks. It also leaves each participant free to innovate on what implementation best fits their customers and their visions.
While we get underway, we’re discussing this on the Assimilation mailing list. We invite you to join us in kicking off this important new open source project. We also encourage you to attend our presentation on it at OSCON 2015 in July. You can save 20% off the normal rate with this code: ALANR20. Check out the agenda and speaker lineup at http://oscon.com
I think the idea of “security best practices as code” is a good one.
But (you knew something else was coming), my requirements at a medical device company include more than making systems secure.
It also includes showing that they are secure according to accepted international standards, such as the ISO/IEC 27000 series of standards on information security and ISO 14971 on application of risk management to medical devices.
I will be interested to see how we could accomplish both goals with these tools.
Most security standards include things you can’t verify mechanically, and of course, we can’t deal with those. For the rest, there are not likely to be any technical issues involved in verifying more rules – just because they’re part of a standard.
But for those things that *are* mechanically verifiable, if the standard isn’t freely available, then that makes it more complicated from a legal perspective. The intent is to have tags on rules that say what standards they are part of. If they are recommended by multiple places, then that’s OK. But if the license on the relevant standards doesn’t allow us to disclose what the requirement are, then we can’t legally tag the rules as belonging to that standard.
This winds up depending on the terms and conditions of the various standards. One could imagine a variety of legal issues depending on the particular standards body and their terms and conditions.
What do you know about the terms and conditions of the standards bodies you care about?