TOGAF 9 - Security Architecture Ver1 0


Published on

TOGAF 9 - Security Architecture - pdf format

TOGAF 9 - Security Architecture Ver1 0

  1. 1. Summarised - 2010
  2. 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. 3. Authentication Risk Authorisation Management Administration Audit Asset Protection Assurance Availability
  4. 4. 1. Business Rules 5. Data Classification 2. Security Policy Policy Artefacts 3. 4. Risk Analysis Data/Information Ownership
  5. 5. 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
  6. 6. •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
  7. 7. 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
  8. 8. •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
  9. 9. Business Continuity Security Disaster Plans Policies Recovery Plans Applicable Jurisdictions INPUT
  10. 10. 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
  11. 11. • 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?’’
  12. 12. • 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
  13. 13. Business and regulatory security Applicable disaster environment recovery and statements business continuity plans applicable security policies and regulations Input
  14. 14. 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)
  15. 15. •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
  16. 16. • 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
  17. 17. Forensic Business Risk Analysis Processes Policies and Threat Analysis Guidelines Matrix DR and BCM Interconnecting Requirements Systems Security Input
  18. 18. 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
  19. 19. •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
  20. 20. Applicable Security Standards and Security-related Actors and Risk elements and Management interconnected Strategy systems Validated Security Policies, Regulatory and Trust Requirements Security Input
  21. 21. 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
  22. 22. •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.
  23. 23. •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
  24. 24. •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
  25. 25. • 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
  26. 26.  TOGAF Version 9, The Open Group Architecture Framework (TOGAF), 2009
  27. 27. If you have one last breath use it to say...