Documenting an As-Is Security Architecture, part one

This is the first of a two part post, part two is available here.

The following list is a set of activities that need to completed at least once to document an existing As-Is security architecture view for a business architecture and then need to be maintained over time through repeat reviews.

The activities include:

The outputs from these activities serve as some of the key inputs when determining the desired To-Be security architecture. I’ll cover the To-Be security architecture in a future post.

I use this as the scene setter for conversations with program managers, enterprise architects or CIOs who are looking to make big changes to the existing business and IT architecture and want to be sure the security is keeping step. This isn’t everything you could do but it is a pragmatic set of activities with defined outputs that get you to a position of knowing if you’re standing on rock or standing on sand before you build.

Establishing scope

This activity is focused on clearly stating the scope of the security view of the business architecture.

The key constraints to identify at this point relate to areas of the business architecture for which the security architecture is managed outside the direct governance of the current activity and which as a result the current activity has limited or no ability to influence or even know about.

Tasks:

• Review existing business architecture
• Draft scope statement
• Present to the governance body for the business architecture for validation

The output is a scope statement for the security view that is validated by the key stakeholders.

Identifying governance

This activity is focused on clearly identifying the role and scope of the different security stakeholders and management forums across the systems and information assets in-scope for the business architecture.

This must include a review of the Terms of Reference for any identified security management groups. The boundaries of responsibility of each group should be clearly drawn and gaps identified.

Stakeholder environments and partner environments must also be considered both from the perspective of the body accountable for the security of the environments and if different the body responsible for delivering the security of the environments.

Tasks:

• Review all Security Management Groups Terms of Reference
• Identify Business and Risk owner roles for all areas in scope and boundaries between them
• Review any contracts or agreements that govern cross boundary information exchanges for security relevant content

The output is a diagrammatic representation of governance structure with an associated textual description.

Identifying and valuing assets

This activity is focused on identifying all current and planned information assets within scope of the business architecture.

This will review the information assets represented in the business architecture Information Model for completeness (e.g. including logs and other related information captured during user or administrator communications). Where gaps are identified these should be described in a compatible format with the Information Model. A decision will need to be made as to the utility of adding these information assets to the core Information Model or generating a security specific Information Asset Model. Once a reasonably complete list has been created each assets description will be extended with the following attributes:

1. Owner (possibly multiple stakeholders for multiple instances)
2. Business valuation (Confidentiality, Integrity, Availability)
3. Underlying driver of the valuation (Overall Content, Subset of Content, metadata etc).
4. Any accumulation levels for business valuation increases for collections of a single type of assets
5. Any association rules for business valuation increases for collections of multiple types of assets
6. Changes in business valuation due to other characteristics (At rest, in transit, age, pre/post processing)

Tasks:

• Review Information Model
• Update Information Model with any new information assets
• Identify owners for all assets
• Develop strawman business valuation and associated characteristics for each asset
• Review strawman business valuation with appropriate governance body / owners.

The output is an updated Information model in the business architecture and an associated information asset list.

Describing threats

This activity is focused on identifying and characterising the threat sources and threat agents with interest in and access to the assets in the scope of the business architecture.

Any existing threat models are to be reviewed. Where other sources of considered threat descriptions can be identified for the scope of the business architecture these will be included.

It may be possible to have a confidential discussion with the delivery team and partners in the delivery of the business architecture to get their views and experiences of threats in their environments that could be fed back into the overall threat assessment. The goal will be to produce a blended threat model covering all the assets across the entire scope of the business architecture. Where gaps in the coverage are identified these will be noted and highlighted to the appropriate governance group.
Tasks:

• Review existing threat models
• Collect partner and delivery team experiences of threats in the delivery environments
• Create blended threat model

The output will be a Architecture Threat Model in a textual description.

Part two of this post is available here.