![Zachman Framework (4)
Source: zachmaninternational.com
[Executive Mgmt
Perspective]
[Business Mgmt
Perspective]
[Architect’s
Perspective]
[Engineer’s
Perspective]
[Technician’s
Perspective]](https://image.slidesharecdn.com/session1-enterprisesecurityarch-170522120530/75/Enterprise-Security-Architecture-Design-7-2048.jpg)
Uploaded byPriyanka Aash
Enterprise Security Architecture Design
The document outlines the evolution and frameworks of enterprise security architecture, highlighting the Zachman framework's taxonomy and its application in organizing architectural artifacts relative to various stakeholders. It also discusses the Sherwood Applied Business Security Architecture (SABSA), which integrates multiple frameworks and methodologies to enhance business-driven security architectures. Key aspects covered include the importance of stakeholder perspectives, approaches for improving enterprise architecture artifacts, and strategies for aligning security with business objectives.
More Related Content
Similar to Enterprise Security Architecture Design
Enterprise Security Architecture Design
- 1. Enterprise Security Architecture ArnabChattopadhayay Vice President, Engineering Infoworks Inc.
- 2. Enterprise Architecture • Afield born about 30 years ago • Initially targeted to address two problems – System complexity – Inadequate business alignment – Resulting into • More Cost, Less Value
- 3. Enterprise Architectural Methodologies •Consortia-developed Frameworks – ISO 19439 – RM-ODP (ITU-T X.901-904) – TOGAF • Defense Industry Framework – DoDAF – MODAF – NAF • Government Framework – ESAAF – FEAF – NIST Enterprise Architecture Model • Open Source Frameworks – TRAK – SABSA • Proprietary Frameworks • Zachman Frameworks • IAF (Capgemini, 1993)
- 4. A Brief Historyof Enterprise Architecture Zachman’s first article 1987 TAFIM released 1994 Clinger-Cohen bill passed 1996 1998 TAFIM retired FEAF 1.2 released 1999 2002 FEA replaces FEAF TOGAF EE 8.0 released 2003 2003 FEA mostly complete 2011 TOGAF 9.1
- 5. Zachman Framework (1) •The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both who the artifact targets (e.g. business owner and builder) and what particular issue (e.g. data and functionality) is being addressed • Two dimensions – Players in the game – Architectural Artifacts • Players in the game: Actors • Architectural Artifacts: the What, How, Where, When, Who and Why • The second dimension is independent of the first – Both the Builder and the Owner need to know the ‘What’ – But, they need to know different ‘What’ • From a Business Owner’s perspective, ‘Data’ means business entity – Example: Customer, Product, Demographic Groups, Inventory • From the developer’s perspective i.e. Builder’s perspective, ‘Data’ means rows and columns organized into table, mathematical joins to implement relationships
- 6. Zachman Framework (2) •Zachman Framework is typically depicted as a 6 x 6 matrix – Columns: Communication Interrogatives – Rows: Reification Transformation – The Framework Classification is represented by 36 cells – Each cell represents a player’s perspective (e.g. business owner) and a descriptive focus (e.g. data) • Moving horizontally changes description of the system from same player’s perspective • Moving vertically pin down to single focus but changes players
- 7. Zachman Framework (4) Source:zachmaninternational.com [Executive Mgmt Perspective] [Business Mgmt Perspective] [Architect’s Perspective] [Engineer’s Perspective] [Technician’s Perspective]
- 8. How Zachman Taxonomycan help building a system architecture • First: use Zachman Taxonomy to the fact that every architecture artifact must live in one and only one cell • Second: achieve architectural completeness by completing every cell • Third: cells in columns should be related to each other.
- 9. Five Ways ZachmanTaxonomy can help building enterprise architecture • Five ways Zachman Taxonomy can help: – Ensure that every stakeholder's perspective has been considered for every descriptive focal point – Improve the Enterprise Architecture artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience – Ensure that all of CxO’s business requirements can be traced down to some technical implementation – Convince Business function of the organization that the technical team isn't planning on building a bunch of useless functionality – Convince Technology team that the business folks are including IT teams in their planning
- 10. What Zachman Taxonomydoes not provide • Does not provide step-by-step process to create new architecture • Does not provide much help in validating an architecture • Does not provide help in deciding future architecture
- 11. Cyber Security Frameworks •A Cyber Security Framework is a risk-based compilation of guidelines designed to help organizations assess current capabilities and draft a prioritized roadmap toward improved cybersecurity practices Source: NIST
- 12. Well Known CyberSecurity Frameworks • ISO/IEC 27001 & 27002 (formerly ISO 17799) • NIST SP 800-53: Security and Privacy Controls for Federal Information Systems and Organizations • Sherwood Applied Business Security Architecture (SABSA) • NIST SP 800-39: Risk Management Framework • Security in Major IT Management Frameworks
- 13. What is SABSA •Methodology for: – Developing business-driven, risk and opportunity focused enterprise security & information assurance architectures – Delivering security infrastructure & service management solutions that traceably support critical business initiatives • Comprised of a number of integrated frameworks, models, methods and processes, including: – Business Requirements Engineering Framework (also known as Attributes Profiling) – Risk & Opportunity Management Framework – Policy Architecture Framework – Security Services-Oriented Architecture Framework – Governance Framework – Security Domain Framework – Through-life Security Service & Performance Management
- 14. Features and Advantages FeatureAdvantage Business Driven Value-assured Risk Focused Prioritized and proportional responses Comprehensive Scalable scope Modular Agility – ease of implementation and management Open Source (protected) Free use, open source global standard Auditable Demonstrate compliance Transparent Two-way traceability ©SABSA Foundation 2010
- 15. How is SABSAUsed • Information Assurance • Governance, Compliance & Audit • Policy Architecture • Security service management • IT Service management • Security performance management, measures & metrics • Service performance management, measures & metrics • Over-arching decision-making framework for end-to-end solutions • Enterprise Security Architecture • Enterprise Architecture • Individual solutions-based Architectures • Seamless security integration & alignment with other frameworks (including TOGAF, ITIL, ISO27000 series, Zachman, DoDAF, CobIT, NIST, etc.) • Filling the security architecture and security service management gaps in other frameworks • Business requirements engineering • Solutions traceability • Risk & Opportunity Management
- 16. Sherwood Applied BusinessSecurity Architecture (SABSA) Model SABSA Model The SABSA Model comprises six layers. It is based on the well-known Zachman framework1 for developing model for enterprise architecture, although it has been adapted somewhat to a security view of the world.
- 17. SABSA Model • Comprisesof six layers • Based on Zachman framework/taxonomy • The Security Service Management Architecture has been placed vertically across the other five layers – Security management issues arises in every horizontal layer • Each horizontal layers are made of a series of vertical communication interrogatives – What (Assets) – Why (Motivation) – How (Process and Technology) – Who (People) – Where (Location) – When (Time)
- 18. ©SABSA foundation, 2010 Logical ProcessMaps & Services Domain Maps Entity & Trust Framework Calendar & Timetable Physical ICT Infrastructure Human Interface Processing Schedule Component Locator Tools & Standards Personnel Management Tools & Standards Step Timing & Sequencing Tools Service Management Service Delivery Management Process Delivery Management Management of Environment Personnel Management Time & Performance Management Information Assets Data Assets ICT Components Process Mechanisms Process Tools & Standards Assets (What) Process (How) Location (Where) People (Who) Time (When) Contextual Business Decisions Business Processes Business Geography Business Governance Business Time Dependence Conceptual Business Knowledge & Risk Strategy Strategies for Process Assurance Domain Framework Roles & Responsibilities Time Management Framework Motivation (Why) Business Risk Risk Management Objectives Risk Management Policies Risk Management Practices Risk Management Tools & Standards Operational Risk Management SABSA Matrix
- 19. SABSA Lifecycle Business ViewContextual Architecture Architect’s View Conceptual Architecture Designer’s View Logical Architecture Builder’s View Physical Architecture Tradesman’s View Component Architecture Service Manager’s View Operational Architecture
- 20. SABSA Mapping withother Security Standards Applications Presentation Session Transport Network Link Physical Applications Presentation Session Transport Network Link Physical ISO 7498-1 ISO 7498-2 Logical Security Services Physical Security Mechanisms Contextual Architecture Conceptual Architecture Business Driven Requirements & Strategy SABSA Views Logical Architecture Physical Architecture Component Architecture Operational Architecture Service Management Detailed Custom Specification
- 21. Bringing All Together BusinessStrategy Goals Relatio nship Market Regula tion People Materi als Financ e Produc tion Logisti cs BAP Risk Model Trust Model SecurityStrategy Process Design Policy& Legal Framework Technical Design LogicalSecurityServices Confidentiality Identification Registration Certification Directories Authentication Authorization Access Control Audit Trail PhysicalSecurityMechanism Encryption Naming Procedures Signatures Databases Passwords ACLs Firewalls Event Logs Components TrustedBusinessOperations ProductsTools
- 22.
- 23. Approach of DiscussingSABSA • Business Context and Requirements • Policy Architecture • Architecture Strategies • Planning and Performance Management • Scope of current discussion – Business context and requirements – Architecture strategies – Planning and performance management • They would be discussed in terms of framework and implementation
- 24.
- 25. Scope: Strategy &Planning Phase - Assets
- 26. Scope: Strategy &Planning Phase - Assets Business Driver Development BAP with KPI’s and KRI’s
- 27. Business Driven Architecture •Being business-driven means never losing site of the organisation’s goals, objectives, success factors and targets, and ensuring that the security strategy demonstrably supports, enhances and protects them • The contextual architecture captures and presents the full set of relevant requirements for the scope of the assignment – Including conflicts in business strategy, risks & priorities – At this stage we are confirming that they are complete and we understand them – The conceptual layer will later resolve these conflicts by delivering an appropriate, measurable security strategy
- 28. Credible Abstraction isKey • Meaningful traceability is enabled by credible abstraction from business context (assets, goals & objectives) to a business security context • Traceability therefore starts by delivering two slightly different sets of requirements:
- 29. Business Attributes • AnAttribute is a conceptual abstraction of a real business requirement (the goals, objectives, drivers, targets, and assets confirmed as part of the business contextual architecture) • The Attributes Profiling technique enables any unique set of business requirements to be engineered as a standardized and re-usable set of specifications • The Attributes are modeled into a normalized language that articulates requirements and measures performance in a way that is instinctive to all stakeholders
- 30. Attributes Profiling Rules& Features • Attributes can be tangible or intangible • Each attribute requires a meaningful name and detailed definition customized specifically for a particular organization • Each attribute requires a measurement approach and metric to be defined during the SABSA Strategy & Planning phase to set performance targets for security • Attributes must be validated (and preferably created) by senior management & the business stake-holders by report, interview or facilitated workshop • The performance targets are then used as the basis for reporting and/or SLAs in the SABSA Manage & Measure phase • Powerful requirements engineering technique • Populates the vital ‘missing link’ between business requirements and technology / process design
- 31. Two-way Traceability –Drivers to Attributes
- 32. Two-way Traceability –Attributes to Drivers
- 33. Sample of BusinessDrivers Driver # Business Drivers BD1 Protecting the reputation of the Organization, ensuring that it is perceived as competent in its sector BD2 Providing support to the claims made by the Organization about its competence to carry out its intended functions BD3 Protecting the trust that exists in business relationships and propagating that trust across remote electronic business communications links and distributed information systems BD4 Maintaining the confidence of other key parties in their relationships with the Organization BD5 Maintaining the operational capability of the Organization’s systems BD6 Maintaining the continuity of service delivery, including the ability to meet the requirements of service level agreements where these exist BD7 Maintaining the accuracy of information BD8 Maintaining the ability to govern
- 35.
- 36. Business Attributes Business Attributes User Attributes Management Attributes Risk Management Attributes Legal/Regulatory Attributes Technical Strategy Attributes Operational Attributes Business Strategy Attributes Business AttributeBusiness Attribute Definition Suggested Measurement Approach Metric Type User Attributes Accessible Information to which the user is entitled to gain access should be easily found and accessed by that user. Search tree depth necessary to find the information Soft Accurate The information provided to users should be accurate within a range that has been preagreed upon as being applicable to the service being delivered. Acceptance testing on key data to demonstrate compliance with design rules Hard Anonymous For certain specialized types of service, the anonymity of the user should be protected. Rigorous proof of system functionality Red team review Hard Soft Consistent The way in which log-in, navigation, and target services are presented to the user should be consistent across different times, locations, and channels of access. Conformance with design style guides Red team review Soft Current Information provided to users should be current and kept up to date, within a range that has been pre- agreed upon as being applicable for the service being delivered. Refresh rates at the data source and replication of source and replication of refreshed data to the destination. Hard
- 37. Attribute Profile Business Attributes User Attributes Management Attributes Risk Management Attributes Legal/Regulatory Attributes Technical Strategy Attributes Operational Attributes Business Strategy Attributes Business Attribute Business DriverBusiness Attribute Definition Measurement Approach Metric Performance Target User Attributes Accessible 5 Information to which the user is entitled to gain access should be easily found and accessed by that user. Search tree depth necessary to find the information Soft Accurate 7 The information provided to users should be accurate within a range that has been preagreed upon as being applicable to the service being delivered. Acceptance testing on key data to demonstrate compliance with design rules Hard Anonymous 4 For certain specialized types of service, the anonymity of the user should be protected. Rigorous proof of system functionality Red team review Hard Soft Consistent 23, 41 The way in which log-in, navigation, and target services are presented to the user should be consistent across different times, locations, and channels of access. Conformance with design style guides Red team review Soft Current 7 Information provided to users should be current and kept up to date, within a range that has been preagreed upon as being applicable for the service being delivered. Refresh rates at the data source and replication of source and replication of refreshed data to the destination. Hard
- 38.
- 39. Scope: Strategy &Planning Phase - Process
- 40. Alignment, Integration &Compliance Strategy • Understand what needs to be aligned, to what purpose, and where it is positioned within the SABSA framework • Business model or business process framework • Legislation, regulation or governance frameworks • Risk management methods, assurance framework or audit approach • IT Architecture framework or method • Controls framework, library or standard • Performance management & reporting framework
- 41. Strategy & PlanningPhase Alignment
- 42. Risk Management MethodAlignment
- 43. Performance & ReportingMethods
- 44. Control Objectives Libraries& Standards
- 45. Controls Frameworks &Libraries
- 46. SABSA Multi-tiered ControlStrategy
- 47. Application of Multi-tieredControls In Risk • The multi-tiered controls strategy is modeled against the risk assessment to determine proportional and appropriate response • Contributes to selection of the right control in the right place at the right time • Enables further removal of subjectivity in selection of Risk Treatments • Facilitates construction of databases and risk management tools that respond to definitive risk scenarios with definitive control decisions • Increases speed and ease of use of Risk Assessment
- 48. Application of SABSAMulti-tier Control
- 49. Application of Multi-tieredControl Strategy
- 50.
- 51. Scope: Strategy &Planning Phase - Time
- 52. Architecture Strategy &Planning Phase
- 53.
- 54. Implementation Phase &Approach • Implementation is an important part of the lifecycle but the SABSA Matrix does not define a specific implementation layer – No need to re-invent Prince2 or PMI etc. • Notoriously difficult to gain business support and budget for pure infrastructure projects • Rare that a major strategic enterprise-wide security architecture is implemented as a single project • More likely (and more sensible) is that the architecture provides a blue-print and a road-map that guides a whole series of separate implementation projects, each of which is driven by a specific business initiative and funded by a budget associated with that initiative
- 55. Manage & MeasurePhase – Lifecycle Overlay • SABSA Architecture traceably abstracts from pure Business Context to: – Pure technical deployment in the Component layer – Pure management in the Service Management layer • The Service Management layer defines all aspects of security management and constructs the means to manage and incorporate change by being presented vertically across the other layers: – Strategy (Context & Concept Layers) – Tactics (Logical, Physical, & Component Layers) – Operations (Security Service Management Matrix)
- 56. Manage & MeasurePhase – SSM Matrix
- 57.
- 58. SABSA Risk ManagementProcess Overview
- 59. Risk Management andthe SABSA Matrix
- 60. SABSA Lifecycle DomainRisk Perspectives
- 61. Process Improvement Framework– SABSA Maturity Profile (SMP) • Coordinates SABSA process information from all parts of the business – Demonstrates due diligence to senior management, auditors and regulators • Based on Capability Maturity Modeling (CMM) concepts – Qualitative measurement technique for maturity of processes – Six domains mapped onto the SABSA Matrix – Consistent, objective 5-point maturity scale • Identifies, measures and reports compliance practices – Against the SABSA framework, model and processes – Provides a gap analysis to drive a SABSA improvement programme • Can be implemented through a web-enabled tool for – Ease of use, wide involvement, quick responses • Regular use tracks progress and measures changes – Benchmarking against target maturity
- 62. SABSA Maturity ProfileProcess Areas SMP Process Areas and SMP Process Activities • Each of the six SMP domains is decomposed into six SMP Process Areas • These SMP Process Areas map onto the six cells of the row of the SABSA • Matrix corresponding to the particular SMP domain • The SMP Process Activities are then derived by overlaying the SABSA • Service Management Matrix onto the SMP Process Areas
- 63.
- 64.
- 65. Performance Management Framework DefiningBusiness-driven Performance Targets
- 66. Architecture Measurement Categories •Completeness – Do we have all of the components? – Do they form an integrated system? • Assurance – Does the system run smoothly? – Are we assured that it is properly assembled? – Is the system fit-for-purpose? • Compliance – Do we maintain the system? – Do we follow the architecture roadmap – Do we comply with the rules? • Performance – Is the system properly tuned? – Do the components work together? – Do we operate the system correctly? • Justification & significance – Does the system have business value?
- 67. Measurement Approaches • Highlevel statements of the approach to obtaining a measurement • Appropriate to the business need • In the language of the intended audience • Culturally specific
- 68. Measurement Guidelines • Measurementshould be a repeatable process (for comparison & prediction) • Measurement should have a clear communications role • Tracking performance • Assigning resources • Measurement should yield quantifiable metrics (percentage, average, numbers, values, etc.)
- 69. Metrics Guidelines • Dataused to calculate metrics should be readily obtainable • Metrics may (should) be calculated independently of parties with vested interest • The type of metric used may change in line with the maturity of the security process e.g. when you are highly compliant, consider changing from conformance measure to significance measure • Performance metric / trend should be tested prior to going ‘live’ • Expectations management is key
- 70. Types of Metric •Soft Metrics – Usually qualitative – Subjective – Open to interpretation and opinion (usually of the authority setting the target or of an official compliance agent such as a regulator or auditor) • Hard Metrics – Usually quantitative – Objective – Fixed, not open to opinion or interpretation
- 71. Types of Metric •Descriptive – Describes the current-state of the object / attribute being measured • Comparative – Describes the current-state of the object / attribute being measured in comparison with a similar object / attribute relating to a different place and/or time • Predictive – Describes the current-state of the object / attribute being measured in relation to its trend in order to project and predict afuture state
- 72. Conceptual Measures &Metrics Framework
- 73.
- 74.
Editor's Notes
- #5 Essentially started in 1987 with the publication of in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman where he laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years U.S. DoD Technical Architecture Framework for Information Management (TAFIM) and was introduced in 1994 which had influenced creation of Clinger-Cohen Act of 1996 which was aimed at improving effectiveness of Govt. IT investments Federal Enterprise Architecture Framework version 1.1 was released in 1999 FEAF renamed to FEA in 2002 TAFIM was retired in 1998 and the work done was turned over to The Open Group who morphed into what is today knows as TOGAF (The Open Group Architecture Framework)