What is security by design?
Security by design is an approach to software and hardware development that seeks to make systems as free of vulnerabilities and impervious to attack as possible through such measures as continuous testing, authentication safeguards and adherence to best programming practices.
An emphasis on building security into products counters the all-too-common tendency for security to be an afterthought in development. Addressing existing vulnerabilities and patching security holes as they are found can be a hit-and-miss process and will never be as effective as designing systems to be as secure as possible from the start.
The security by design process is becoming crucial in the rapidly developing internet of things (IoT) environment, in which almost any conceivable device, object or entity can be given a unique identifier (UID) and networked to make them addressable over the internet. One of the major challenges of IoT security is the fact that security has not traditionally been considered in product design for networking appliances and objects that have not traditionally been networked.
The security-by-design approach contrasts with less rigorous approaches, including security through obscurity, security through minority and security through obsolescence.
Why security by design is essential
In previous years, security was often considered an inconvenient activity. Getting to an acceptable level of security required additional time, funding and employees experienced in security development. Considering the dramatic growth of cyberattacks in recent years, especially ransomware, security can no longer be an afterthought.
Assuming an IT department is handling software development, the software development lifecycle (SDLC) is likely to be used. When a security-by-design methodology is added to the SDLC process, security issues are considered and implemented at every stage of the development process.

Each phase of the security-by-design methodology requires specific activities to help ensure the overall security of the software product.
Phase 1 -- planning and requirements analysis. Capturing data from users, stakeholders and other sources is the initial step. Requirements for the application emerge from this step. Obtaining security inputs from the same interviewees is a key activity. This can include issues like local and remote access, encryption and who is authorized to use the system.
Phase 2 -- defining security requirements. Once the requirements, including security features and security controls, have been identified and documented, they should be reviewed and approved by all contributors and senior management.
Phase 3 -- designing the application. This step defines the application architecture, input/output requirements, security requirements and other issues. The design process involves preparing flow diagrams and other documentation before the application is coded.
Phase 4 -- developing and coding the application. The process for coding the application begins in this phase, which requires programming languages and tools to build the software, including the security components.
Phase 5 -- testing and validation. Once the app has completed its initial development, testing and validation begins. Testing identifies any problems in the coding and other elements that can be fixed. This is also where security testing ensures the performance of access controls and protection against malware and other security breaches.
Phase 6 -- deployment and maintenance. Upon completion of testing, it may be useful to try out the new application in a controlled environment prior to releasing it into production. A research and development or engineering environment is often an ideal place to further challenge the system. This is also valuable for testing security attributes and training users on the system. Once the system is approved for production, it should be carefully monitored during its initial rollout to verify performance, user and customer interaction, data management, disaster recovery and security performance. Once the system has been deemed stable, it enters a maintenance regime to address issues like patching, fixing bugs and updating features.
Additional benefits of security by design
Clearly the integration of security at all stages of software development is highly recommended. Additional benefits include the following:
- Issues with staffing. Lack of sufficiently trained and experienced security team members may hamper the security-by-design approach to ensure that systems are designed from the ground up with security top of mind. In that case, adding qualified personnel or engaging third-party security support alternatives, such as cloud-based security services, may be appropriate.
- Compliance with regulatory requirements. Applications that have been designed with security are more likely to comply with specific government regulations, such as the European Union General Data Protection Regulation (GDPR) and global security standards such as ISO 27001. Ideally, these and other security standards and frameworks should be used during the SDLC process.
- Ensuring that security keeps up with demand. Considering the impact of cloud-based services and anything-as-a-service resources, the speed of development can easily accelerate. Engaging security teams in all initiatives, regardless of their source, and at all phases of development, ensures that security is firmly embedded.
Downsides of security by design
In reality, no downsides to security by design should exist, given the importance of integrating security at all phases of the SDLC. However, it may be challenging to find employees with security-by-design experience.
Deciding on the framework to use and learning how to use it may take additional planning time that may not be desired. Costs to retain third-party firms with security-by-design experience may be prohibitive.
Company culture may even be a factor, especially if senior management believes that security is not a critical concern.
Security-by-design frameworks
Security standards and good practices can be used in a security-by-design approach. ISO 27001 (and other members of the ISO 27000 Series) and NIST SP800-53 (plus numerous additional security standards) are two of the most widely used. Their guidance can provide an important starting point for a security-by-design process.
Following are examples of security frameworks that can be used by themselves or in conjunction with standards noted above to facilitate a security-by-design process:
- NIST SP 800-160 Volume 1 (2016) and Volume 2 (2021) provide guidance on developing and engineering secure products and developing cyber-resilient systems, respectively. Of the two, the latter is the recommended first choice for security by design.
- NIST SP 800-218 (2022) is the Secure Software Development Framework that provides guidance on preventing software vulnerabilities.
- The NIST Cybersecurity Framework Version 2.0 (2023) defines a risk-based approach to cybersecurity management.
- While the AWS Security by Design framework is designed for AWS activities, its principles and practices can be used in cloud and non-cloud applications.
- IEC 62443 Series was developed by the International Electrotechnical Commission; it is a set of standards that addresses security considerations for industrial automation and control systems (IACS). Standards can be used by manufacturers and end users of IACS technology.
- The U.S. Cybersecurity and Infrastructure Security Agency unveiled a guidance report, "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software" in late 2023. The report urges software manufacturers to develop and ship products that are secure by design.
The importance of threat modeling
An important activity to include in the SDLC process is threat modeling. It is a proactive approach that digs deep into potential threat situations to identify threats and vulnerabilities that may not be readily apparent. This activity can be enhanced using artificial intelligence (AI).
By running various threat models, unanticipated attack vectors may be identified and prioritized for prevention and mitigation. This can help security teams focus on the most critical -- and likely -- cyberattacks when developing software.

Adding security by design to security policies
Existing cybersecurity policies may not specify the use of security by design principles when developing applications, securing networks and improving the organization's overall security posture. The same may be true of software development policies and procedures.
Considering the available resources for security by design, it is recommended to either add requirements for security by design to existing policies or establish separate policies that mandate security by design across all areas of technology development. Support from senior management is also essential.
The impact of AI on security by design
Considering the importance of security-by-design principles and methods, AI is clearly an important tool to improve the overall process. The increasing implementation of IoT products and services means that security is a critical component, and AI-based security-by-design systems will be essential tools to meet the new challenges during system design and development.
The following security attributes can be enhanced by AI:
- Threat detection using enhanced algorithms may identify issues before they become disruptive.
- Security activities can be automated, such as patching, threat hunting and vulnerability scanning.
- Enhanced predictions of potential events may be based on analysis of a wide array of event data.
- Faster activation of incident response and recovery activities.
- Demonstrating compliance with specific regulations.
Security by design, enhanced by AI, has a bright future and must be an essential part of an enterprise's cybersecurity management program.
Implementing security-by-design principles in the cloud can be complex, but there are several effective strategies to consider. Focusing on these three areas when applying security by design in the cloud is a great starting point.