Summarised - 2010

Security architecture has its own methods. These methods

might be the basis for a discreet security methodology.
Security architecture composes its own discrete view and
viewpoints.
Security architecture addresses non-normative flows through
systems and among applications.
Security architecture introduces its own normative flows
through systems and among applications.
Security architecture introduces unique, single-purpose
components in the design.
Security architecture calls for its own unique set of skill
requirements in the IT architect.
 Authentication

Risk
Authorisation
Management

Administration Audit

Asset Protection Assurance

Availability
 1. Business Rules

5. Data
Classification 2. Security Policy
Policy

Artefacts

3.
4. Risk Analysis Data/Information
Ownership
 Security Security
Policy Standard

Enterprise Requirements Management Process

New Security Requirements arise from many sources:

2 3
1

A new IT
architecture
A new threat initiative
A new statutory realized or discovers new
or regulatory experienced stakeholders
mandate and/or new
requirements
 A written Security Policy for the organisation must be in
place
Objective

ISO/IEC 17799:2005 a basis for the security policy

Architecture constraints established in the security policy
Security must be communicated
Assessment

Dependent upon the functionality of the system and the

data collected or maintained.
Regulatory The jurisdiction where the system or service is deployed
Requirements
 Relevant
Security Statutes
Policy

Applicable
Jurisdictions

Input

2 3 4
1

Security
Applicable Security Team Assumptions
Applicable Security Policies Roster and Boundary
Regulations Conditions

Output
 Obtain management support for security measures
Management
Support

Define necessary security-related management sign-off milestones

Milestones
of this architecture development cycle

Determine and document applicable disaster recovery or business

DR and BCM
continuity plans/requirements

Identify and document the anticipated physical/business/regulatory

Environment
environment(s) in which the system(s) will be deployed

Determine and document the criticality of the system: safety-

Criticality
critical/mission-critical/noncritical
 Business
Continuity
Security Disaster
Plans
Policies Recovery
Plans

Applicable
Jurisdictions

INPUT
 Output
2 3 4
1

Business
Physical Regulatory Security Policy
Security
Security Environment Cover Letter
Environment
Environment Statement Signed
Statement
Statement

6 7
5

List of Disaster
Architecture Recovery and System Critical
Development Business Statement
Checkpoints for Continuity Plans
Sign-off
 Determine who are the legitimate actors who will
Legitimate
Actors
interact with the product/ser vice/process

Assess and baseline current security-specific business

Baseline processes (enhancement of existing objective)

Determine whom/how much it is acceptable to

Security
Measures
inconvenience in utilizing security measures

Identify and document interconnecting systems beyond

Interconnecting
Systems
project control

Determine the assets at risk if something goes wrong

Assets at Risk What are we trying to protect?
 Determine the cost (both qualitative and
Cost quantitative) of asset loss/impact in failure cases

Asset
Identify and document the ownership of assets
Ownership

Determine and document appropriate security

Forensic
Process
forensic processes

Identify the criticality of the availability and correct

Criticality operation of the overall service

Reassess and confirm Architecture Vision decisions

Re-assess
 Business and
regulatory security
Applicable disaster
environment
recovery and
statements
business continuity
plans

applicable security
policies and regulations

Input
 Output
2 3 4
1

New disaster Validated

recovery and business and Validated
Forensic business regulatory security policies
Processes continuity environment and regulations
requirements statements

6 7 8
5

Baseline
Interconnecting
Target security security security actors
Systems
processes processes

9 10 11 12

List of trust
security
Asset list with paths and
tolerance for Threat analysis
values and Availability
each class of matrix
owners impact
security actor
statement(s)
 Assess and baseline current security-specific architecture elements (enhancement of existing
objective)
Baseline Architecture
Elements

Identify safe default actions and failure states

Safe default actions and failure modes must be defined for the system informed by the current
Default Actions and state, business environment, applicable policies, and regulatory obligations.
Failure States

Identify and evaluate applicable recognized guidelines and standards

Guidelines and
Standards

Revisit assumptions regarding interconnecting systems beyond project control

In light of the risk assessments performed, assumptions regarding interconnecting systems may
Revisit Interconnecting
Systems
require modification

Determine and document the sensitivity or classification level of information stored/created/used

Identify and document custody of assets
Classification Level Identify the criticality of the availability and correct operation of each function
 Determine the relationship of the system under design with existing business
disaster/continuity plans
Identify what aspects of the system must be configurable to reflect changes in
DR and BCM policy/business environment/access control

Identify lifespan of information used as defined by business needs and

regulatory requirements
Lifespan Determine approaches to address identified risks

Identify actions/events that warrant logging for later review or triggering

forensic processes
Identify and document requirements for rigor in proving accuracy of logged
Logs events (non-repudiation)

Identify potential/likely avenues of attack

Thinking like an adversar y will prepare the architect for creation of a robust
system that resists malicious tampering and, providentially, malfunction
Attacks arising from random error
 Forensic Business
Risk Analysis Processes Policies and
Threat Analysis
Guidelines
Matrix

DR and BCM
Interconnecting
Requirements Systems

Security Input
 Security Output
2 3 4
1

List of
Risk
Event log-level Data Life Cycle configurable
Management
matrix and Definitions system
Strategy
requirements elements

6 7 8
5

Security use-
New or
case models,
Baseline list of augmented Validated
List of
security-related security-related interconnected
applicable
elements of the elements of the system list
security
system system
standards

9 10 11 12

Information
Revised disaster
classification Function
recovery and Refined threat
report, List of criticality
business analysis matrix
asset statement
continuity plans
custodians
 Assess and baseline current security-specific technologies (enhancement of existing objective)
Revisit assumptions regarding interconnecting systems beyond project control
Baseline Identify and evaluate applicable recognized guidelines and standards
Technologies

Identify methods to regulate consumption of resources

Engineer a method by which the efficacy of security measures will be measured and
communicated on an ongoing basis
Measures Identify minimal privileges required for any entity to achieve a technical or business objective

Identify minimal privileges required for any entity to achieve a technical or business objective

Privileges

Identify the trust (clearance) level of:

All users of the system
All administrators of the system
Trust All interconnecting systems beyond project control
 Applicable Security
Standards and
Security-related Actors and Risk
elements and Management
interconnected Strategy
systems

Validated Security
Policies, Regulatory and
Trust Requirements

Security Input
 Security Output
2 3 4
1

Validated Selected Resource

Baseline list of interconnected security conservation
security systems list standards list plan
technologies

6 7 8
5

User Risk User trust

Security metrics authorization management (clearance)
and monitoring policies plan requirements
plan
 Identify existing security services available for re-use
Statutory or regulator y requirements may call for physical separation of domains
Security which may eliminate the ability to re-use existing infrastructure
Services

Engineer mitigation measures addressing identified risks

Mitigation measures must be designed, implemented, deployed, and/or operated.
Mitigation

Evaluate tested and re-usable security software and security system resources
Evaluate

Identify new code/resources/assets that are appropriate for re-use

It is appropriate to evaluate those new solutions for inclusion into any existing
Re-Use libraries, archives, or other repositories for future re-use.
 Assess the impact of new security measures upon other new
Impact components or existing leveraged systems
Assessment

Implement assurance methods by which the efficacy of security

measures will be measured and communicated on an ongoing basis
Assurance
Methods

Identify correct secure installation parameters, initial conditions, and

configurations
Installation

Implement disaster recover y and business continuity plans or

modifications
Modifications
 Establish architecture artifact, design, and code reviews and
define acceptance criteria for the successful implementation of

Review the findings

Implement methods and procedures to review evidence

produced by the system that reflects operational stability and
adherence to security policies
Evidence

Implement necessary training to ensure correct deployment,

configuration, and operations of security-relevant subsystems
and components; ensure awareness training of all users and
Training non-privileged operators of the system and/or its components
 Change is driven by new requirements. Changes in
security requirements are often more disruptive than
Requirements a simplification or incremental change.

Changes in security policy can be driven by statute,

regulation, or something that has gone wrong
Statutes and
Regulations

Changes in security standards are usually less

disruptive since the trade-off for their adoption is
based on the value of the change. However, standards
Standards changes can also be mandated
 TOGAF Version 9, The Open Group
Architecture Framework (TOGAF), 2009
If you have one last breath
use it to say...