Building an Assessment Program
- • Threat models are living documents; they change and, thus, must be kept in sync with changes in architecture and design.
- • Agile requires continuous engagement, since architecture and design are iterative and parallel processes (parallel to themselves, to implementation, and to testing).2
There is probably no value in my repeating these programmatic thoughts here, beyond the bulleted list, above. Instead, I will focus on the people who will assess and how security architects form into a team.
My goal for my security architecture program is not to be a policing function that enforces a set of laws to which all projects must hew. Although it is important to establish a set of architecture policies and standards, these cannot be immutable laws to which every project must conform or suffer some dire consequences. The world of computer security is far too changeable. And computer security exists as an attribute, an emerging property (or not!) of systems that exist within an extremely rapidly changing context, that is, digital technology. It is simply too difficult to anticipate all circumstances, external and internal, in a policy at this time.
Rather, policy becomes the bedrock to which many systems can mostly conform. The standards that set out how the policy will be enacted create an easy path, a reasonably secure path that can be followed. At the same time, policy and standards help to define areas and situations that will require creativity—those systems, connections, technologies that are necessary but which cannot conform: the exceptions to standards. Sometimes, these exceptions will reduce the security posture. Sometimes, exceptions will offer an opportunity to mature security in new ways or open opportunities to adopt new technologies.
Take, for instance, Agile software development practices. When these were first being widely adopted, like many security practitioners, I was very suspicious and concerned. It seemed that Agile’s penchant for changing design during implementation flew in the face of every process we had put into place to ensure that designs would include necessary security. Security assessments and the resulting requirements were heavily front-loaded in our processes; we counted on implementations that followed upfront guidance closely. There seemed to be considerable tension between Agile and security architecture practice, as we had built it (which was as much an industry standard as existed at that time). In any event, the company at which I worked had some teams who were wholeheartedly adopting the SCRUM Agile methodology. A couple of those experiments did, indeed, seem to shift or lose their security requirements through the Agile process. What was I to do?
My first approach was to put governance checks around the Agile process, to circumscribe it with security assurance. Requirements had to be given with a “don’t change” caveat. And there was a governance check, with security having a “no go” blocking power once an application was ready for deployment.
I reasoned that if the requirements were clear enough and security had the power to demand change or stop a project before it went live, then due diligence duties to protect the company could be served. I remember presenting about this Agile security approach at a security sharing forum of major companies that I attended regularly. It turned out that my company was the only company with enough Agile to worry over; Agile was not on anyone else’s security radar. I was out on the edges, all alone.
Later, I participated in a couple of Agile projects and saw how SCRUM works from the inside. Subsequently, I had SCRUM training (at another organization) and participated in a wholesale convergence of an IT delivery department to SCRUM. Through these experiences, I came to appreciate the Agile approach, the ideals that underlie SCRUM, and the merit to be reaped from Agile adoption. Perhaps you can say that I’ve been “agilized”; I’m certainly no longer afraid of Agile; I’ve seen how valuable it can be even for security, when Agile is done well.
The point is that Agile did not fit with the first organization’s policies nor its standards. Agile was exceptional. Still, adopting Agile proved to have great value, both to that organization and, ultimately, to our security posture, as well, once I (and we) had allowed ourselves to step into the challenge and reap the opportunity offered. If we had instead taken an enforcement line, the opportunity would have been lost, and, quite possibly, we also would have lost those relationships, the trust, and influence that allowed us to be effective. A law and order attitude would have been disastrous.
If a team is trying to “game” the system, to avoid security assessment and requirements, governance is there to try and avert disaster. But I try not to mistake my due diligence responsibility to the overall security posture and risk tolerance that I hold with a blind adherence to a set of documents that I know will always be incomplete in the face of change.
I’m not suggesting that we throw away policies and standards. If you’ve come this far in this book, I hope that you understand the importance of these. But I don’t want to use these to stunt creativity and innovation. Rather, these are there as a comparator against reality in order to identify the deviant and the exceptional.
My friend and colleague, Ian Savage, says, “It’s like community policing. You can sit around waiting for bad things to land in your lap, or you can proactively try to prevent problems.” I’d add that not only can we try to “prevent problems,” but we can proactively look for opportunities for growth and change for the better.
In this chapter, I will cover four areas:
- 1. Program relationship building
- 2. Acquiring and building a team
- 3. Outputs of an assessment process
- 4. Measuring effectiveness
I’ve tried to keep these topics focused on the subjects not usually covered in other works on security programs—that is, policy, organizational structure, and the relationship between security architecture and other aspects of an information security program. These subjects, I believe, have been abundantly explained multiple times and from multiple angles. Due to my focus on that which doesn’t usually get described, the following will necessarily be incomplete. I assume that many of you, the readers, either already have running programs or have previously been introduced to the other programmatic aspects that I have not addressed.
-  Security architecture callsfor its own unique set of skill requirements in the IT architect.1 For security architecture, the main ingredient will be the people and their skills to perform assessments and, ultimately, to craft and then drive security solutions. This comesdown to the individuals and how to form your team. Many books have been written about security policies, managing security programs,and the like. For software security (which does not comprise the whole domain ofwhat’s covered by security architecture, as defined in this book), I think that Dr. JamesRansome and Anmol Misra’s book, Core Software Security: Security at the Source, forwhich I wrote a chapter, will provide a fairly complete program blueprint, includingwhat value security architecture delivers, how its applied, where it fits, and how tomanage and govern an architecture program. I set my thoughts down in Chapter 9 ofthat book, essentially, as follows: • Pre-architecture engagement fosters discovery and inclusion of required securityfeatures.
-  For new architectures, security engagement throughout the architecture cycleimproves the integration of security requirements (vs. a one-time assessment). • For existing architectures, only architecture changes need to be assessed and threatmodeled. • Any change in design of security-related portions or components necessitates asecurity design review.