How can you implement security by design and default?

Having an architectural model of the target system is a great basis upon which to identify security requirements as it enables threats, vulnerabilities & control gaps in the technical layers to be traced up to business assets (processes, data capabilities & value streams) that the business will be readily recognisable as critical. If this exposes risks that are above appetite, the same models can be used to identify the best places to deploy addition controls, either to provide end-to-end protection of an exploit path or re-enforce it pressure points with defence in depth. The SABSA Security Overlay for ArchiMate has a wealth of advice on how to add the security perspective to Enterprise Architecture models.

The National Institute of Standards and Technology offers reliable security-by-design guidelines through NIST SP 800-160. This publication combines established security standards and emphasizes engineering practices and techniques, requiring organizations to consider the entire operational life cycle.

Define ownership of building 'Securing by Default' within the framework - where the onus is on the product or service owner to consider Securing by default as a core requirement - supported by appropriate policies that drive the requirements. Clearly build a framework for service owners to validate compliance and identify GAPS, work with the application or product security team to identify appropriate remediation actions.

Security requirements in practice end up being a product of the context in which your thing (circuit, program, chip, box etc.) is running. Change the context and the requirements change. Set your requirements broadly, so you are immune to changes in context. Are you making assumptions about the data or keys you generate are used? A BORE vulnerable user of keys you hand out will impose new security requirements on your security thing. This can seem like a subtle issue until it happens to you. Consider yourself as being untrustworthy and see what is the worst thing that could happen. What would be required to stop you, as the designer, undermining the system. Make the same analysis for all the users of your security thing.

Implementing security by design and default involves integrating security measures into every aspect of a system from the very beginning and ensuring that security features are enabled by default. This means considering potential security risks during the design phase, implementing controls to mitigate these risks, and configuring systems so that security measures are active without requiring additional action from users. It involves adopting security best practices, such as encryption, access controls, and regular security updates, as inherent components of the system rather than add-ons. Additionally, it involves creating user-friendly interfaces that prioritize security and making security settings clear and easy to understand for users.

In that phase need to follow the security principals to assure the solution is secure by design: 1. Principle of Least Privilege 2. Principle of Separation of Duties 3. Principle of Defense in Depth 4. Principle of Failing Securely 5. Principle of Open Design 6. Principle of Avoiding Security by Obscurity 7. Principle of Minimizing Attack Surface Area ...

In addition to security principles as stated by Dan, it may be useful to think of "security building blocks" which implement certain common security controls. For example, you can use a number of building blocks for boundary protection: firewalls (hardware and/or software), data diodes, gateways, etc. When you have such a library of building blocks (with standardised descriptions and supply chains), you can establish a repeatable practice when designing and implementing a security solution.

Early Integration: Embed security controls into the design phase. Leverage secure design patterns and architectural principles. Zero Trust Architecture: Consider adopting a Zero Trust approach, where trust is never assumed, and access is explicitly verified. Secure Coding Practices: Promote secure coding practices across development teams. Encourage the use of secure libraries, input validation, and secure defaults. Privacy by Design: With privacy regulations like GDPR and CCPA, ensure that privacy considerations are part of your design process.

For larger projects, it makes sense to write a Security Management Plan, which will outline the approach you take to design security in your system. In such a plan, you address the "how" of security engineering, i.e. the roles and responsibilities, and the activities you will execute within your project. This should not be seen as "just another piece of paper", but a document which you will use to obtain committment, from project stakeholders and from the management, on the way security should be engineered.

Automation and DevSecOps: Embrace automation for security tasks. Integrate security into your CI/CD pipelines (DevSecOps) to catch vulnerabilities early. Secure Defaults: Set secure defaults for configurations. For example, configure firewalls to deny all traffic by default and allow only necessary exceptions. Threat Intelligence: Leverage threat intelligence feeds to stay informed about emerging threats. Use this information to adjust security controls. Secure APIs: As APIs become central to modern applications, focus on securing them. Implement authentication, authorization, and rate limiting.

Need to educate all product development organization starting from top management and till the last engineer in the development team. Security mindset is the first step in embedding security by default in the product development lifecycle.

One way of educating your stakeholders is to write a Security Management Plan (as described in point 3) and have your stakeholders review and accept it. This will help in following a security-by-design approach, because unfortunately some project stakeholders will not be used to cyber security being a significant concern when developing a product or a project.

Effective cybersecurity education is paramount in our interconnected digital world. It spans individuals, organizations, and communities, equipping them to navigate the evolving threat landscape. Stakeholders must comprehend various cyber threats, their motivations, and potential consequences. They need to adopt best practices like secure passwords, multi-factor authentication, and data encryption. Tailored training for employees, leaders, and the broader community is essential. This is a continuous effort, involving collaboration among governments, institutions, experts, and individuals to create a safer digital environment.

Security Awareness Training: Regularly train developers, testers, and other stakeholders on security best practices. Make security part of their mindset. Collaboration: Foster collaboration between security teams, developers, and business units. Break down silos to improve security communication. Secure Culture: Promote a security-conscious culture across the organization. Encourage reporting of security incidents and near misses.

The intro paragraph emphasizes on when and how to include security teams. But the first section skips it and goes into "Define security requirements" . To be able to truly implement the "secure by design" principle, we should involve the security teams early-on in brainstorming sessions where the idea is being conceived. The security professionals are more than it meets the eyes! They are creative thinkers and guardians of innovation! It's worth emphasizing on the integration of automation to enhance monitoring and compliance efforts. Also, conducting regular risk assessments are pivotal. Optimal controls are those that align with overarching business objectives and are established in accordance with the organization's risk appetite.

For some industry verticals, security should NEVER be a premium feature you must pay more money for. EVER. Case in point - an MRI machine you must pay the cost of a new car to upgrade to the “secure” version. (You know who you are…)