Security Champions: The Importance of Threat Modeling

Security champions may be tasked with building threat models for the software their teams generate. For champions who must threat model, they will usually be more effective if given significant support. This article outlines some of the key assistance that will aid the building and use of threat models through a champions programme.

Because champions are a part of development teams or are co-located with or assigned to development teams, they can more readily ensure that security is integrated into every aspect of the development process organically and naturally, including threat modeling. One of the most important benefits of a champion vs a central team: the champion is an integral part of the development effort, not someone interposed from outside. Which means that threat modeling becomes a natural part of developing software, integral to how each development team designs and constructs software.

Threat modeling is the technique through which potential threats to a system or application can be identified. The analysis then determines threat likelihood and expected impacts. It is a crucial step in developing a comprehensive security strategy and ensuring that security capabilities and controls are generated as an ongoing part of software creation. Our ability to design security and for security rests on a foundation of threat modeling, because the model tells us which security features and defenses a system will need based upon that system’s anticipated attacks.

In order for security champions to successfully deliver threat modeling with their development teams, most champion programmes must typically include the following functions:

Training
Consistency and governance
Documentation
Archive or repository

Training

Unless the number of development efforts/teams is very small, one, two, or a few experts won’t be able to meet threat model training needs, especially for more than a couple of champions. Indeed, the experts available to teach have to be willing, which isn’t true for every threat modeler. No matter the number of experts available, somehow, threat modeling training must be delivered to every security champion.

Of course, there are professional threat modeling trainers who can be brought in to provide training as necessary. Professional threat modeling training can be prohibitively expensive for smaller and less well-resourced organizations.

An alternative approach is to start with a discreet selection of champions, perhaps the most experienced security practitioners. Then, encourage every champion who shows promise as a trainer to teach. As trainees build confidence and skill as threat modelers, the existing threat modeling trainers identify trainees who might be capable and willing to teach. Over time, the number of trainers increases to fulfill the training needs of the organization. As teachers “train the trainer”, training becomes part of the fabric of the security champion community. When sharing what’s been learned is an advancement expectation for champions, there are always champions who take up the teaching mantle.

Governance And Quality

Large organizations who have champions at diverse skill levels will have relative newcomers threat modeling, as well as those who have gained significant skill levels. There are a couple of tried and true methods for ensuring consistent and comprehensive models.

Review boards: Probably the simplest method to ensure model quality will be to have the organization’s most experienced modelers review every model. These are often called “security architecture review boards”. For smaller development organizations, having a few experts review every model is straightforward and easy. As size and complexity grows, however, manual review by the few quickly turns into a development bottleneck which slows everything down and can even trap those few experts into a never-ending cycle of threat model review; they have no time for anything else. Manual review boards quickly become overwhelmed and a process burden.
Mentorship and pairing: An alternative governance model is to appoint senior modelers (perhaps the organization’s trainers?) who review for a collection of teams, perhaps on a product or related project affiliation, or other relationship or affinity of teams. One or a few “mentors” review for a subset of the models produced. This form of governance works quite well by also including one or more senior or mentor from another group, someone outside the group who brings experience but also independence and most importantly, “fresh eyes”, unclouded by being in the thick of development.
Federated reviews with escalation: Governance needn’t be heavy handed. One nimble model is to have every model and every model change reviewed by one person senior to the modeler and one person who is not involved in that specific software effort or project, i.e., an independent reviewer. In other words, three people are involved in every review. Because these are part of the development process (and assuming models are built and refined iteratively), reviews aren’t particularly time consuming. They can be as quick for minor changes as 10 minutes, often no more than 30-60 minutes. Federating model reviews means that nobody has to be specially convened. There is a caveat, though: if the reviewers cannot agree, they must escalate upwards to greater seniority. Eventually, if there is some issue that has not been decided at lower levels, the final arbiter must be the most senior technical security person. If they cannot decide, then escalation proceeds to executives. In this process, such escalations are extremely rare. We have seen 5000 developers with more than a hundred security champions escalate to the most senior level only once or twice within a period of years. Most issues are governed at a much lower level. The nice benefit from federate governance is that it scales to thousands of developers without requiring formal governance boards. requiring formal governance boards.

Whatever form governance and quality control takes, we urge cross-pollination by including modelers who are from outside the group or team or involvement in generating the model and software. One of the best accelerators to threat modeling skill is to model software designs with which one is less familiar, that presents new design patterns, new threats, new defense patterns. Include at least one or two people who are less experienced and who are less familiar with the software under analysis. Doing so provides real world experience and also helps to build a sense of threat modeling community.

Documentation

The type of documentation needed for threat models varies widely from an image of a white board to formal, archived threat model documents in a standard format. What must be kept, for how long, and where is highly contextual, depending upon industry standards, certifications, regulations, etc. A list of the security requirements output by the model might suffice for low regulation environments. Environments subject to strict requirements for a formal threat model will need their champions to produce what is needed and must have an archive where auditors or regulators can find the models.

The first step will always be to understand documentation and archive requirements if any. In addition, it’s important to consider model life, and how often it must be consulted and potentially refined.

Typically, once a system’s model has completed its first iteration, it will need to be reviewed and refined at least periodically. For system’s under active development, the model will need to be consulted, reviewed, and potentially refined every time a security significant change must be made to the system and whenever a new attack method is identified.

For the purposes of developer/champion review and refinement, models should be easily available to the development process, however they may be kept. Often, a link to the model in the development team’s wiki or task manager works well. Some teams keep the model itself in the team’s wiki, though this may be too decentralized when threat modeling is subject to stricter standards. When models are required by regulators, it’s probably best to place all models into a central repository. Doing so also provides a mechanism for ensuring that models are being generated as required.

It must be noted that a modeling tool by its very nature, enforces a standard model representation and should provide a repository for models across an organization.

However models are documented and retained, they should be available to development teams and their security champions so that the model can serve its purpose as a key input to building software.

Conclusion

Security champions play a critical role in threat modeling. Threat models identify potential threats and vulnerabilities, assess risk, and recommend appropriate mitigation strategies. Through building a champion network, security teams scale the threat modeling function. Since champions are an integral part of development teams, threat modeling is readily adopted, becoming an organic part of building software. Alongside these very important benefits, champion programmes surmount the challenges outlined above. Hopefully the solutions provided here will help threat modeling champions be effective and successful.

If more information is needed about champions and champion programmes, there are numerous articles describing what security champions are, why they are effective, and how to build a program. Some examples are:

5 steps to run a successful cybersecurity champions program
Avoid Unnecessary Pain with a Security Champion
How To Build A Network Of Security Champions In Your organisation

‍