This is the second post in our Threat Modeling series. We recommend reading the "starting out" post first to get a baseline and overview on this practice. In that initial post, we pointed out that Threat Modeling should be inclusive of disciplines and can be done any phase of the SDLC. This practice helps surface gaps and issues earlier in any project (see our post on Left-Shifting), but has side benefits in building a cohesive team. In this post, we'll further explore team and culture benefits.
No matter when or how you do it, Threat Modeling offers benefits in aligning the various project disciplines and stakeholders. Too often development teams (Dev) create solutions that are difficult to deploy and scale because they are focused on the requirements and capabilities versus the final deployment and operations. As a result, Dev can't reproduce or do effective debugging of production issues because there are too many differences between what they developed and tested, and what operational and hosting teams (Ops) actually deployed and configured. Or worse, the architecture and design gets materially changed in deployment and scaling such as attempting add multi-tenancy onto a design intended to scale by adding tenant instances of databases or services. It is never Dev's intention create a solution that is difficult to scale and operate, rather it's a byproduct of how they are focused by the requirements and goals they are given.
Years ago, it was quality assurance teams (QA) that would have a solution tossed over the proverbial wall to be tested. This led to contention between the Dev and QA teams and unhappiness in leadership when there were late-stage schedule slips or buggy code releases. This situation has been improved via Agile practices and getting QA included either from the project start or simply blended with Dev (e.g., Microsoft's test practices). Many Ops teams are in the same situation now. It can makes sense to blend Dev and Ops teams (see our post on Ops Venn), but at the least the team should have aligned leadership and goals (e.g., Ops as a cost center versus profit center). To that end, Ops should be included early and get multi-discipline commitments for the project. At Cylidify, we cannot emphasize enough our belief that earlier is always better (including with Threat Modeling) and a business should not commit to building anything without commitments to quality and cost-effective scaling and operations.
Threat Modeling is iterative and presents great opportunities for being inclusive of Dev, QA, Ops, Support, and Services disciplines(with a red thread of security). Not only will you surface security and privacy threats, but also issues or gaps in aspects that require continuous adjustments and compromises such as scaling, performance, visibility/monitoring, and servicing. Ops teams have been early adopters of offensive and penetration testing practices (including adversarial simulations), which have a lot in common with Threat Modeling. So, Ops will add value to this practice as well as a different perspective in the design and analysis aspects — same for Support and Services. (Cylidify believes that having an architecture council/team supporting both Dev and Ops is the right approach for most business with many benefits, including organizational alignment and Threat Modeling sponsorship.)
Regardless of the forcing function, getting the disciplines together in the architecture and design phases will pay dividends throughout the project. Threat Modeling exercises will make the disciplines feel included and allow them to establish a sense of ownership and pride in the solution. It will establish a common ground on terminology, services, stores, and trust boundaries. It will also allow for issues to be surfaced and tracked from architecture and design through implementation and into operations, maintenance, support, and services.
It's not always easy, but Threat Modeling done early and inclusively can be very rewarding in terms of team building and collaboration. (And, Cylidify is available to help!) Even if you do Threat Modeling too early (rare), you will be able to realize most of the benefits. As the design decisions and implementation details are added, employing gamification or bounties to the analysis phase will increase participation and leverage team members competitiveness to improve the results.
The key benefit is in creating a solution that is more robust in its architecture and design with a shared understanding of scaling and operational required to meet the needs of the business and customers. Finding just one security, scale, or operations issue early can yield significant cost savings for the business increasing the solution's value and customer satisfaction. And, building a more cohesive team through Threat Modeling is a great bonus!
References:
See references in Threat Modeling "starting out" post.
Blending disciplines - https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/evolving-test-practices-microsoft
Team building benefits even without a "trust fall" or human pyramid: https://www.strayboots.com/blog/team-building-play-central-role-corporate-culture
Comentários