What actually is Security Architecture?
Security Architecture resonates differently with different people. Sometimes it refers to the specific implementation of a protocol, sometimes it is the security requirements for a new application, and sometimes it is synonymous with strategy or product management. In reality it can be all of these things based on the size of the security team and the needs of the greater organization. Fundamentally, security architecture programs should have the following offerings:
Implementation guidance on security policies or requirements: Far too often, security programs produce security policies that are not grounded in reality or reflect the tooling in the environment. Policies should be actionable and enforceable. One way to make them enforceable is by ensuring each policy requirement has Implementation Guidance. This type of guidance can range from a design pattern, sample code, or tooling configuration. The guidance should be as concrete as possible and available across an organization to access.
Aid enterprise technology teams during design: Whether it is in a consultative nature, a member of an enterprise (architecture) review board, or as a formal tollgate - security architects first goal is to enable technology. Embedding security architects with solution architects is an easy approach to ensure controls are baked into design and scans, tests and pre-deployment are used to catch for outstanding flaws or vulnerabilities.
Advance security controls and designs by providing forward-thinking, threat-informed reference architectures: Security architects need to be thinking one step ahead of the rest of the security functions. Reference architectures and patterns cannot become stale, they need to be routinely updated with threat intelligence, changes in technology across the organization, and with emerging concerns. While some think that security architects are in an ivory tower - they are not – they are in the equivalent of a castel’s watch tower understanding where the next evolution of exploitation is coming from. Two great ways to memorialize the evolution of threats coupled with required controls is developing (and maintaining) 1) security maturity model and 2) top threat models against the organization.
Across these three pillars it is easy for a security architecture team to get wrapped up into writing policies, assisting assessment teams, and spending endless hours across other technology architecture teams, so time management of a security architect and prioritization of the group’s efforts are critical. The security architecture team should not be the largest - nor the loudest - team within the security organization, but it should be a trusted advisor and an accountable party for the next generation of a technology ecosystem
