Secure-by-Design and Threat Modeling, your guide to a proactive security strategy
Is the cyber landscape anything other than a stormy sea? Do we ever get calm waters in cyber security? Probably not, and this is where secure by design practices, and threat modeling is a recommended activity to bring your efforts into a proactive or shift left approach to help navigate the turbulent waters. We recently held a webinar with our partner, Concord USA, where we discussed the importance of security by design, and the ways a threat modeling program can reduce costs, increase collaboration, and ultimately bring you greater security. Prefer video? Watch the session in full here below:
What is Security-by-Design?
It is described in this document from CISA as ‘..a means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure’. This was contributed to by multiple organizations across the globe, such as the NIST, UK National Cyber Centrem Canadian Center for Cyber Security, and many others. It includes software product security principles and secure-by-design tactics that companies can implement such as code reviews and Cyber Performance Goals (CPGs) to be met.
What level of Security-by-Design are we seeing?
We see a diverse range of maturity levels. It's encouraging to see an uptick in questions, inquiries and discussions around security by design, but the reality is, the majority of people still feel more familiar with security testing phases, which traditionally occur later in development. This may indicate a gap in the widespread understanding of what security by design is, and that it's not a final step, but can be implemented at the inception stage for maximum positive outcomes and more secure products.
In our most recent webinar, we asked this question, and interestingly, only 32% of respondents had a comprehensive strategy.
What is automated threat modeling?
Automated threat modeling, versus manual efforts, is usually the difference between whiteboarding or drawing out your architecture, and recording threats perhaps in a spreadsheet, to scaling this effort with enterprise tooling. This gives you a faster, more reliable - and arguably most importantly - a repeatable way of threat modeling more effectively and across more products. The earlier this can be performed in a product development lifecycle, the more effective it becomes - in both cost, remediation avoidance, and resources.
We also asked on our latest webinar, whether companies are manually or just starting threat modeling or have a full program in place. Great to see that 67% are manually doing this as a minimum, or have more mature activities in place.
How does IriusRisk Threat Modeling support Secure-by-Design Strategies?
From a secure by design perspective, customers are leveraging that during the architectural review process. Oftentimes they'll leverage things like templates, to enforce good practices across their users, and heightened repeatability and structure from their IriusRisk instance.
Our Security Content Libraries further instill security and engineering teams to choose and use best practices throughout their processes and enrich the experience to bring security considerations in earlier and across teams. it's like having an engineer sitting on your shoulder the entire time going, ‘Maybe that's not a great idea’ or ‘When you check that box, it's going to increase your risk’. It guides them through the process. This of course allows scalability from just a few systems being threat modeled to hundreds if it is necessary for your industry.
This then brings the next step of Secure-by-Default. By putting up guardrails and a centralized policy enforcement, it prevents users from making those insecure items. And that's ultimately the outcome of good threat modeling is, to augment existing processes, and prevent insecure products from being possible. Security Managers and Architects cannot be everywhere and they can become a bottleneck due to a high number of developers vs security people. Couple with them sometimes getting bad perceptions as they are the gatekeepers of releasing bad code! A more harmonious relationship between DevSecOps is better for everyone.
What separates good threat modeling and great threat modeling?
We believe it has three core activities; buy-in, process, and priorities. See what they are in the short clip below:
Good processes break down walls between development teams and security teams. DevSec or DevSecOps is not new. But again, the reality all too often is that there is a separation between traditional security teams and development and engineering teams. Having to go through a threat model process, and especially when that process is facilitated by good technology, breaks down those barriers and encourages conversation. What are we designing? What is it going to look like? Let's talk about those threats.
Doing threat modeling at the beginning of a system architecture also aids that buy-in. It informs the stakeholders about the risk that needs mitigation, right away and early on. This supports senior managers to demonstrate that threat modeling is not a cost,but actually saves time, and improves communication on security delivery.
When you have full buy-in and a defined process for all stakeholders, this makes the prioritization part much easier. Especially if you incorporate a Security Champion Program to keep momentum going. The platform identifies and prioritizes the risks for the relevant teams, and can be passed across into tools such as issue trackers, for remediation work to take place. A full audit trail can also support Risk & Control requirements.
What next?
It’s okay if you need to crawl, and then walk, rather than run full speed into your proactive security program. Start with your most critical systems and engage all the stakeholders from the beginning to get good processes established, and multiple views around the cybersecurity table. In time you can transition this process across your portfolio of products, have a single source of truth for workloads and priorities, and ultimately have security considerations built-in - and not an afterthought.
