By David Graves, Distinguished Technologist and Security Architect at Hewlett Packard Enterprise

The increasing acceptance of Agile development is driving shorter release cycles, sometimes placing application security at risk. Has the pace of Agile development displaced strong solution architecture? Twenty-five security professionals gathered at RSA Conference 2016 to discuss this and related questions in a lively Peer2Peer session. 

Has the pace of Agile development displaced strong solution architecture?

Several participants expressed concern about the challenge of maintaining strong and secure solution architectures while maintaining a brisk pace of development. This concern was predictable and natural, since the discussion was had by people who gathered to discuss this very issue. Some participants pointed out the difficulty in hiring enough experienced security professionals to embed in each development team, while others pointed out that a small team of security professionals can provide consulting to many development teams.

Must discovery of vulnerabilities occur only after solutions are implemented?

While it’s generally accepted that early discovery of flaws is less expensive than discovery late in the development cycle, a few of those attending were surprised by the assertion that it’s possible to discover threats even before code is written. Several others agreed that some vulnerabilities are evident during the design phase, so architectural review can be useful even before code is written. Code review and penetration testing are still essential later in the development cycle, of course, and those activities can occur only after code has been written. 

Can rapid, flexible development be integrated with sound architectural practices for solution security?

Throughout the industry, security teams must analyze threats in fast-moving Agile environments, where product definitions continually change until late in each cycle. The discussion leader asserted that in order to meet this challenge, security professionals can use an integral approach combining architecture definition with threat analysis, and this assertion was supported by several who worked in organizations with mature processes. This was a new concept to some of those in the group.

How does your organization use architectural processes to drive development of secure applications?

Not all of the participants worked in organizations that used architectural processes to drive development. Those that did use such processes generally agreed that it was beneficial to combine architecture definition with threat analysis. Such practices enable early discovery of risks and gaps, and provide a forum for early discussion of the security implications of design alternatives.

Has formalized architecture definition contributed to your organization’s process for threat analysis and risk mitigation?

Again, answers to this question were mixed, since architectural processes were not used by all.  In the teams that did integrate architectural processes, the practice was deemed useful. In more than one organization, engineering teams were required to develop architecture specifications that adhere to the organization’s standards. In more than one case, those standards were influenced by or defined by the security team. Those architectural specifications were then used as part of the threat analysis process. The resulting specifications included the security controls placed on each interface between components in the solution architecture. 

How do you get the architects to produce all that?

It was deemed helpful to integrate the requirements as checklist items in program management’s release gate processes. Then the architects have to comply with the requirements for architectural specification and subsequent architectural threat analysis.

Once you launch architectural review process, there are multiple benefits such as reusability of the architecture specifications produced. Teams frequently refer to other teams’ specifications. Inconsistencies and gaps between service architectures are discovered earlier. Preparation for subsequent threat analysis reviews is easier, since each team need only update their existing architecture specification to reflect changes in their architecture.

Another benefit discussed was improved relations between the engineering and security teams.  When this process is used, engineering architects frequently contact the security team to discuss the security implications of design alternatives they are considering. Rather than trying to avoid or delay security review, they initiate contact to get security consulting at the earliest phase of development, which is a dream come true to some security professionals.

What are the artifacts that your organization requires in an architectural specification?

The combined set of specification artifacts called out by the group included: a logical diagram, a physical diagram, the inputs to the system, the outputs from the system, the trust boundaries, the data description, flow diagrams, security attributes of each service, use cases, patterns, and principles.

What are our conclusions?

Documents could benefit from co-authoring between security architects and engineering architects. These processes can be used on a small scale, and then ramp up as resources allow.  Results from architecture-based security reviews include the architectural specifications and the threat analysis findings from each review. These results, plus tickets from findings that have been resolved, provide proof of due diligence to auditors.

Many in the group agreed that they could apply the discussed approaches in their organizations to enable stronger integration of architecture definition with threat analysis results. When it was time to leave, some discussions continued down the hallway as we moved on to our next activity at the conference.

David Graves is a Distinguished Technologist and Security Architect at Hewlett Packard Enterprise and is responsible for architectural threat analysis in the Helion Cloud organization.  His areas of expertise include solution architecture, cloud computing, information security, and patentable innovation.  David is a Certified Information Systems Security Professional (CISSP), a Certified Information Systems Auditor (CISA), and holds fifteen patents for cloud security automation.