The software we use in our smartphones, tablets, or desktop pcs is configurable. Through these configurations, we can make our systems more personal, e.g., with a cool background, more efficient, e.g., with a speed-up option, or more secure, e.g., by deactivating insecure protocols. Software vendors do not configure their software as secure as possible in the default configuration. For most customers, ease of use is more important than security. Hence, it is also more critical for the vendors.
Let us assume that there is a securely configured instance of a system and an insecurely configured instance. In the securely configured instance, the customers first have to activate some functions before using them. In the insecurely configured instance, everything is activated by default. If average customers had to decide between those two instances, most would opt for the second option because it is more convenient than the secured option.
Often, the insecure configuration of systems is regarded as a small threat to a system’s security. This statement might be tempting, but we can easily falsify it, e.g., by looking at the last OWASP TOP 10 of web application risks; security misconfiguration is in the 6th place of all risks. Additionally, most data breaches and ransomware attacks result from inadequate security configuration.
So systems should be configured securely, but the administrators dealing with the secure configuration of software systems name several significant factors for misconfiguration, e.g., lack of knowledge, time pressure, and manual configuration. One attempt to deal with the lack of knowledge is to use publicly available security-configuration guides published, e.g., by the Center for Internet Security (CIS). Nevertheless, we have to implement the guides manually and adjust them for our infrastructure.
In this project with the Siemens AG, we are working on approaches and tools to overcome these problems.
One significant problem of security-configuration is that the existing guides focus on the automatic assessment of the system’s security. However, we have to implement (or apply or remediate) the guide on the systems manually based on the guide’s text. This is a time consuming, expensive, and error-prone process. Thus, we have developed an approach that uses natural-language processing to extract the guide’s essential parts. Furthermore, we can extract knowledge about existing configurations and valid values for those from definition files. We use this knowledge to validate and sanitize the guide’s extracted parts to ensure that we implement the guide’s rules correctly. Moreover, we developed a proof of concept for Windows-related security-configuration guides. We demonstrated that our PoC could extract and implement 83% of the rules of a publicly available Windows Server 2016 guide without any manual effort. In an extensive study with 12 state-of-the-art guides of the CIS, we show that our PoC implemented 97% of the 2014 rules correctly.
For more details about our approach, please refer to: P. Stöckle, B. Grobauer, and A. Pretschner, Automated Implementation of Windows-related Security-Configuration Guides, Automated Software Engineering Conference (ASE), 2020
You can find the Windows Server 2016 guide and a Windows Server 2019 version on GitHub and on Software Heritage under the tag 4dca8abd816ea99f5ce06cfc05aa9da86ef3a9b2 respectively 13ffd9d2566c64afdedd414336a95a35605392d7.
November 2017 - October 2021