Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

16

Partager

Enterprise Security Architecture Design

Enterprise Security Architecture was initially targeted to address two problems
1- System complexity
2- Inadequate business alignment
Resulting into More Cost, Less Value

Enterprise Security Architecture Design

  1. 1. Enterprise Security Architecture Arnab Chattopadhayay Vice President, Engineering Infoworks Inc.
  2. 2. Enterprise Architecture • A field born about 30 years ago • Initially targeted to address two problems – System complexity – Inadequate business alignment – Resulting into • More Cost, Less Value
  3. 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. 4. A Brief History of 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. 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. 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. 7. Zachman Framework (4) Source: zachmaninternational.com [Executive Mgmt Perspective] [Business Mgmt Perspective] [Architect’s Perspective] [Engineer’s Perspective] [Technician’s Perspective]
  8. 8. How Zachman Taxonomy can 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. 9. Five Ways Zachman Taxonomy 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. 10. What Zachman Taxonomy does 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. 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. 12. Well Known Cyber Security 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. 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. 14. Features and Advantages Feature Advantage 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. 15. How is SABSA Used • 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. 16. Sherwood Applied Business Security 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. 17. SABSA Model • Comprises of 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. 18. ©SABSA foundation, 2010 Logical Process Maps & 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. 19. SABSA Lifecycle Business View Contextual 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. 20. SABSA Mapping with other 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. 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. 22. Using SABSA Define Contextual Security Architecture Define Conceptual Security Architecture Define Logical Security Architecture Define Physical Security Architecture Define Component Security Architecture Define Operational Security Architecture
  23. 23. Approach of Discussing SABSA • 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. 24. BUSINESS CONTEXT AND REQUIREMENTS Framework
  25. 25. Scope: Strategy & Planning Phase - Assets
  26. 26. Scope: Strategy & Planning Phase - Assets Business Driver Development BAP with KPI’s and KRI’s
  27. 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. 28. Credible Abstraction is Key • 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. 29. Business Attributes • An Attribute 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. 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. 31. Two-way Traceability – Drivers to Attributes
  32. 32. Two-way Traceability – Attributes to Drivers
  33. 33. Sample of Business Drivers 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
  34. 34. BUSINESS CONTEXT AND REQUIREMENTS Implementation Approach
  35. 35. Business Attributes Business Attributes User Attributes Management Attributes Risk Management Attributes Legal/Regulatory Attributes Technical Strategy Attributes Operational Attributes Business Strategy Attributes Business Attribute Business 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
  36. 36. 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 Driver Business 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
  37. 37. ARCHITECTURAL STRATEGIES
  38. 38. Scope: Strategy & Planning Phase - Process
  39. 39. 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
  40. 40. Strategy & Planning Phase Alignment
  41. 41. Risk Management Method Alignment
  42. 42. Performance & Reporting Methods
  43. 43. Control Objectives Libraries & Standards
  44. 44. Controls Frameworks & Libraries
  45. 45. SABSA Multi-tiered Control Strategy
  46. 46. Application of Multi-tiered Controls 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
  47. 47. Application of SABSA Multi-tier Control
  48. 48. Application of Multi-tiered Control Strategy
  49. 49. PLANNING & PERFORMANCE MANAGEMENT CONCEPTS
  50. 50. Scope: Strategy & Planning Phase - Time
  51. 51. Architecture Strategy & Planning Phase
  52. 52. Architecture Design Phase
  53. 53. 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
  54. 54. Manage & Measure Phase – 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)
  55. 55. Manage & Measure Phase – SSM Matrix
  56. 56. SABSA Development Process
  57. 57. SABSA Risk Management Process Overview
  58. 58. Risk Management and the SABSA Matrix
  59. 59. SABSA Lifecycle Domain Risk Perspectives
  60. 60. 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
  61. 61. SABSA Maturity Profile Process 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
  62. 62. SMP Maturity Levels
  63. 63. SMP Generic Practices
  64. 64. Performance Management Framework Defining Business-driven Performance Targets
  65. 65. 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?
  66. 66. Measurement Approaches • High level statements of the approach to obtaining a measurement • Appropriate to the business need • In the language of the intended audience • Culturally specific
  67. 67. Measurement Guidelines • Measurement should 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.)
  68. 68. Metrics Guidelines • Data used 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
  69. 69. 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
  70. 70. 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
  71. 71. Conceptual Measures & Metrics Framework
  72. 72. SABSA Vitality Framework
  73. 73. Thank You
  • MattCelichowski

    Aug. 9, 2021
  • murugirachael

    Jun. 18, 2021
  • HaotianLiu11

    Jul. 24, 2020
  • StevenLin49

    Jul. 24, 2020
  • wweinmeyer79

    Mar. 3, 2020
  • TesfatsionGebreyohan

    Jan. 23, 2020
  • RobbieWalker2

    Nov. 20, 2019
  • shivanthan

    Apr. 16, 2019
  • GopalGupta33

    Jan. 4, 2019
  • DarrelLewis1

    Sep. 25, 2018
  • AladdinDandisCISM

    Jun. 26, 2018
  • greggjl

    May. 28, 2018
  • kiranpj1

    May. 20, 2018
  • pallahue

    Oct. 15, 2017
  • Ab1322

    Aug. 12, 2017
  • nandas_d

    Jun. 2, 2017

Enterprise Security Architecture was initially targeted to address two problems 1- System complexity 2- Inadequate business alignment Resulting into More Cost, Less Value

Vues

Nombre de vues

5 893

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

370

Actions

Téléchargements

1

Partages

0

Commentaires

0

Mentions J'aime

16

×