OWASP Top Ten Proactive Controls - C5: Secure By Default Configurations

What does "Secure-by-Default" mean in software development?

"Secure-by-Default" signifies that software products are inherently resistant to common exploitation techniques right out of the box, without requiring any additional cost. Essentially, the software should be in a secure state from the outset, minimizing the need for extensive user configuration. The default settings should always prioritize the most secure options.

What are the benefits of having an application secure from the start?

Starting with a secure application relieves developers of the burden of figuring out how to lock down the system, as they're provided with an already secure foundation. This approach reduces the effort needed to deploy products securely and increases confidence in their ongoing security.

What are some potential threats related to insecure default configurations?

• Attackers could exploit default, weak, or well-known credentials that haven't been modified from their initial state to gain unauthorized access.
• Overly permissive default settings can be exploited to access sensitive resources or perform unauthorized actions.
• Attackers might gather sensitive information by probing unnecessarily enabled features or services that are active by default.
• Cross-site scripting (XSS) attacks could be carried out by exploiting lenient default security headers that lack sufficient protection against such threats.

How does Infrastructure-as-Code (IaC) play a role in secure-by-default configurations?

In modern cloud applications, developers often build infrastructure alongside their applications. This involves making security-critical configuration decisions while writing code. IaC, which uses code to create and configure infrastructure, applies configurations at various levels, including the application, container, and infrastructure. By employing IaC, developers can embed security measures directly into the infrastructure's foundation.

What are some key principles to follow when implementing secure-by-default configurations using IaC?

1. Least Privilege Principle: Implement configurations that grant the minimum necessary access rights, ensuring that resources like cloud storage are private and accessed only for essential periods.
2. Deny by Default, Allow by Exception: Access should be denied by default and only granted through an allowed list.
3. Secure Container Images: Utilize container images that have undergone vulnerability scanning for packages and components and are sourced from a private container registry.
4. Declarative Configuration: Favor declarative infrastructure configuration over manual processes. Use Infrastructure-as-Code templates for automated provisioning and configuration of cloud and on-premises infrastructure. On a higher level, leverage Policy-as-Code to enforce policies, including privilege assignments.
5. Traffic Encryption: Ensure traffic encryption by default or avoid implementing unencrypted communication channels altogether.

What is Continuous Configurations Verification, and why is it important?

Continuous Configurations Verification is an integral part of software development. It involves developers ensuring that software is configured securely by default at the application level. This includes practices like adhering to the principle of least privilege in infrastructure code and disabling unnecessary configurations, features, accounts, and demo capabilities.

What kind of vulnerabilities can secure-by-default configurations help prevent?

Secure-by-default configurations are particularly effective in mitigating vulnerabilities like OWASP Top 10 2021 A05 – Security Misconfiguration. By establishing secure baselines from the outset, organizations can significantly reduce the risk of security misconfigurations that attackers could exploit.

Are there any tools available to help implement and verify secure-by-default configurations?

Yes, several tools can assist in implementing and verifying secure-by-default configurations. Some notable examples include:

• Static Analysis Tools: Tfsec, Terrascan, Checkov
• Multi-Cloud Security Auditing: Scout Suite
• Vulnerability Scanning: Snyk, Trivy
• Kubernetes Security: Kubescape, Kyverno
• Infrastructure-as-Code Scanning: Prowler, Cloudmapper, KICS

References:

https://top10proactive.owasp.org/archive/2024/the-top-10/c5-secure-by-default/