Security by Design: Turning Theory into Practice

In today’s slowing economy, it is more important than ever to invest in preventative measures to mitigate or remediate security gaps in architectures and close vulnerabilities that lead to much larger impacts on the business and drive higher costs.  This post is not intended to be a comprehensive list of security by designs ideas but some practical ones my teams have put in place.

Understanding Security by Design

At its core, Security by Design is about proactively building security into every phase of a project or system's development rather than attempting to patch vulnerabilities or fix architectural design issues later. It's a mindset shift that prioritizes security from the very beginning, and it's a critical strategy for protecting sensitive data, system, and assets. 

Putting Cybersecurity by Design into Practice 

1.     Security Policies, Standards and Technical Requirements:  Almost all organizations have security standards and policies that align with their organization’s goals and regulatory requirements.  Usually, these are written to be non-vendor specific and cover a large area of both infrastructure and project specific requirements.  Most employees do not read these policies cover to cover (or at all).   

It is up to the cybersecurity team to convert these policies into specific technical requirements and then filter the requirements so that a project team is only given a list of requirements that specifically applies to them.  Security questionnaires can filter this list down based on the type of project being implemented, the sensitivity of the data in the system, the hosting environment (data center, IaaS, PaaS or SaaS), databases used, etc.  Combining security and privacy questionnaires into one process is another way to reduce duplicity of data collection and improve business productivity. 

Reducing thousands of policy statements down to the 30 to 50 specific technical requirements that a project team must implement can significantly improve security adherence and reduce frustration on both sides.  Some of these requirements will be met by controls or guardrails already in place and specific guidance should be provided on how to meet them.  You should check that the system design addresses these requirements and validate that they were implemented by the build team.  Automating requirements validation should be a high priority.  Finally, the better you can fit these process steps into the project team’s workflow (such as agile development sprints), the more likely security controls will be properly implemented.

2.     Training and Awareness / Security Champions:  Regular employee training on security is important and usually required for most organizations. However, it likely is taken yearly and the content can be very superficial.  Developing a security champions program that target employees such as software developers and system administrator can substantially increase cybersecurity awareness, enthusiasm and the level of knowledge around security.  It can also provide a stronger connection to the business that leads to stronger security controls. Feedback from the security champions can improve security processes that reduce impact on the business.

3.     Threat Modeling:  Performing threat modeling in the architecture phase of a project can catch missing security controls and poor security design early in the project lifecycle when it is the most cost effective to fix.  Remediating issues at this stage vs once a system has been deployed to production can be 30 to 100 times more cost effective. 

Selecting the right tool can also be a benefit for the development and design teams.  If they can use the tool to perform their design, threat modeling can be a side benefit of using the tool.  Design components built into the tool that are frequently used in the organization along with standard design patterns can speed design and improve security.  Those design models can then be analyzed by the tool to provide architecture improvements and increase the understanding of security risks to the architects.

Threat modeling can reduce the number of vulnerabilities found later in SAST, DAST and penetration testing by 50% if properly done.

4.     Device Hardening:  Developing security configurations to harden device, OS and system configurations can dramatically reduce your attack surface, stopping some intruders and slow down others who do make it into your systems and network.  Develop organization specific configurations based on industry standards from the Center for Internet Security (CIS), the US National Security Agency (NSA), the UK National Cyber Security Centre and other respected organizations.  Golden configs are a great way to lock down devices, databases, network elements, and operating systems from the start of project, rather than trying to retrofitting the controls later in testing or production.

Limiting access to systems through firewalls and other mechanisms is a good defense in depth strategy to limit exposure of vulnerabilities.  Remember, risk is the combination of vulnerability and exposure to a threat actor who can exploit it.  If a vulnerability is not accessible, you are protected.

5.     Continuous Monitoring:  Monitoring for operational drift from baseline standards is critical to maintain your security posture.  Operational drift can occur when production systems are updated with insecure protocols and configurations once they are in production.  This can happen when outages occur and system administrators are troubleshooting problems.  Once the problem is fixed, rarely do the administrators go back and turn on restrictions and controls that where in place, opening holes for intruders.

Self reporting control implementation is a good first step but can significantly over estimate the actual implementation of a control.  Were possible, put in automated testing of security controls and hardening practices.

6.     Securing your Development Pipeline:  It is just as important to ensure your development pipeline is secure as it is to ensure the end product is secure.  You should be testing the security of your pipeline, code storage, monitoring for insecure secrets and the ability of threat actors to infiltrate and modify your code.  Developers can be under strong deadlines to get products out the door.  Your controls may be testing their products but an intrusion into your development processes can be much more devastating in the long run.

7.     Threat Intelligence:  Cyber threats are constantly evolving. Stay informed about emerging threats and adapt your security measures accordingly. Regularly update your security controls and policies.  You should be reviewing not only your policies but also your hardening configurations and design principles based on the latest tactics, techniques and procedures that threat actors are using.

8.     Partnering with your Privacy Organization:  Early engagement with your privacy organization can have the same effects as Security by Design.  Privacy by Design with early engagement can reduce significant bottlenecks later in the program and can reduce duplication of data collection mentioned earlier.  This is especially true in privacy sensitive regions such as Europe and China. Explaining the need for security controls to privacy experts can help reduce conflict, especially when implementing more intrusive security controls.  A reasonable balance between security and privacy can be met by understanding privacy concerns and taking them into account early in the process.  Remember the old phrase, “You can have security without privacy but you cannot have privacy without security”.

9.     Partnering with the Business:  Having a strong relationship with the business is key to a successful security program.  For large organizations, having Business Information Security Officers and teams to understand the business's strategic goals and work with them to achieve those goals are critical.  Security champions can bridge the gap at the lower, technical level and ensure security is not overlooked or bypassed.  In my experience, the business wants to do the right thing and have their products secure but the security team needs to work with the business to meet their goals: security at the speed of business.

Remember, in the end, security is just one more business risk.  Security risk decisions made at the appropriate level with a full understanding of the potential consequences are no different than other business risk decisions.  It may be fine to get a product out to market with lower security controls if that is a fully informed risk the business wishes to take on.  The key is then shoring up the security once the product is in production to minimize the risk going forward.  This may cost more in the end but getting the product to market faster may be more important.  If you go down this path, the deadly sin is not then mitigating or remediating the issues once in production. 

I was at a company where we went down this road and the VoIP product was very successful.  However, the business would not spent the time and money to fix the product once it was in production until the COO’s phone was hacked.  Then it became a priority.

Conclusion

Security by Design is not a one-time effort; it's an ongoing commitment to making security an integral part of your organization's culture and operations. By embracing this approach and putting it into practice, you can significantly reduce the risk of cyberattacks and protect your organization's digital assets and reputation. Remember, in the world of cybersecurity, prevention is always better than remediation.