Following a recipe, like baking cookies, is one way to ensure consistency in the setup and configuration of your devices and systems, which in turn, reduces the possibility of introducing new configuration mistakes that could lead to unwanted vulnerabilities exploitable by an attacker. These recipes are baseline configurations that document in detail the exact settings that an operating system, application, or device should be configured. Use these well-defined configurations to automate processes that look for variance and configuration drift in a rapid and efficient manner. In this blog, we’ll look at how configuration baselines are an important tool to ensure your applications and devices are set up appropriately.
Configuration baselines are not at all new. Systems engineers and administrators have long relied on these templates to ensure that every system is configured identically. Prescriptive guidance, provided by system manufacturers and other subject matter expert groups, is an important place to start to ensure that your configurations are designed with security in mind.
Configuration baselines define how a specific type of device must be set up and are very detailed down to each input and variable. For example, configuration baselines define how to configure remote access to a device and what protocols to enable. Leveraging baseline configurations should reduce the overall operational costs of your devices because they ensure homogeneity across your fleet, which in turn, facilitates configuration through automation and other time-saving methods. It is expected that if one device works well with a specified configuration, the rest should behave in the same way. Proper configuration baselines improve security as well because through their development, they require a detailed review of every setting and often will result in a change of a device’s default behavior to a more secure posture depending on the use case. As a device operator, you can study and review the prescriptive guidance from one source, and then extend this knowledge to create appropriate baselines for similar devices from different manufacturers. This comparison method also highlights differences in capabilities between devices and may even influence which devices you choose based on their security features. Configuration baselines should include how to set up these security features and ensure that the devices and systems are appropriately hardened from attack. Take remote access for example, many devices support remote access for allowing system administrators and developers to configure them over the network. It is common for a device to support multiple protocols—e.g., telnet, secure shell, and web browser access—but not all these protocols are equally secure. For the most secure configuration, you would want to favor encrypted protocols that support modern authentication methods and disallow others.
Ensure your baselines support your organization’s security requirements and obligations by linking them to your security policy and standards. Your security policy is the cornerstone of your information security program and defines at a high-level what behavior is allowed and what is not. A good security policy is broad and covers multiple security domains relevant to your company or organization. Whereas the policy is broader and higher level, the information security standards dive deeper into each policy area. For example, you might include a single paragraph or two in your policy describing appropriate authentication principles but dedicate an entire five to six-page standard that describes in much more detail the approved protocols and permissible use cases and systems supported by your organization for these authentication services. The configuration baselines directly support the policy and standards and include the actual settings for how to set up the devices to use these systems. Lastly, you might choose to document appropriate procedures that complement the standards and baselines that include broader instructions on how to configure more complex systems and devices.
In our previous remote access example, the policy might describe the requirement for all devices and systems to encrypt network communications and require authentication for privileged access. Supporting standards would specify secure shell (SSH, over TCP 22) and hypertext secure protocol (HTTPS, over 443) as approved remote administration protocols and WS-Federation, Security Assertion Markup Language (SAML 2.0), and OAuth as approved authentication standards. Every type of device and system in your organization would have a unique configuration baseline created for it that defines the device-specific configuration settings that enable the device to support these standards. Configuration baselines can take many forms. The most simple is a table that lists every configuration element of a device and its preferred value. An illustrative baseline might include screenshots of configuration dialog boxes to make it easier to manually set up. To reduce the chance of configuration variance between devices, be sure to explicitly define how each checkbox, radio button, and field should be set. For larger installations, look for opportunities to automate the configuration through Application Programming Interfaces (APIs) or commands exposed by the device. Most enterprise network equipment is configured in this way. You can create a text file or XML document that includes all important configuration commands and settings and load this file into the device to ensure the equipment is configured in exactly the right way.
These configuration baselines are auditable. Many organizations use a redacted configuration file to demonstrate the secure configuration of a device to an auditor. Some vulnerability scanners like Qualys or Nessus can be configured to scan for configuration settings in addition to their vulnerability signatures. As a part of a broader Information Security Management System (ISMS), it is important to demonstrate not only that your devices are configured appropriately but that the configurations align with your security policy and program and these configuration baselines do just that.
You will likely find more diversity in creating configuration baselines for on-premise infrastructure than cloud-based services due simply to the variety of devices and systems offered by multiple manufacturers. Look to these manufacturers of the operating systems and large enterprise applications that you use for configuration best practices. The major cloud service providers expose APIs for their entire configuration, so it becomes much easier to write scripts and programs to quickly deploy a new system configured exactly how you want it and just like your others. Microsoft has published recommended security configuration settings for their current operating systems, which they offer as a download from their website. This zip file includes thousands of recommended settings to secure these systems. The Center for Internet Security offers a free download of recommended security configurations for a wide variety of operating systems and applications including Microsoft Windows, Linux, iOS, Apache, Docker, Microsoft SQL Server, Oracle, and many others. These resources are free and a great starting point for identifying important security configurations that you can customize to your environment.
Security configuration baselines help ensure that your devices and systems are set up in a secure and repeatable manner. Especially in larger organizations, where multiple people may be responsible for setting up devices, these documents ensure not only that the devices are set up appropriately and securely, but later provide a checkpoint to audit for configuration drift over time. Configuration baselines are a complementary component to security updates in a comprehensive and effective vulnerability management program and an important tool for system administrators and developers alike.
Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop.
Ver versión para móviles
Centro de privacidad |
términos y condiciones
Mapa del sitio
Derechos reservados ©2023 Mouser Electronics, Inc.
Mouser® y Mouser Electronics® son marcas de Mouser Electronics, Inc. en los EE.UU. y/o en otros países.
Todas las demás marcas son propiedad de sus respectivos dueños.
Sede corporativa y el centro de logística en Mansfield, Texas USA.