By David Graves
Architectural threat analysis combines strong architecture specification with threat analysis, enabling early discovery of risks and discussion of alternatives. Twenty five security professionals gathered in a lively peer to peer session at RSA Conference 2017 to discuss how cross-organizational teams can collaborate to produce and analyze architecture specifications to drive secure application development.
We agreed that strong architectural specifications empower threat analysis, but had differing experiences in putting the concept into practice. As our discussion progressed, a few recurring themes soon became apparent: collaboration, architecture patterns, and effective communication.
Collaboration
A few indicated that their engineering departments were required to document their architecture as part of their Software Development Lifecycle (SDLC). Others indicated that their security team collaborates with engineering to co-author the architecture specification, not driven by an SDLC requirement. In either case, collaborative authoring was deemed to be a means for building a relationship with engineering while doing security consultation as needed. The collaboration provides a way to explain why each control is in place.
Architecture Patterns
Several participants described how they teach the use of architecture patterns to drive consistency and standardization of application architecture across the organization. These patterns often follow generally accepted approaches for application organization, such as designing applications in tiers or terminating network encryption at the load balancer or organizing your applications components into already-accepted zones of trust. By definition, architecture patterns are re-usable. Engineering teams choosing to follow a pattern have the benefit of matching an already reviewed set of constructs rather than having to design something all new and defending the logic of how it will be protected.
Effective Communication
Some participants shared that they needed to support business lines, working with both technical and non-technical people, and wanted advice on how to bridge the communication gap to the non-technical people. Answers included learning “business speak”, stating security risks in layman’s terms, and giving analogies. Winning approval to invest in architecture specification becomes easier when all participants see the business value.
These discussion themes were interrelated and resulted in discussion threads that returned to assertions of how collaborative architecture specification, using accepted architecture patterns, supported a security assurance program resulting in more secure applications.