Secure By Design: What Makes Software SbD

As the digital landscape continues to evolve, new cyber threats continue to emerge. It’s imperative to have safeguards in place early on in the product development process. That’s where Secure by Design comes in. 

What does Secure by Design mean?

An initiative from CISA, Secure by Design (SbD) is the cybersecurity design concept that emphasizes embedding security measures early into the planning and development phase of a product. 

For example, a Secure by Design software development life cycle (SDLC) approach involves developing product features and functionality that adhere to acceptable cybersecurity standards and best practices. 

Conceptually, SbD contrasts with more traditional software development approaches that treat security as an afterthought, where cybersecurity measures are only introduced as additional layers to the end product before release. (Shift left and DevSecOps are related concepts for building security into and across the entire development lifecycle.)

SbD design principles are designed to reasonably protect digital products against common cyber threats. A risk assessment early during the SDLC pipeline identifies prevalent security threats and introduces defense capabilities that make the final product resilient against exploitation techniques in its default state.

Core principles of Secure by Design

The following principles are the foundation of the Secure by Design philosophy:

Secure default baselines

This principle says that you should automatically enable the highest level of security controls that minimize risk exposure to every user. These baselines should: 

• Feature in products at no additional cost to the customer. 

• Not be hidden behind or require tedious configuration.

Simple security configurations

A simple and intuitive interface for security configurations assists the end-user in enforcing the required security policies. 

Staff and IT administrators should not be burdened with additional responsibilities to identify, understand, and implement security protocols when the product itself can be shipped in accordance with Secure by Design standards.

Separation of duties

Product functions should be isolated for users across different functional domains to reduce the risk of errors and security malpractices. The separation should include task segregation based on:

• Roles

• Clear authorization process for task execution

• Mitigation of any conflict of interest or overlapping task functions

• Consistent enforcement of compliance regulations such as HIPAA, PCI DSS, and GDPR

Principle of least privilege access (PoLP)

Users should only be able to access functions, data, and resources necessary to fulfill their tasks—this is made possible by enforcing granular permissions and access restrictions using an Identity and Access Management (IAM) protocol such as the Policy-based access control (PBAC) mechanism.

(Understand the PoLP concept.)

Ubiquitous encryption

All sensitive business information should be encrypted before storage and transmission. This is especially necessary for sensitive workloads processed in third-party cloud environments.

(Related reading: third-party risk management.)

Automated system-specific security controls

Manual policy enforcement and administrative tasks at scale lead to costly security errors. Simple and repetitive security policy enforcement should be automated. 

Complex controls, however, should be carefully evaluated before setting up a security automation system.

Standardization of security design specifications

Developers, engineering teams, and cross-functional experts should be able to follow a uniform and consistent set of security design specifications. This can be achieved by enforcing the use of templates that specify configuration patterns, security policies, and other details commonly used across all phases of the SDLC pipeline by different team members.

Operationalized use-case specific security processes

Use cases for different industry verticals and teams may require unique security policies and controls. Instead of creating a secure environment from scratch every time, engineering teams should be able to adopt security controls and standardized rules following applicable compliance regulations. 

Tip: Use standardized templates and actionable guidelines.

Security ownership

Team members across all phases of the SDLC pipeline should assume security responsibility in their engineering activities. 

• Developers should evaluate feature builds from security performance and vulnerability perspectives. 

• QA and Ops should work collectively with Devs to identify the prevalent security threats and establish protection measures in the SDLC lifecycle.

Continuous and real-time auditing

The security and compliance performance of the software products and the SDLC cycle should be continuously monitored. Malpractices should be identified, and security bugs should be traced to the point of origination. 

A fully functional and reliable governance model should be in place to minimize security risks.

Best practices of frameworks in software design

The process of developing technologies that are secure by design requires a methodological approach to product development. Modern SDLC frameworks such as DevOps and SecOps can complement your engineering capacity and organizational structure to achieve a fully functional secure system, by design. 

These frameworks encourage a security culture that builds on principles of collaboration and automation to develop high-quality and secure software products with rapid release cycles.

The role of software designers

Individual members and SDLC teams should also take ownership of the security outcomes of their contributions to product design and development. Security should not be treated solely as the responsibility and burden of the customer. Engineering teams should embrace transparency and accountability. 

In addition, real-world customer feedback should be used to improve the security performance of iterative builds. Organizational structure and stakeholder sponsorship should help support the changes necessary to build products that are secure by design. 

Technology vendors and enterprise IT organizations should consider how these changes, their security investments, and the end-user experience change the security posture of their products against the prevalent security threats.