Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models


How does an organization train people so that they can perform these difficult, architectural tasks? Software security expert Gary McGraw says:

For many years I have struggled with how to teach people. . . security design. The only technique that really works is apprenticeship. Short of that, a deep understanding of security design principles can help.5

In Core Software Security, I amplified McGraw’s wisdom:

McGraw’s statement implies that, in order to build a qualified team, each organization will either have to invest in sufficiently capable and experienced practitioners who can also mentor and teach what they do, or hire consultants who can provide appropriate mentorship. Neither of these is likely to be cheap. As of this writing, there is a dearth of skilled security architects, much less the subset of those who can and want to impart what they know to others. The architecture and design skills necessary to an SDL program are probably going to require time to build, time to find key leaders, and then time for those leaders to build a skilled practice from among the available and interested people at hand. In one such long-running mentorship, even highly motivated junior people have taken as long as two or three years before they could work entirely independently and start to lead in their own right. This is a significant time investment.6

Up until Michele Guel’s Security Knowledge Empowerment program (“SKE,” National Cyber Security Award winner, 2011), security training tended to focus on engineering skills, not security architecture skills. Up until about 2010, as far as I know, Gary McGraw hit the nail on the head. That is, security architects learned by following a seasoned security architect through her or his day. That’s the way I was trained.

First, the candidate “shadows” the teacher through any number of projects— watching, learning, perhaps trying out ideas under the tutelage and observation of the practitioner. Then there comes a period when the candidate is shadowed by the teacher. In this way, the new security architect has someone to turn to. And, also important for any organization, if the seasoned security architect believes that something dreadful will happen, they can step in and prevent catastrophe. Finally, if all goes as planned, and it often doesn’t, the new architect works more independently with regular mentorship and coaching by the teacher for a period of time, often as along as a couple of years.

Almost every architect I know of learned in precisely this manner. The problem is that not everyone learns by following someone around. What if you’re assigned to a mentor who you cannot work well with? What happens then? Most likely, the seasoned architect will continue in the role, but the candidate will seem to have failed. I’ve long thought that this is entirely unfair to talented people who have other learning styles. Not everyone likes to follow me around. Sometimes, even I don’t like to follow me around.

Guel’s SKE program had an architecture section. Michelle, Vinay Bansal, and I built a curriculum and then attempted to teach it to the class. The class consisted of a group of interested coworkers who had volunteered to attend for the 40 weeks and do the homework. Some of those students went on to a security architect role. More importantly, we proved to ourselves that it is possible to impart at least some of the skills of security architecture in a classroom setting by using lectures, case studies, and class discussion, as opposed to following Michele, Vinay, or Brook around for a couple of years.[1] We did follow up with formal mentorship for those who were going on to a security architect role.

Today, there are at least a few online videos from conferences describing threat modeling. There have been a couple of books on the subject, as well. And a couple of vendors offer video classes. Still, I believe that there is no substitute for experience, especially when that experience can be held in a container of relative safety.

So what does classroom training look like?

Obviously, you could work through the material in this book. Possible classroom use is one of the purposes that I hope this book will serve. Or use any methodology that works.

Assuming that the students already have some experience in computer security and with system design, I teach in the following manner:

  • • Introduce security assessment as a part of security architecture
  • • Introduce security architecture in its entirety, but with a focus on security assessments, in particular
  • • Delve into understanding architectures
  • • Practice architectural decomposition and following data flows
  • • Introduce the ATASM process
  • • Analyze architectures and present case studies

After students have some feel for what architecture analysis for security and threat modeling is, I’ve had a lot of success facilitating participatory ATASM sessions. I gather as many of the people who will interact with the threat model on the team as possible. I don’t limit the session to just the security architects and those who are directly responsible for implementing the security requirements.

I like to keep these participatory sessions as open as is practical, given constraints of time and proprietary intellectual property protection needs. Even a test engineer who won’t be involved in the threat model in any active way will conduct better tests if she or he has some context for attack surfaces when testing. Then, the testing is more likely to, at least in part, prove the mitigations that have been built (i.e., above and beyond the security tests that have been placed into the formal test plan). The entire project benefits from the exposure that active participation in a threat model gains.

I walk through the ATASM process precisely as this book is laid out:

  • • Learn the architecture
  • • Gather all threats (brainstorm)
  • • Talk about which threats are relevant to this system as it will be deployed for its purposes in the organizational context
  • • Discover as many attack surfaces as possible
  • • Consider existing security controls and possible mitigations

The goal of the session isn’t to produce a complete threat model. I will often move onto the next step, in consideration of available time, so long as a deep conversation around a particular step in the process has occurred. I don’t provide the answers to these questions, though I may fill in towards the end of the discussion to highlight areas that haven’t already been covered by the participants. The goal of the class is active participation, nothing else. I want the people present to consider the issues, to delve into the complexities that building a threat model inevitably encounters. I’m after rich discussions, not particular engineering results.

At the end of the class, there may or may not be a complete threat model. That’s OK. Even if the threat model is incomplete, the participants now have the skills to finish it.

I know that this format works very well. I’ve done as many as twenty-four of these in a four-week period, in many locations, spread across distinctly different cultures. Engineers and architects love to consider weighty problems. All that’s really required from the facilitator is a willingness to start the ball rolling on each step and, sometimes, a little encouragement to participants.[2]

Once candidates have completed whatever formal training is offered, I then employ a period of “shadowing” an experienced and proven security architect. I described shadowing above.

One of the reasons that organizations perform security assessments is to help ensure that systems don’t go live such that the system reduces the security posture of the organization in some fundamental way. This is a “due diligence” responsibility. In other words, the security assessment is, in part, an attempt to keep “bad things” from happening through the implementation and deployment of insecure computer systems. This role imbues the security assessment with a fairly heavy responsibility for the safety of the organization. As such, entrusting this responsibility to someone without the experience to perform the duty might lead to a disaster. The “safety container” is the peer review and coaching (and empowerment) of one or more practitioners with enough experience to carry the load appropriately.

Consequently, except for very small organizations that can get by with just one or two security architects, I favor putting someone in the role first who can carry it off properly. That first practitioner, who has to be good enough at security assessments and threat models to prevent the truly disastrous from unfolding, can then create a container in which others can make some mistakes and gain experience.

But for those readers who feel like they’ve been placed in the role without having had sufficient experience, I would counsel that your management and their management need to understand the risk the organization has taken.

You will help yourself immeasurably by finding any resources, security or otherwise, who have some architectural experience who can then be your peer reviewers on difficult decisions. Peer review is always a critical part of a good program.

Furthermore, if you find yourself placed in the security architect role and you don’t have the background and experience that’s been described in this book, I would also suggest that you find seasoned practitioners from whom you can get the mentorship that you will need. Furthermore, you will need an experienced practitioner with whom you can discuss the problems that you encounter and from whom you can receive the necessary peer review that every security architect needs. Again, transparency with your management is critical, since you are likely to make some mistakes along the way. I’ve certainly made my share; I’ve made some massive misses and miscalculations. Luckily, my management have always supported me so that I’ve learned from those experiences.

For others who will have a larger team, for security architects who are working in a team, and, of course, for those who have to build and manage a team of high- functioning security architects, the next section will explain some of the things I think are critical to support your team.

  • [1] I don’t know if SKE marks “the” beginning for formal security architecture pedagogy. ButSKE certainly represents “a” beginning.
  • [2] If there are managers present, I insist that anything said in the room can’t be used against theparticipants, or for performance review of participants. Or managers have to leave the room.It has to be safe to experiment, or these classes won’t work.
< Prev   CONTENTS   Source   Next >

Related topics