Exploring security by design and loosening guides

The concept of security by design, which includes the concept of security by default, is not new. In fact, secure by design is considered one of the fundamental principles of secure development. In general, we say there is security by design or security by default when, from the user’s point of view, security is included and enabled without doing anything specific or changing the factory configurations. The Cybersecurity & Infrastructure Security Agency (CISA) has recently developed this concept further, and at Red Hat we are embracing it in our products and cloud services.

****Secure by default products****

Secure by default products are those that provide a high level of security “out of the box,” requiring few, if any, configuration changes. This means, for example, that all known and potentially dangerous configuration options that could facilitate breaches are disabled by default. Another typical example would be to avoid using weak cipher suites —secure by default products implement and allow only cipher suites that are known to be secure by default when feasible.

CISA developed the following criteria to identify a product as secure by default:

• Eliminate default passwords: The product should not have default passwords.
• Conduct field tests: Understanding how users manage the software and its security settings will help you improve its design.
• Reduce hardening guide size: Any security-forward options should be enabled by default and insecure ones disabled. There should be no need for hardening guides, as the defaults and interface should establish the correct level of security.
• Actively discourage use of unsafe legacy features: Prioritize security through clear upgrade paths over backwards compatibility.
• Create secure configuration templates: The product should be released with configuration templates to achieve a high level of systems security if needed.
• Implement attention grabbing alerts: When a user tries to enable an insecure option, they should receive a clear and informative notification about the associated risk directly in the interface.

Secure by default products are built to help protect against attacks without requiring high configuration efforts and high expertise from users. This is not something that can happen overnight, but at Red Hat the dedicated Product Security team is working together with engineering teams to bring our products and cloud services to the highest possible standard.

****New and existing software****

In order to build secure by design products, software manufacturers and developers should embrace secure development practices from the beginning of the product development process. These are practices such as threat modeling, security architecture reviews, developer training, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), penetration testing, and other secure development practices. Security in products is a byproduct of these efforts, not something obtained solely by doing a security review at the end of the development process.

In the case of existing products, it is possible to make them secure by design by evolving them to meet these security principles over multiple iterations. It requires effort, but it is possible with a good plan and commitment from the development team.

****Benefits****

Secure by design products benefit both users and developers. From the users’ perspective, they strengthen their overall security posture and help facilitate their compliance efforts. For software manufacturers and developers, they lower maintenance and patching costs in the long term because the software is more resilient to software vulnerabilities.

All of the Red Hat’s effort towards security by design impacts not only the security posture of Red Hat products, but also on the security posture of the open source ecosystem at large due to our working principle of “upstream first.”

****Frictionless software****

Another theoretical property of secure by default products is that hardening guides do not exist or are minimal because the product is as secure as it can be by default. This is a utopian scenario, but it should be our goal.

Software manufacturers and developers should help users to try to reduce the complexity of securely configuring a product. Products should provide as much guidance, automation and other mechanisms as necessary to support users when adapting a product’s deployment and configuration to their unique environment. Secure by default products are designed so users are aware when they are trying to change the configuration to insecure options, so they do not have to fully review, understand and process complex configuration instructions.

A good example of a mechanism for products in being proactive about insecure configurations is building “nudges” into the products rather than relying solely on administrators time, expertise and awareness in interpreting hardening guides.

The goal of producing frictionless software influences not only how we practice security at Red Hat, but also how we build it into our products. One example is, Red Hat Ansible Lightspeed with IBM watsonx Code Assistant, whose main objective is to help automation teams to be more efficient.

****Loosening guides****

Of course, there are challenges to adopting secure by design principles. For example, disabling some insecure options may make the product more difficult to configure or run initially, leading to customer frustration and more calls to support. Additionally, there are situations where users need to use less than ideal configurations, such as when supporting backwards compatibility.

In these situations, the users should be made fully aware of the risks and should be provided with recommendations for compensatory controls. When installing a secure by default product in an environment that requires an insecure configuration due to backwards compatibility, it might happen the product wouldn’t work for them in the first place because these secure configurations are applied by default.

In these cases, users could have “loosening guides” —the opposite of hardening guides. As secure configurations are the default, these loosening guides can help the users modify the configuration of the product to match their specific needs, while also being informed about the associated risks. This approach means that deliberate effort is needed to reduce the security posture of the product, instead of requiring extra effort to apply additional security measures as recommended by a hardening guide.

****Wrap up****

As software developers, we should take responsibility for designing and implementing software that is secure by default and easily understandable by users. It would not be acceptable for a product to simply have all the security options enabled, as that could make it impossible for the customer to use it. In this paradigm, user interfaces gain prominence from a security point of view —instead of long and complex hardening guides, the user interface helps guide the user and makes sure they’re fully aware of what they’re doing before they downgrade the security of the product.

Red Hat is embracing this challenge by implementing Red Hat’s Secure Development Lifecycle (SDL) practices. By putting effort into secure by design products, we will continue improving the security of the open source software ecosystem as a whole, helping reduce security risks and facilitating compliance efforts.