TOGAF 9 - Security Architecture - pdf format

1. Summarised - 2010

2.  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.

3. Authentication
Risk
Authorisation
Management
Administration Audit
Asset Protection Assurance
Availability

4. 1. Business Rules
5. Data
Classification 2. Security Policy
Policy
Artefacts
3.
4. Risk Analysis Data/Information
Ownership

6. 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

8. •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

9. 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

11. •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

12. Business
Continuity
Security Disaster
Plans
Policies Recovery
Plans
Applicable
Jurisdictions
INPUT

13. 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

15. • 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?’’

16. • 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

17. Business and
regulatory security
Applicable disaster
environment
recovery and
statements
business continuity
plans
applicable security
policies and regulations
Input

18. 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)

20. •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

21. • 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

22. Forensic Business
Risk Analysis Processes Policies and
Threat Analysis
Guidelines
Matrix
DR and BCM
Interconnecting
Requirements Systems
Security Input

23. 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

25. •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

26. Applicable Security
Standards and
Security-related Actors and Risk
elements and Management
interconnected Strategy
systems
Validated Security
Policies, Regulatory and
Trust Requirements
Security Input

27. 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

29. •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.

31. •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

33. •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

35. • 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

36.  TOGAF Version 9, The Open Group
Architecture Framework (TOGAF), 2009

37. If you have one last breath
use it to say...