III Summary and Afterword
As we learned in Part I, only the extraordinary person can walk in cold to an assessment and achieve good results. From the organizational through the technical, from system architecture skills to some sort of risk methodology, there is an entire body of knowledge that precedes an actual threat model analysis.
In Part II of this book, a series of six detailed architectural analyses was presented. Each of these was meant to build upon the skills of the previous assessment while, at the same time, introducing one or more new security architecture problems and their possible solutions. There is no doubt in my mind that I’ve omitted some goals and details: A number of the exclusions were purposive in order to keep the book tightly focused as a course in applied security architecture and threat modeling. And, as was noted previously, these are fictional architectures. Architectures in the real world tend to be even messier than these examples. And throughout the analyses, I have avoided digging down into implementation details, even though these engineering aspects are also critical to the delivery of secure systems.
Instead, the analyses attempt to follow a path as would typically be followed in an analysis. In the first example, we strictly follow the ATASM method. Along the way, we factored an architecture, identified and prioritized threats, applied the threat’s methods and capabilities to the attack surfaces, and enumerated existing mitigations. Then after applying a risk methodology to the attack surfaces in the threat model, we prioritized credible attack vectors (CAVs) and developed a series of security requirements to mitigate the enumerated CAV.
After the first example, I tried to follow a more real-world approach such that new discoveries and areas of investigation turned up additional attack surfaces requiring additional defenses. Each of the analyses was meant to demonstrate how a security architect would probably think about these problems and reach decisions about priority and security requirements. None of the analyses was meant to be exhaustive.
In Part III, we took up some facets surrounding the application of security assessment and threat modeling to larger portfolios of projects. Standards become a key tool to allow projects to be self-sufficient and to minimize design and implementation errors. Wherever a vetted standard can be used, the standard solution can be implemented without further need for analysis. This approach saves the human factor for unique and exceptional situations.
Once an organization is delivering multiple systems through writing software, integrating existing systems, or some combination of the two, there will be a need to govern, so that processes and activities actually get executed in a proven and repeatable manner. I explain some of the approaches that have encouraged innovation while at the same time making sure that due diligence processes are, indeed, followed.
When building a security architecture team, appropriate people have to be hired, trained, mentored, coached, and supported so that they can be effective. Since hiring more than a handful of experienced practitioners is difficult at the time of this writing, training and then mentoring through a long process of experience and practice will be a determiner of success. Even though I’ve tried very hard to clarify and elucidate the kind of thinking that goes into a security assessment, gaining the necessary experience to be able to work independently still requires a significant investment.
Furthermore, in any large organization, there will be many stakeholders with many different perspectives who all have to agree that securing systems is the right thing to do. Organizational support must extend upwards to the highest levels, across through middle management, and downwards through line management and to the grassroots people who are accomplishing the tasks that will ensure the security of an organization’s systems. Building communication and relationships through this network is a nontrivial task that will need significant effort and focus.
In Chapter 13, I included some of the larger programmatic mistakes of which I’ve been a part in the hopes that you, the reader, won’t have to make the same mistakes in your program. I hope that these little anecdotes provide at least some insight into the subtleties of running a security architecture program?
If you’ve made it this far in this book, Bravo! I’m sure that some of my language is not particularly clear. I’m willing to bet that some of the aspects of security that I’ve tried to cover are fairly dense and perhaps, difficult to understand. There is no doubt that I’ve made one or more technical mistakes in these analyses. For these, I ask your forgiveness; please don’t throw out what is useful because I’ve made some errors along the way.
Nevertheless, I hope that on this journey of applied security architecture and threat modeling there have been at least some tidbits worthy of the time and effort you’ve made to slog through this book. As I said at the beginning, if I can add just a little to the emerging practice of security architecture, and perhaps a little controversy, I will be tickled pink.
In any event, always remember that there is more than one way to skin a particular security cat; there are usually at least a couple of different ways to arrive at more or less the same defense.