Security by design (SbD) explained
Security by design is a software development approach that aims to establish security as a pillar, not an afterthought, i.e., integrating security controls into software products right from the design phase. SbD creates secure software that enterprises can deploy out of the box without incurring additional costs for security features.
To better understand SbD, imagine a scenario where you need to build a secure warehouse for your multimillion-dollar goods. You could construct a building with easy-to-breach wood, fortify it with security features, e.g., sensors and CCTV, and even hire a security company. Or you could build your warehouse out of brick, use heavy metal doors, and install the same security features.
The brick warehouse will, of course, be more secure, as no matter your security features, it is better to have an unbreachable system, and that’s the approach that exemplifies SbD.
Advanced Container Security Best Practices [Cheat Sheet]
This cheat sheet goes beyond the no-brainer container security best practices and explores advanced techniques that you can put into action ASAP. Use this cheat sheet as a quick reference to ensure you have the proper benchmarks in place to secure your container environments.
Download now
Why security by design?
Web-facing apps used to be vulnerable by design (VbD) because software vendors shipped software before baking security into it. This meant businesses had to purchase security features as add-ons and patch major vulnerabilities as they arose—a profitable approach for vendors, as more features equaled more money.
But as the primary targets of supply chain attacks, enterprises are the ones that face the legal, financial, and reputational consequences when breaches occur (and they often do).
SbD addresses this “penalize the enterprise user, spare the vendor” problem by promoting a culture of software development whereby both the user and vendor are held responsible for their actions or inactions. This improves both the vendors’ and users’ software security posture by reducing their attack surface and facilitating other key outcomes.
Easier, cheaper patching
Applying security fixes in a hurry while the software is in use (to prevent data breaches and associated financial and reputational damage) can be a pain in the neck, costly, and fraught with error.
Products designed to be secure from the outset require fewer and less critical patches, making the process a whole lot cheaper and easier.
Cost-effective products
The only way to secure vulnerable-by-design systems is to bolt on multiple add-ons. However, attackers can still leverage the backdoors created by the VbD flaw to infiltrate systems.
Securing systems by default is more cost-effective than facing a higher risk of data breaches and their associated costs, lawsuits, and fines.
Regulatory compliance
Since software developed using the SbD approach has security at its core, they are more likely to be compliant by default. This eases the process of checking different software components to ensure compliance with various regulations.
How does security by design work?
The SbD approach has four key stages, which we explore below.
Stage 1: Define security requirements
SbD begins with a clear study of the software to be developed, its potential vulnerabilities, and corresponding security requirements. For a database service, security requirements would include encryption, role-based access control (RBAC), and other authorization techniques.
Stage 2: Conduct risk assessments and threat modeling
This stage entails using a context-sensitive vulnerability scanner to map out the software’s potential attack paths.
For example, a database service provider is exposed to possible attack paths such as public IPs or privileged accounts due to sensitive personal identifiable information (PII) and protected health information (PHI) stored in its databases.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Stage 3: Write code and build security measures simultaneously
In this stage, the engineering team jettisons conventional coding procedures to develop software with native security measures. For the database provider, this could include writing code that:
Prevents databases from being open to the public by default
Automatically validates user input without enterprise users having to purchase add-ons
Requires multiple authentication mechanisms before any form of access is granted
Limits access points for privileged accounts
Stage 4: Continuously monitor and patch
Finally, the software is tested and, if found to be secure by design, shipped. As users deploy the software, the vendor continuously monitors, audits, and sends out SbD updates as new threats and vulnerabilities emerge.
Security by design principles
The Cybersecurity and Infrastructure Security Agency (CISA) encourages software manufacturers to adopt three core principles when developing a product.
Shared responsibility
Both the vendor and the customer should share the burden of security. Software manufacturers are expected to build secure products and regularly patch their software as the threat landscape evolves. Customers, meanwhile, are expected to configure their products using this software securely and keep their data safe.
Radical transparency
Software manufacturers should share information about what makes their products secure by design. They are accountable to their customers for accurate vulnerability advisories, the associated common vulnerability and exposure (CVE) records, and authentication mechanisms, to name a few of the things expected of an SbD product.
Organizational structure
SbD requires C-suite-level commitment and communication between all stakeholders, Collaboration is key between vendors and customers as well as developers and security teams. This will facilitate the implementation of near-impenetrable security controls and enable insight-based budget planning and resource allocation.
Challenges of implementing security by design
Let’s discuss three top challenges of adopting SbD.
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Security by design best practices
CISA offers some SbD tactics culled from the Secure Software Development Framework (SSDF) of the National Institute of Standards and Technology (NIST): NIST’s SP 800-218. Organizations should integrate these practices into every stage of their software development lifecycle (SDLC).
Use secure software components
Deploy well-secured software components, including libraries, frameworks, and middleware, from verified providers only. Also, avoid software with known vulnerabilities, including cryptographic and authentication failures, broken access controls, injection vulnerabilities, and logging issues.
A cloud native application protection platform (CNAPP) will come in handy to detect unsecured components.
Adopt good design practices
Organizations can reduce risk to their software systems by implementing defense in depth, i.e., having more than one layer of security measures. Meanwhile, sandboxing isolates software and security components to prevent the compromise of a single component from affecting the entire system.
Vendors should also design software that makes patching easy; minimizing downtime resulting from software updates will encourage enterprise users to apply patches faster.
Utilize memory-safe programming languages
NIST encourages developers to implement common memory-targeted mitigations such as control-flow integrity (CFI) and address space layout randomization (ASLR). But beyond this, NIST also notes they should adopt modern memory-safe languages, e.g., Rust, Go, Java, C#, Swift, and Python, while avoiding their memory-unsafe counterparts, C and C++.
This will help mitigate memory-safety vulnerabilities like SlammerWorm, Ghost Engine, and Stagefright.
Adopt parameterized queries and web template frameworks
Parameterized queries are SQL queries with parameters that separate user input from the query itself. Web template frameworks contain context-sensitive information that automatically prevents suspicious user input. Together, these mechanisms help prevent SQL injection and cross-site scripting (XSS) attacks.
Provide SBOMs
Software vendors should provide users with a list of the proprietary and third-party software components, libraries, and tools they used to develop software. This list—which can be generated via an agentless SBOM scanner—enables easy vulnerability resolution.
Eliminate default passwords
Providers must avoid rolling out products with default passwords. Instead, they should adopt multi-factor authentication and require users to set strong passwords immediately after they configure the software.
Provide software authorization profiles
These profiles designate user roles and use cases to limit unnecessary access to user data and privileged accounts. Software manufacturers should provide detailed software authorization profiles, implement the principle of least privilege, and issue warnings against deviating from the designated limits.
Conclusion
Security by design proactively implements security protocols from the software design stage. Championed by CISA and other key industry players, SbD encourages conducting vulnerability assessments, attack path analysis, and software component analysis to determine and resolve potential software vulnerabilities before apps are shipped and at every stage of the SDLC.
The goal is to cut out expensive bolt-on security tools and complicated after-sales code changes that do not adequately protect systems from attacks because they are already vulnerable by design.
SbD is a cheaper, faster, and more robust approach to building and securing apps. This is why Wiz is a leading advocate for shipping secure code. Its solution:
Facilitates end-to-end software visibility
Provides up-to-date SBOMs
Enables attack path analysis
Sign up for a personalized demo to see how Wiz can help you begin your journey to secure-by-design products.
Learn what makes Wiz the platform to enable your cloud security operation
