Cybersecurity - Secure by Default vs. Secure by Design
In information security, the principles of secure by design and secure by default represent two paradigms that work together to enhance the security of networks and systems. These two paradigms represent essential elements in cybersecurity. The secure-by-design principle is an engineering principle that integrates security as a fundamental element during the development process and throughout the development lifecycle. The focus of secure-by-default means the product is as secure as possible out-of-box without any additional security configurations.
Many government and multi-national partner agencies such as CISA, NSA, FBI, ACSC, NCSC-UK, EU, CCCS, BSI, NCSC-NL, and NCSC-NZ have taken a keen interest in recent years in encouraging vendors, manufacturers, and developers to adopt secure by design and secure by default principles to enhance information security for software consumers and organizations worldwide. In this blog post, we'll seek to understand what secure-by-design & secure-by-default entail, some development practices and other best practices, and some real-world examples of vulnerabilities and risks these principles and approaches could prevent.
Secure by Design vs. Secure by Default
It is important to note that secure by design and secure by default are different. These two principles do, however, work together to ensure the confidentiality, integrity, and availability of information on systems and networks. In this section, let's explore secure by design and secure by default to understand the differences and give some examples of best practices.
What is Secure By Design?
Secure-by-design means security is integrated as a fundamental element during the software design phase, the software development process, and the product lifecycle. Secure by design practices puts product security as a core element of the design process; this makes software resilient against common security threats. Secure by design operates under the fundamental premise that a large subset of software vulnerabilities are due to a relatively small subset of causes and that by putting security at the heart of the software design process, developers can protect and mitigate against these threats, protecting consumers down the line.
What Are Some Secure By Design Examples?
The following are some examples of secure-by-design best practices and principles. We'll also throw
Memory Safe Programming
Memory-safe languages remove memory management from the software engineer, preventing memory errors and vulnerabilities. These languages include Rust, Python, Java, and Go.
Programming languages like Rust enforce a strict ownership model to ensure memory safety. That is, in Rust, the value of each value is tracked across its lifecycle and can only be used once. Additionally, in Rust, the compiler's borrow-checker feature prevents vulnerabilities in memory, dereferences, and other undefined behavior by enforcing scope and strict rules on borrowing values.
Memory-safe programming eliminates the entire CWE-1399 category of memory-based vulnerabilities.
Secure Hardware
Using hardware that supports security through enhanced memory protections, such as Capability Hardware Enhanced RISC Instructions (CHERI). The developers behind CHERI describe this hardware system as Architectural Capabilities by adding registers and data pathways and enforcing bounded addresses. These add fine-grained memory protection techniques that prevent vulnerabilities such as out-of-bounds issues and pointer abuse. Multiple technical reports and papers have been published on the CHERI hardware approach. The CHERI project includes many software-stack prototypes, and software such as WebKit has been fully prototyped for the CHERI protection model as CHERI-WebKit.
By adhering to secure design principles, vendors, developers, and software manufacturers can help protect consumers of their products from cyber threats and lower maintenance costs related to security patches.
Web Frameworks
When designing software and applications, developers can use web frameworks that protect against common web-based attacks, such as cross-site scripting (XSS). These frameworks include sanitization checks on user input baked into the framework. For example, frameworks like Angular, AngularJS, and ReactJS include functions that sanitize user input to prevent cross-site scripting (XSS) attacks. This allows developers and engineers peace of mind by allowing the framework to handle the necessary escaping and checks on user input.
Cross-site scripting attacks can pose a significant threat to organizations' security. Such attacks can have potentially devastating consequences. Critical examples of cross-site scripting (XSS) vulnerabilities include CVE-2023-38750, a reflected cross-site scripting vulnerability in Zimbra Collaboration (ZCS). This vulnerability was discovered by Clément Lecigne of Google Threat Analysis Group. Another example is CVE-2023-20060, a vulnerability that allowed authenticated attackers to access resources outside of the filesystem mount point of the web UI through a cross-site scripting vulnerability in the web UI of Cisco IOS XE software. CVE-2023-20060 was discovered by Pierre Vivegnis of the NATO Cyber Security Centre (NCSC)
Static Application Security Testing (SAST)
Many security issues can be resolved in the design and development process using static application security testing (SAST). This security testing methodology is a white-box security testing technique that analyzes source code for vulnerabilities—often performed early in the development process or when various software components are brought together. This method scans codebases for vulnerabilities and does not need a running machine to analyze.
Static application security testing (SAST) can automatically detect vulnerabilities such as SQL injections, cross-site request forgery, and cross-site scripting (XSS). SAST testing is a great tool; however, it is essential to note that SAST testing cannot identify vulnerabilities in dynamic environments.
Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing (DAST) is an essential black-box testing technique that can be used to find vulnerabilities through simulated attacks. Unlike SAST, which focuses on the static analysis of codebases at rest, DAST testing allows software developers to find security vulnerabilities by actively "attacking" an application as a threat actor would.
Dynamic Application Security Testing (DAST) is a great tool to detect server configuration errors, code injection, SQL injection, cross-site scripting, and other runtime vulnerabilities that cannot be discovered by Static application security testing (SAST).
Securing Software Components
In today's interconnected world, securing various software components such as (libraries, modules, middleware, and frameworks) has never been more critical. Vendors and developers should be aware of the risks associated with third-party components and use verified commercial and open-source components to ensure a strong cybersecurity posture. Using the best practice of utilizing a Software Bill of Materials (SBOM) to add visibility into the various software components helps secure software components and the security posture of the final product while also increasing trust between suppliers and consumers.
Some real-world examples of zero-day exploitation highlighting the risks associated with securing software components include:
CVE-2023-4863 - Google Chrome libwebp Heap Buffer Overflow Vulnerability
CVE-2023-5217 - Google Chrome libvpx Heap Buffer Overflow Vulnerability
In the above Common Vulnerabilities and Exposures (CVE) numbers, vulnerabilities in software components (libwebp and libvpx) lead to zero-day attacks by threat actors attacking Google Chrome. This highlights the need to ensure the security of software components that make up consumer products.
Relationships With Vulnerability Disclosure Programs
Vendors and manufacturers should create relationships with bug bounty and vulnerability disclosure programs such as Trend Micro's Zero Day Initiative. These programs serve a critical function in the secure-by-design process, encouraging the responsible disclosure of vulnerabilities by security researchers. Suppliers can use these programs and research to quickly identify root causes and inform if any secure-by-design and secure-by-default features should be implemented, shifting the balance of cybersecurity in favor of vendors. These programs can help further ensure that CVEs are accurate and complete and include a common weakness enumeration (CWE) root cause.
What is Secure By Default?
Secure-by-default means secure out-of-the-box without the need for additional security configuration. Recently, greater attention has been drawn to shipping software and applications to consumers with "Secure by Default" principles in mind. Secure by default means that the default settings protect against prevalent exploitation techniques out of the box with minimal changes necessary by the consumer, putting any security complexity in the hands of the vendor.
By incorporating secure by default features into their products, vendors and developers can raise the cybersecurity posture of consumers needing more technological expertise or resources to implement modern information security standards.
What Are Some Secure By Default Examples?
The following section will give some examples of secure-by-default principles and best practices:
Don't Ship Factory Default Passwords
Software vendors and system manufacturers often ship default passwords to consumers for installation and deployment, ease of administration, and testing. The risk of shipping default passwords is that if product administrators don't change passwords, systems, and networks can easily be compromised by threat actors. These default passwords are well-documented in vendor documentation and often shared across product lines. Threat actors can easily access those devices with internet-exposed default credentials through reconnaissance tools such as Shodan and Censys.
Critical real-world examples of default credentials vulnerabilities include CVE-2023-20101, a vulnerability affecting Cisco Emergency Responder, which threat actors could leverage to log in to the affected system and execute commands as root. In the case of CVE-2023-20101, these credentials were static and cannot be deleted. In another example, consumers of LogicMonitor software became victims of ransomware attacks due to default credentials. Examples like these highlight the seriousness of default credential usage and the potential ramifications of their use.
Force Multi-factor Authentication (MFA) For Privileged Users
High-privileged users such as root and Administrator are high-value targets for threat actors as they can perform sensitive operations and lead to the complete takeover of an account or environment. Enforcing MFA utilization by default for high-privileged users, vendors, and developers can help ensure an enhanced security posture for their consumers.
Multi-factor authentication (MFA) can thwart unauthorized access vulnerabilities. For example, the case of CVE-2023-20269, an unauthorized access vulnerability affecting Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD). Organizations that had enabled MFA on these devices were protected against the Akira and LockBit ransomware gangs, who targeted vulnerable ASA and FTD devices where MFA was not enabled. MFA, especially for privileged users, should be an opt-out feature, not an opt-in feature.
Include SSO By Default, Not as a Luxury Feature
Vendors and manufacturers are responsible for ensuring that the consumers of their products and applications have the best security posture while using their products. These include adding single sign-on technology to their core offering without an additional charge by implementing open standards such as Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). By making SSO a luxury with a price, vendors hinder the broader adoption of this critical identity and access management (IAM) technology, especially amongst smaller organizations.
Enable secure logging and easy integration with Security Information and Event Management (SIEM)
Offer Great Secure Logging
Logging provides a powerful tool for identifying threats and is crucial during incident response. By offering a robust logging solution by default, vendors can significantly enhance the security posture of their consumers and help them identify threats. Logging solutions should contain an easy-to-use Application Programming Interface (API) that easily allows ingestion by Security Information and Event Management (SIEM) systems.
Do Recommend Secure Profiles
Software suppliers can assist consumers by providing recommended profiles for everyday use cases, including targeted use cases that large enterprise customers may encounter. Vendors can further help consumers by having clear warning signs that notify users when they deviate from a recommended profile. Examples include warnings when MFA is disabled or when an insecure protocol has been enabled.
Prioritize Security Over Backwards Compatibility
Often, legacy features and protocols are removed with new versions for good reason, such as SMBv1, SSLv1, SSLv2, and SSLv3. Vendors can increase security by default and help protect organizations by focusing on security over backward compatibility. Removing insecure features allows security teams to focus on the latest threats and incidents instead of drowning in issues mitigated by modern security standards.
Reduce Complexity Of Security Settings
By releasing secure products by default, vendors and suppliers can ease some cognitive costs associated with complex security features and hardening guides consumers face. Vendors can ensure their consumers have a robust security posture while using their applications and products by baking the best security features into products by default and abstracting the complexity away from the consumer.
Wrapping Up Cybersecurity Principles of Secure By Design and Default
Secure by design, with its roots deep within the software development lifecycle, emphasizes the proactive integration of security measures. Through practices like memory-safe programming, secure hardware adoption, and robust web frameworks, vulnerabilities can be found during the software development lifecycle. We explored how partnerships with vulnerability disclosure programs such as Trend Micro's Zero Day Initiative are crucial to bridging the gap between security researchers and product developers. These strategies shield products from potential threats and alleviate the burden on end-users, fostering trust between vendors and consumers.
Equally pivotal is the concept of secure by default, where security isn't an optional add-on but a fundamental product characteristic out-of-box. This principle recognizes that not all users possess the technical prowess to navigate intricate security settings. Therefore, vendors empower users with a shield that requires no assembly by eliminating factory default passwords, enforcing multi-factor authentication, and seamlessly integrating Single Sign-On (SSO) capabilities. It's security straight out of the box, pushing acquiring organizations' standard and secure posture.
We explored some real-world examples of vulnerabilities and exploits to underscore the importance of these principles. These are cautionary tales of real-world consequences where zero-day exploitation and ransomware gang activity can wreak havoc on organizations worldwide, reminding us of the stakes involved and the importance of embracing secure design and default practices.
I hope you found this blog post informative, if you have any questions or concerns, feel free to reach out on social media!