Summary

Building a security architecture program is not a simple matter of hiring some smart people and then giving them some training.

A successful security architecture program depends upon the support and collaboration of those who will interact and see the results of the program. Building a strong network of support is one of the key communication activities of the program, even a mature program. Senior management must not only assent to assessments, but they must also support the delivery of the requirements that result from the assessments. Grassroots support is critical to getting things done with the least amount of friction possible. And the inevitable challenges are far more easily solved through a supportive peer network. Building up your network will also be an important contributor to program success.

Finding the right people who have the relevant aptitude is, in and of itself, a nontrivial problem. Care must be taken to select for aptitude in a number of orthogonal areas: technical depth and breadth, communication skills, sociability, and a predilection to think architecturally about systems. I believe that a program will gain more success and proceed more rapidly by finding a seasoned security architect as the first or even first and second hire of the program. Whoever is hired at the beginning must also have the propensity to teach, coach, and mentor those who come afterwards. For most of us, becoming a seasoned security architect takes time, effort, and significant help from those who’ve gone before.

Training can help to set a firm base upon which to establish experience. Naturally, I hope this book offers at least some basis for training security architects who’ll perform assessments. Still, it will be on-the-job experience under the watchful eye of an experienced practitioner through which most of us deepen our craft. A culture of collaboration, coaching, mentoring, and peer review will help accelerate the learning process as well as prevent disaster from ensuing from the inevitable mistakes architects will make as they learn.

The primary output from security assessments must be a set of security requirements. That doesn’t mean that there cannot be other outputs; a threat model document can be very useful, not just for the security architects but for everyone who’s involved in implementing security requirements. It may also be useful to develop a threat model template in order to seed discovery and discussion that will lead to a thorough threat model. However, I do not favor a checklist approach unless the technology portfolio can be carefully limited to the items in the checklist.

If the program’s architects are perceived as adding value, if the architects are repeatedly invited to project team meetings, perhaps even sought out during system conception, this is a very strong indicator of a successful program. There are other quantitative measures. But care must be taken not to take simplistic totals as meaningful by themselves. Baselines built from the performance of successful architects can provide some measure against which performance can be compared. But, generally, even this approach can only indicate the possibility of a problem, not the problem itself.

Typically, security architecture programs don’t build themselves. There’s a fair amount of care and feeding that necessarily occurs to build a successful security architecture assessment program. Not to be too trivial, but it takes people, process, and technology. I hope that the foregoing tidbits help you on your journey.

References

  • 1. he Open Group (2005, November). Guide to Security Architecture in TOGAF ADM, p. 5. Retrieved from http://pubs.opengroup.org/onlinepubs/7699949499/ toc.pdf.
  • 2. Schoenfield, B. (2014). “Applying the SDL Framework to the Real World” (Ch. 9). In Core Software Security: Security at the Source, pp. 255—324. Boca Raton (FL): CRC Press.
  • 3. Ibid.
  • 4. George, B., Sims, P., McLean, A. N., and Mayer, D. (February 2007). “Discovering Your Authentic Leadership,” Harvard Business Review.
  • 5. McGraw, G. (Jan. 18, 2013). Cigital Justice League Blog: Securing Software Design

Is Hard. Retrieved from http://www.cigital.com/justice-league-blog/2013/01/18/

securing-software-design-is-hard/.

6. Schoenfield, B. (2014). “Applying the SDL Framework to the Real World” (Ch. 9). In Core Software Security: Security at the Source, pp. 255—324. Boca Raton (FL): CRC Press.

 
Source
< Prev   CONTENTS   Source   Next >