SABSA Foundation F2 - Security Management & Design PDF

DLCAMSF230904 SABSA Foundation SABSA Chartered Architect Foundation Level (SCF) v2.4.3  DLCAMSF230904 F2 – Security Management & Design  DLCAMSF230904 Module F2 – Course Outline Sec...

DLCAMSF230904 SABSA Foundation SABSA Chartered Architect Foundation Level (SCF) v2.4.3  DLCAMSF230904 F2 – Security Management & Design  DLCAMSF230904 Module F2 – Course Outline Section 12 – Asset Architecture & Management Section 13 – Risk & Policy Management Architecture tÉ Section 14 – Transformation & Service Architecture Section 15 – Entity & Trust Framework Section 16 – Inter-domain Security Associations Section 17 – Service Sequencing & Performance © The SABSA Institute C.I.C 2021 3  DLCAMSF230904 F2 Question Domains / Materials Cross-reference 1. What (assets) – F2 sections 12 8É 2. Why (risk & motivation factors) – F2 sections 13 3. How (process factors) – F2 section 14 4. Who (people factors) – F2 section 15 5. Where (location factors) – F2 section 16 6. When (temporal factors) – F2 section 17 © The SABSA Institute C.I.C 2021 4  DLCAMSF230904 Asset Architecture & Asset Management Section 12 © The SABSA Institute C.I.C 2021 5  DLCAMSF230904 Scope: Design Phase - Assets Architecture Management Matrix Matrix É E Information Assets Logical Asset Management O Logical Inventory of Information Assets Knowledge Management; Information Model of the Business Release & Deployment Management a Data Assets Physical Asset Management Physical Data Dictionary & Change Management; Platform & Data Storage Devices Inventory Data Storage Management É E Component Assets Component Management Component Products and Tools, Product & Component including Data Repositories Standards Management and Processors © The SABSA Institute C.I.C 2021 Mi I o 6  DLCAMSF230904 Section 12 Competency Objectives Competency / Question Domain 1 – What (Assets) Knowledge Element Knowledge Competency Comprehension Competency The SABSA Matrix Describe the characteristics & deliverables of Explain the constructs & characteristics of, the SABSA Architecture Design Phase layers and distinguish between assets at logical, É physical & component layers Describe the principles of aligning & Summarise approaches to aligning & integrating SABSA’s lower layers with other Integrating architectural frameworks & E established frameworks & standards standards Service Management Identify the role of SABSA techniques for Explain Release & Knowledge Management security in Release & Knowledge in terms of SABSA assets & attributes Management Start-up Approaches List and define possible start-up approaches Differentiate between start-up approaches & to SABSA Enterprise Security Architecture interpret the benefits and challenges of each to recommend appropriate approaches for organisational circumstances © The SABSA Institute C.I.C 2021 7  DLCAMSF230904 Constructs & Characteristics of Assets E Data Asset Information É É Assets Transformation Assets Raw facts, figures & events Set of people, processes, Transformed data (quantitative) services & resources that (qualitative) collects & transforms data Collected by observation & into information and Created by analysis and structured presentation of É recording disseminates & presents this É information data Stored in a specific location (physical) The “information system” or ÉÉ – not stored Virtual (logical) “ICT system” in a specific location No context (little meaning until organised, arranged & Context (has meaning developed) through organisation & presentation) 9 © The SABSA Institute C.I.C 2021 8  DLCAMSF230904 I Asset Value in SABSA The purpose of information is to contribute to business knowledge for decision-making _É E Information value is achieved if it has certain properties such as: Accuracy & Completeness Timeliness & Availability Relevance Similar properties are required for the data assets to be transformed to create the information, É and the management assets of the information systems that perform the transformations SABSA traceably derives these properties from the Conceptual Attributes Attributes performance targets also provide added-value by ensuring the quantity of assets (and the quantity of asset properties) is fit-for-purpose © The SABSA Institute C.I.C 2021 9  DLCAMSF230904 Relationship With Conceptual Assets Business Drivers for Business Security Requirements Attributes in Conceptual Layer Accurate CompleteÉÉ Timely Available Etc. Logical Domain A Logical Domain B Information Information Information Information Accuracy Availability Etc. Accuracy Availability Etc. Physical Domain X Physical Domain Y Data Data Data Data Accuracy Availability Etc. Accuracy Availability Etc. © The SABSA Institute C.I.C 2021 10  DLCAMSF230904 Overview of the Design Phase Logical Layer Logical Architecture e Logical Architecture is the Designer’s View of ICT Systems Concerned with information security & systems functionality Elements exist in logical domains 8585ft not tied to specific physical locations Risk Information Process Maps Trust Calendar & Management Domain Maps Assets & Services Relationships Timetable Policies By deploying security In a given time frame, Secures information services (functional sequence & performance É assets, information flows specifications) in & between level, according to defined & trust relationships logical domains domain policies © The SABSA Institute C.I.C 2021 11  DLCAMSF230904 Overview of the Design Phase Physical Layer Physical Architecture Physical Architecture is the Builder’s View of ICT Systems Concerned with data security stEE & infrastructure security Technical specifications for systems Elements exist in a specific physical domain and location Risk 0 00000 Data Process Human Processing Management Infrastructure Assets Mechanisms Interface Schedule Practices Secures data and By deploying security In a given time frame, technology mechanisms (technical sequence & performance EI E I infrastructure, its specifications) in & between level, according to defined processes & its interface physical domains procedures with people © The SABSA Institute C.I.C 2021 12  DLCAMSF230904 Overview of the Design Phase Component Layer Component Architecture Components are the Tradesman’s View of ICT Systems Specialised to Tools Brands Specific granular technical specifications & standards Protocols a Risk Step Timing EEE Process Human Entities: Locator EEE Component Management & Sequencing t Components Components & Components & Assets Components & Components & Standards Standards Standards Standards and Standards © The SABSA Institute C.I.C 2021 13  DLCAMSF230904 Overview of the Design Phase Management Layers Management Architecture (Overlaid) te Management Architecture is the Manager’s View of ICT Systems Concerned with management processes & activities Governance, Delivery & Operational Process Time & D Relationship & Environment E Continuity Management Risk u Management Delivery Management Personnel Management Management Performance Management Logical Physical Component Security Security Security Architecture Architecture Architecture I Processes & activities to Processes & activities to Processes & activities to Ee manage information security manage data security, manage security tools, brands, & security functionality & security infrastructure protocols & standards © The SABSA Institute C.I.C 2021 14  DLCAMSF230904 Architectural Asset Alignment It In section 3 of Module F1 we discussed the fact that security does not exist in isolation – it is a property of something else (assets) É It is not possible to define the security architecture of logical, physical & component level assets until the assets themselves have been defined EÉ The assets are defined, organised and architected in a number of different ways according to other architectural frameworks, approaches and standards In the same section we discussed a guiding principle that a good architecture framework must have compatibility to__oo Therefore the security architect must be capable of demonstrating compatibility and alignment with the frameworks used by other architects © The SABSA Institute C.I.C 2021 15  DLCAMSF230904 0 Build on Existing Strengths 7 Organisations may have already invested heavily in architectural frameworks I I No-one wants to reverse or waste that investment But frameworks leave gaps for security SABSA fills those gaps by being compatible and aligned EERIE It doesn’t replace other frameworks It builds on their strengths by adding security in a fully aligned way © The SABSA Institute C.I.C 2021 16  DLCAMSF230904 Align & Enhance, Don’t Replace SABSA Business Architecture Security Architecture Security Contextual Business Security Architecture Conceptual Systems Architecture Logical Systems Security Architecture Security Physical Component Management Architecture Management Security Management Architecture Security © The SABSA Institute C.I.C 2021 17  DLCAMSF230904 TOGAF, SABSA and General Architecture SABSA View SABSA Architecture SABSA Lifecycle TOGAF Architecture General (Enterprise) Layer Layer Architecture Business Contextual Strategy and Architecture Enterprise Planning I Vision/Business Architect Conceptual Strategy and Business Enterprise / Service Planning Designer Logical Design Information Systems Service / Solution Design Builder Physical Design Information Systems Solution Build / Technology Tradesman Component Design Technology Solution Components © The SABSA Institute C.I.C 2021 18  DLCAMSF230904 Zachman Architecture Alignment Tea D I I © The SABSA Institute C.I.C 2021 19  DLCAMSF230904 ITIL V3 Service Lifecycle F not me Published mid 2007 8 Changes the V2 principles of scope Moves to a focus on “service lifecycle” Positions the lifecycle within a feedback loop of continual improvement I © The SABSA Institute C.I.C 2021 20  DLCAMSF230904 ITIL V3 Service Lifecycle Business / Customer Requirements Service Strategy Strong conceptual view of strategic IT choices Service Design Refined model for service delivery and value creation Is Service Catalogue Service Portfolio Service Transition Effective execution of design and transition of change Service Operation Practices to run effective IT service operations Continual Service Sound basis to engage business for improvements Improvement © The SABSA Institute C.I.C 2021 21  DLCAMSF230904 SABSA and the ITIL Service Lifecycle Define Define Service Strategy & Contextual Conceptual I Strategy Planning Security Security Architecture Architecture Define Define Define II Logical Physical Component Design Security Security Security Service Architecture Architecture Architecture Design Service É Transition Implement © The SABSA Institute C.I.C 2021 22  DLCAMSF230904 SABSA and the ITIL Service Lifecycle Define Service Manage & Security Operation Measure Management Architecture Strategy & Planning Continual Service Manage & Design Measure Improvement 080 Implement © The SABSA Institute C.I.C 2021 23  DLCAMSF230904 a Release & Deployment Management In the Service Management field, assets (information, data, and all of the elements of the Into ICT system) are called Configuration Items (CI) and stored in a Configuration Management Database (CMDB) Objective of Release & Deployment Management is to build, test and deliver the Et __ capabilities and resources to provide the required services A Release is set of new or changed CIs that will be released into production together © The SABSA Institute C.I.C 2021 24  DLCAMSF230904 SABSA Lifecycle Domain Risk Perspectives t m Enterprise Level Strategic Business Attributes Profile Business Attributes are Performance against inherited from higher Business Attribute Change Programme Business targets is reported levels to lower levels Attributes Profile i ÉEÉFEe through scorecards at every level a Project Business Attributes Profile E Business Attributes can also feed upwards to contribute to the higher E level profiles 3 Operational Processes and Systems Business Attributes Profile © The SABSA Institute C.I.C 2021 25  DLCAMSF230904 SABSA in Release & Deployment 8 585to: A project (or any change) exists Improve current capabilities or performance Introduce new capabilities 8 Asset Information (stored in CMDB) Logical Asset Domains E Asset A increase Attribute A Asset B increase Attribute A Change in security performance target of New Asset X Attribute A Project or existing assets (CIs) Change Physical Asset Domains Attributes Introduce new Asset C increase Attribute A security capability & assets (CIs) Asset C New Attribute X New Asset X Attribute Y © The SABSA Institute C.I.C 2021 26  DLCAMSF230904 Knowledge Management VL Traublity Knowledge Management improves the quality of decision making by ensuring that reliable information is available during the service lifecycle Knowledge is aggregated and contextualised through the SABSA Architecture layers The layer-mapping technique discussed in module F1 is the mechanism for delivering knowledge for: Asset risk status ELII Asset risk & enablement performance Re-usability of assets to meet control & enablement objectives Completeness, justification & assurance Managing change © The SABSA Institute C.I.C 2021 27  DLCAMSF230904 Knowledge Management Layer-Map t Contextual Layer Business Wisdom Conceptual Layer EST Business Knowledge Management Layer Q Logical Layer Knowledge Business Information Management Physical & Component Layers Business Data © The SABSA Institute C.I.C 2021 28  DLCAMSF230904 Implementation 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. Rare that a major strategic éÉE 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 © The SABSA Institute C.I.C 2021 29  DLCAMSF230904 0 Start-up Approaches Executive Interview Approach Requires access to stake holders Ég Analysis followed by validation No access to stake holders Team research & assumptions Review, consensus & sign-off of strategy 4 Yed SABSA Fast-Track ÉEE Full scope experience & proof of concept Limited financial liability & commitment Requires access to full team & stake holders Blended Approach Complex or distributed organisations often require a combination of the other three approaches © The SABSA Institute C.I.C 2021 30  DLCAMSF230904 Fast-Track Start-up Concept Based on intensive facilitated workshops Heavily customised to the specific needs of the client organisation Starting position & architectural maturity Key programmes & risk priorities ÉEEEe Key players experience every aspect of the programme in a short time Workshops often run in parallel syndicate groups to ensure scope is covered Some types of people such as senior managers attend only a restricted sub-set of the workshops Post-workshop report toooo Key objectives: straw-man models, realistic programme plan, proof-of-concept Scope: unlike other approaches covers full-scope of SABSA © The SABSA Institute C.I.C 2021 31  DLCAMSF230904 Fast-Track Work Programme - Advance Gain an initial understanding of the organisation, its goals and objectives, through research and an analysis of documents supplied in advance by the Fast-Track host Gain an initial understanding, through an analysis of documents supplied in advance, of the current security and technology environment or the position of any architecture program that has already commenced Gain an initial understanding of the roles of all of the proposed Fast-Track participants and their objectives Draft, prioritise and agree the specific Fast-Track objectives and deliverables Draft, structure and agree the five-day program and its detailed contents Compile and customise all presentations for delivery Design and produce appropriate detailed workshops © The SABSA Institute C.I.C 2021 32  DLCAMSF230904 Fast-Track Work Programme - Workshops x Customisation of planned presentations to meet new objectives Development of new or replacement presentations to be introduced into the program Customisation of participant workshops to meet new or refined objectives Development of new or replacement participant workshops to be introduced into the program End of day status meetings to review progress against objectives and to plan mechanisms that must be introduced to meet altered priorities or objectives Review workshop output and document key architecture components © The SABSA Institute C.I.C 2021 33  DLCAMSF230904 Fast-Track Work Programme – Post Workshop Documented summary of the business case for Security Architecture development activities x Documented summary of a plan to collect and verify the full set of security business requirements Documented summary of the outline presentations and draft reports developed during the on-site program, and advice on progressing these to definitive and detailed architecture plans Summary of existing Architecture layers and a high-level gap analysis against stated strategic architectural requirements Advice on a means to integrate the Security Architecture with any existing or in-progress developments of business or technology architecture High-level implementation and migration strategy Summary of Key Performance Indicators (KPI) for Security Documented draft project plan to communicate key tasks, milestones, and future deliverables, together with any key dependencies revealed from an analysis of the on-site program Documented draft project plan summary illustrating what is needed to complete the Security Architecture, when it is needed, and what resources are required © The SABSA Institute C.I.C 2021 34  DLCAMSF230904 e Interview Approach – Who to Interview Hierarchical Structure May be many Executives & Senior Managers Some have multiple responsibilities Some have many staff - some not Too many decision ÉEmakers to interview? Process Structure Identify key processes Few, clearly identified ‘Chiefs’ Best positioned to answer © The SABSA Institute C.I.C 2021 35  DLCAMSF230904 Executive Interview Risks & Opportunities 00 Risks Opportunities Tired of being interviewed by IT High Level Buy-in, Endorsement & Support Limited Access Time & Availability Direct Stakeholder Validation Language Barrier EÉ Positive Project Exposure & Momentum Failure to Attain Buy-in and Support Establish Departmental EE ‘Champions’ Raised Expectations Building Bridges to the Business Managers Conflicting Priorities “The Value of the Process Itself Is More Project Exposure Important Than the Value of the Results” One-chance Opportunity © The SABSA Institute C.I.C 2021 36  DLCAMSF230904 Interview Criteria & Aims e Criteria: Ensure Requirements Come From Key Business Decision Makers Ensure Requirements Are Current & Future Validate Our Understanding Aim To Understand: ÉEET Culture and Business Environment Business Risks, Opportunities, Strategies Constraints & Motivators Business Relationships & Priorities Attitudes & Awareness Levels © The SABSA Institute C.I.C 2021 37  DLCAMSF230904 tFE Gaining Consensus Build and maintain strong relationships with the key players Facilitated consensus sessions or direct meetings ÉET Find out what makes them tick Do they have any concerns? Are they pre-disposed for or against any particular approaches? What will you need to do to get their agreement to the conceptual security architecture? What level of influence do they expect to have? What type of involvement in the process do they expect? Who are their key allies / opponents? What specific ‘buttons’ do they have that you will need to ‘push’? Foresee difficulties & manage expectations EEE Pre-sell the ideas Politics & diplomacy © The SABSA Institute C.I.C 2021 38  DLCAMSF230904 Appendices F2-1 & F2-2 Template yafteridem Sample interview scripts I Start-up Validation concern your Recap capture © The SABSA Institute C.I.C 2021 39  DLCAMSF230904 Sample Questions Competency Domain 1 Working as individuals, answer the following two questions. Time limit is 2 minutes 30 seconds. As a group we will then discuss the questions. © The SABSA Institute C.I.C 2021 40  DLCAMSF230904 Competency Domain 1 Is Which ONE of the following statements about the Fast-Track facilitated workshop approach to SABSA start-up is TRUE? e A. Fast-Track creates deliverables for only one SABSA Architecture Layer B. Fast-Track facilitated workshops are dependent upon week-long access to Executive Management C. Fast-Track requires long-term investment of finances and resources in order to deliver ‘proof of concept’ for the SABSA method D. Fast-Track provides key participants in the architecture project with the opportunity to experience the full scope of SABSA in a short time frame © The SABSA Institute C.I.C 41  DLCAMSF230904 Competency Domain 1 A diagram that shows the location in a distributed computing environment of ICT infrastructure is described as which ONE of the following? It A. Component Architecture B. Physical Architecture C. Logical Architecture D. Conceptual Architecture © The SABSA Institute C.I.C 42  DLCAMSF230904 alf Risk & Policy É Management Architecture Section 13 Risk Treatment © The SABSA Institute C.I.C 2021 43  DLCAMSF230904 Scope: Design Phase - Motivation Architecture Management Matrix Matrix Risk Management Policies Policy Management 5 Logical Risk Models; Domain Policies; Assurance Criteria Risk Modelling; Management of Policy Development & Maintenance. (populated Assurance Framework). Policy Publication & Compliance Management Risk Management Practices Risk Data Management Physical Risk Management Risk Procedure Management; Rules & Procedures; Risk Metadata Risk Metadata Management Risk Management Components & Standards Risk Management Components Component Risk Analysis Tools; Risk Analysis, Monitoring & Risk Registers; Risk Monitoring Reporting Components, & Reporting Tools Systems and Standards Management © The SABSA Institute C.I.C 2021 44  DLCAMSF230904 Section 13 Competency Objectives Competency / Question Domain 2 – Why (Motivation) Knowledge Element Knowledge Competency Comprehension Competency Risk & Policy Management Architecture List the requirements for architected Explain the association of architected controls controls To SABSA Contextual & Conceptual layers Identify the role in controls architecture Summarise the possible applications of of Pure Risk, Appetite Thresholds, Pure Risk, Appetite Thresholds, Actuarial Actuarial Data, & Dynamic Thresholds Data & Dynamic Thresholds List & label Risk Levels, Policy Levels, ÉÉto SABSA Architecture Associate & relate Control Levels & Management Layers Risk, Policy & Control Levels and Activities in Risk & Policy Management Management Activities SABSA Assurance Framework Describe the structure & objectives of Explain the application of the SABSA Fffectivness the SABSA Assurance Framework Assurance Framework & its relationship with Risk Level of dogfights © The SABSA Institute C.I.C 2021 45 i 1 1 Je Y Iii  DLCAMSF230904 oh Relationship With Conceptual Risk & Policy 000 Business risks & opportunities exist traceably through every layer of the architecture Responsibility for managing enterprise risks & opportunities is delegated to Domains Each Domain Policy Authority: Operates within the risk appetite parameters of the super domain Is compliant with the ÉE ÉEIsuper domain policy Has vested interest in risk performance within their own domain Deploys specific controls & enablers to manage risk according to the architecture layer at which their domain exists e.g. network risk is managed by network controls & enablers deployed in the network domain according to the network security policy © The SABSA Institute C.I.C 2021 46  DLCAMSF230904 Complexity of Control Considerations ÉE Legislation Sectoral regulation Sectoral standards Quality management Management style Corporate culture Risk management ÉE Technical standards IT & Architecture frameworks Development lifecycles Management frameworks © The SABSA Institute C.I.C 2021 47  DLCAMSF230904 Standards Are Not Enough Pee Most suggest what may be managed but few advise how Some contain control objectives, controls libraries or both Almost every organisation needs to adapt them to their specific business sector, culture, terminology, and national legislative andÉEESE regulatory requirements To succeed we need an overarching framework and methodology that ties it all together to design, deliver, and support end-to-end secure processes © The SABSA Institute C.I.C 2021 48  DLCAMSF230904 Requirement for Controls Architecture Few controls standards are written from the Architect’s holistic and structured point of view Example: ISO 27001 / ISO 27002 – 11.4 Network Access Control TEÉE Policy is at logical layer but requires physical procedures, component configuration 11.4.1 Users shall only be provided with standards & operating instructions at the Policy on use of access to the services that they have management layer. Implies an Network Services been specifically authorised to use authorisation service, mechanisms components & activities Implies an authentication service, 11.4.2 Mechanisms components & activities on at Appropriate authentication methods User authentication least three different domain levels (external shall be used to control access by for external users & networks, & internal networks) plus remote users connections a means of associating the domains together. Doesn’t cover internal users 11.4.3 Automatic equipment identification Implies physical identification mechanisms & Equipment shall be considered as a means to components, the means to verify the identities, identification authenticate connections from & management activities at each layer on networks specific locations & equipment © The SABSA Institute C.I.C 2021 49  DLCAMSF230904 Risk & Policy Management Architecture Etta Management Risk Level Policy Level Control Level Activity Controls Business Risks Appetite & strategy Management of & Opportunities to articulated in Security Services Security Services Logical Domains Logical Policy É Risks & Opportunities Managed by Management of to Physical Physical Procedures Security Mechanisms Infrastructure & Environment & derived from Policy Environment Infrastructure Domains Risks & Opportunities Managed by Management of to System E E Standards for Security Components Components, Products & Components Tools & Products Standards & Configurations © The SABSA Institute C.I.C 2021 50  DLCAMSF230904 Architectural Control Distribution Case Study FIFE Business Context: Interactions between Government Departments Business Drivers for Security: Information confidentiality in storage & in transit Information integrity in storage & in transit Integrity- Business Attributes: Confidential Identified Authenticated Assured EEEI.EE Architecture Controls & Enablers Management Controls & Enablers Logical Services: credentials issuance, session Logical Activities: Registration process, authorisation authentication, message origin authentication, process, credentials management, certificate policy message integrity, message content confidentiality, statement definition non-repudiation, replay protection, stored data integrity protection, stored data confidentiality Physical Activities: certification practice statement Physical Mechanisms: SSL, VPNs, disk EE EE definition, token management, provisioning, encryption, file hashing, message hashing, platform management, environment management, HSMs, crypto servers, smartcards network management Components: x.509 certificates, Component Activities: user credential management, algorithms (AES, SHA-1, etc) & keys certificate management, key management © The SABSA Institute C.I.C 2021 51  DLCAMSF230904 ORM Architecture Inheritance & Re-use SABSA Risk Assessment #1 / Pilot / Establishment Project Attributes _e Establishes first enterprise attributes, control & enablement objectives and risk register for those attributes with performance targets & risk appetite thresholds Creates first traceable layer-map from business requirements to Threat Vulnerability Fte - Impact controls (services, mechanisms, Risk Assessment components & management Ratings Opportunity Strength + Impact activities) Integrated Controls & Enablers Library – MTCS Modelled This layer-map becomes the Service 1 Service 2 Service 3 current-state SABSA E Enterprise Security E Mechanism 1 Mechanism 2 Mechanism 3 Architecture Component 1 Component 2 Component 3 Activity 1 Activity 2 Activity 3 © The SABSA Institute C.I.C 2021 52  DLCAMSF230904 ORM Architecture Inheritance & Re-use Subsequent SABSA Risk Assessments / Project – Re-use What attributes from the current-state Attributes Enterprise Security Architecture are tf required for project #2 with similar performance bands / thresholds? with performance targets & risk appetite thresholds We have already analysed and modeled the appropriate Risk Assessment Threat Vulnerability - Impact controls to achieve these Ratings Opportunity Strength + Impact attributes at those performance levels Integrated Controls & Enablers Library – MTCS Modelled Service 1 Service 2 Service 3 We have already solved this problem – inherit all entries Mechanism 1 Mechanism 2 Mechanism 3 in layer-map linked to the attributes: Component 1 Component 2 Component 3 re-use our now‘standard’ Activity 1 Activity 2 Activity 3 solutions © The SABSA Institute C.I.C 2021 53  DLCAMSF230904 ORM Architecture Inheritance & Re-use Subsequent SABSA Risk Assessments / Projects – Enhance What attributes & Attributes performance thresholds required by project #2 are new to the current-state architecture? with performance targets & risk appetite thresholds Add these new attributes, targets, risks & control Risk Assessment Threat Vulnerability - Impact decisions to the Ratings current-state Opportunity Strength + Impact Enhances & expands the Integrated Controls & Enablers Library – MTCS Modelled standard solutions library Service 1 Service 2 Service 3 Service 4 Mechanism 1 Mechanism 2 Mechanism 3 Mechanism 4 Component 1 Component 2 Component 3 Component 4 Activity 1 Activity 2 Activity 3 Activity 4 © The SABSA Institute C.I.C 2021 I 54  DLCAMSF230904 Strength-in-Depth Capability Engineering Application of the SABSA Multi-tiered Control Strategy to each architected control layer Deter Management of Products & Environment Management Prevent Component Standards Service Management Control Components Control Mechanisms Control Services Infrastructure & Contain 1111111 EEE Detect & Notify É Evidence & Track Recover & Restore Assure Traceable Control Capability © The SABSA Institute C.I.C 2021 55  DLCAMSF230904 Risk Assessment in Controls Architecture The Role of Pure Risk in Control Value Assessment ÉF Risk High Proportional Risk Pure Risk Admissible Admissible 100% vulnerability 55% 36% 9% } 100% weakness } Control É value of current Current (as-is) Admissible Admissible architecture Total control Ee Residual risk 32% 68% value of } exceeds appetite architecture Control value of proposed Target (to-be) Admissible Admissible change O All residual risk 100% within appetite © The SABSA Institute C.I.C 2021 56  DLCAMSF230904 Risk Assessment in Controls Architecture The Role of Appetite Thresholds in Control Value Assessment Risk Appetite Spectrum Unacceptable Warning Acceptable ÉÉ Primary KRI Threshold Secondary KRI Threshold ⚫ Deploy control A? How do we assess the effectiveness of a control? Which control or ⚫ Deploy control B? combination of controls causes the residual risk rating to cross a threshold? ⚫ Deploy control A + B? ⚫ Deploy controls from each domain of the multi-tiered controls strategy? © The SABSA Institute C.I.C 2021 57  DLCAMSF230904 Risk Assessment in Controls Architecture The Role of Actuarial Data in Control Value Assessment e Attribute performance criteria removes some O Estimated Unacceptable subjectivity in initial rating by creating defined impact parameters & thresholds Current State O Predicted Warning Predicted Warning Warning Target State Target State Iteration 1 Retain actuarial data & historical rating data Informed estimate result of controls deployment Iteration 20 Low process maturity, low confidence in rating Validated result of controls deployment High process maturity, high confidence in rating © The SABSA Institute C.I.C 2021 58  DLCAMSF230904 Dynamic Risk & Policy Management Example: credit card security alert thresholds Normal Risk Appetite Spectrum Increased actuarial impact or increased threat level causes change in warning Unacceptable Warning Acceptable threshold F se Primary Secondary High Alert Risk Appetite Spectrum KRI Threshold KRI Threshold Acc Unacceptable Warning ept able Primary Earlier KRI Threshold Secondary KRI Threshold SABSA O o © The SABSA Institute C.I.C 2021 59  DLCAMSF230904 SABSA Assurance Defined Assurance Providing confirmation and confidence that the enterprise risks are being adequately managed and that residual E tolerance information risk is within the risk appetite or risk FEÉE of the organisation Assurance Management The process of managing assurance, including governing, planning and executing an enterprise assurance programme The process of providing assurance that the enterprise security architecture is Business-driven Complete Consistent Robust Fit-for-purpose in every way ÉÉ Assurance Management Activities The set of activities that comprise ‘assurance management’ Audits, Tests, Reviews, Checks & Balances © The SABSA Institute C.I.C 2021 60  DLCAMSF230904 SABSA Assurance Framework Manage & Measure ÉÉI SABSA Implement Assurance Strategy & Planning Levels Design © The SABSA Institute C.I.C 2021 61  DLCAMSF230904 Determining the Assurance Levels Assurance Levels Correlate to Risk Levels Level 4 Level 3 Ée Level 2 Level 1 4 Risk Levels 4 Assurance Levels © The SABSA Institute C.I.C 2021 62  DLCAMSF230904 Constructing a SABSA Assurance Matrix Two-dimensional view through the SABSA Assurance Framework cube Lifecycle View Risk Assets to Process People Location Timeliness (one of four) Man’ment Level 1 Level 2 Level 3 Level 4 © The SABSA Institute C.I.C 2021 63  DLCAMSF230904 SABSA Assurance Levels Relationship Between Assurance Level & Risk Level Ate SABSA Assurance Levels A Formal Accreditation B C Defence in Depth D Special Treatments E F Baseline Domains G H I J K L M N O P 0 O_0 1 2 3 4 0 Risk levels © The SABSA Institute C.I.C 2021 64  Dd_etT DLCAMSF230904 Policy Compliance & Auditing Services provided by the “Assurance Role” defined in section 9 of module F1 The higher the risk level, the more assurance services are required Specialist skills & tools required at each architecture layer & domain level Traceable auditing concept to ÉEEE support through-life risk management The elements at each architecture layer are complete, fit-for-purpose, effective, and trace from each layer of the Motivation Column to the next The Risk Management activities at each Management Architecture layer are complete, fit-for-purpose, effective, and trace from each layer of the Motivation Column to the next The Risk Management monitoring & reporting activities follow the Domain responsibility model The aggregation of Risk Status is effective between domain levels IÉEE The controls & enablers in each domain are risk proportional & effective © The SABSA Institute C.I.C 2021 65  4 DLCAMSF230904 Sample Questions Competency Domain 2 Working as individuals, answer the following two questions. Time limit is 2 minutes 30 seconds. As a group we will then discuss the questions. © The SABSA Institute C.I.C 2021 66  DLCAMSF230904 Competency Domain 2 Which ONE of the following statements about SABSA Assurance is FALSE? A. Assurance Management in SABSA is defined as the process of managing assurance, including governing, planning and executing an enterprise assurance programme B. The SABSA Assurance Framework isÉ often presented as a cube in which the headings of all three axes can be customised C. SABSA Assurance Management provides assurance that the Enterprise Security Architecture as a whole, and its individual elements, are business-driven, complete, consistent, robust and fit-for-purpose D. When populating a SABSA Assurance Matrix, risk exposure levels in a domain determine the Assurance levels required © The SABSA Institute C.I.C 67  DLCAMSF230904 Competency Domain 2 With regard to the SABSA Policy Architecture Framework which of the following statements is FALSE? A. The Contextual layer contains separate enterprise-wide policies for risk categories such as Business Continuity, Physical Security and Health & Safety ÉÉÉ B. The Conceptual layer contains the Enterprise Information Security Policy as one of several related Operational Risk Management categories C. The Logical layer contains policies for each domain in the enterprise domain model, each owned by a domain authority D. The Physical layer contains procedures as the mechanisms to implement policy within each domain © The SABSA Institute C.I.C 68  DLCAMSF230904 Transformation & Service E Architecture Section 14 © The SABSA Institute C.I.C 2021 69  DLCAMSF230904 or Scope: Design Phase - Process Architecture Management Matrix Matrix Process Maps & Services Delivery Management Information Flows; Logical Functional Transformations; Service Oriented SLA Management; Supply Chain Management; BCM; Financial Management; Architecture; Services Catalogue; Transition Management Application Functionality and Services Process Mechanisms Operations Management É Physical Working Procedures; Application Job, Incident, Event, and Software; Middleware; Systems; Disaster Recovery Management Security Mechanisms; Process Control Points Process Components & Standards Component Deployment Component Tools and Protocols for Process Delivery; Product & Component Selection, Procurement. Application Products Project and Standards Management © The SABSA Institute C.I.C 2021 70  DLCAMSF230904 Section 14 Competency Objectives Competency / Question Domain 3 – How (Process) Knowledge Element Process Analysis Knowledge Competency so Describe the concept of top-down Comprehension Competency Explain the implications & applications of Process analysis top-down process analysis in SABSA ÉETE Security Services Define security service & security Contrast the applications of primary, service types Secondary, implicit & explicit services Describe the implications of static & Contrast & summarise the placement of Dynamic information, information flows & Security Services in architecture layers transactions on security service specification Identify the position in the architecture Traceably associate services, mechanisms, Matrix of services, mechanisms, components & management activities EE components & management activities Service Value & SLAs Describe the principle of Security Service Explain the application of the Service Value Value concept together with roles & responsibilities, and domain models from F1 to define an SLA © The SABSA Institute C.I.C 2021 71  DLCAMSF230904 SABSA Top-Down Process Analysis Contextual: Meta-Processes Vertical Security Consistency Conceptual: Strategic View of Process ÉE to Logical: Information Flows & Transformations Physical: Data Flows & System Interactions Component: Protocols & Step Sequences Horizontal Security Consistency © The SABSA Institute C.I.C 2021 72  DLCAMSF230904 Vertical Consistency at 0 A requirement for a business process is expressed as an attribute with a performance 2 1 target A process is ‘executed’ by a series of progressively more granular steps down through each of the architecture layers ÉETES Vertical consistency means that the conceptual attribute required at the top of the process model must be accurately represented at each layer (or the requirement is not met) Security Services are the means of specifying and providing the required functionality © The SABSA Institute C.I.C 2021 73  DLCAMSF230904 SABSA Concept of a Security Service specification ÉED TEE Business-driven requirements organised into a consistent, logical / functional Arranged as a Services-Oriented Architecture Specified independently of the technical (physical) mechanisms used to deliver them Examples: SABSA Matrix t.EE Entity authentication service Process 377 Stored data confidentiality service Transaction source verification service Entity unique identification service Monitoring service Logical Derived exclusively from the contextual and conceptual layers above, especially Attribute profile (with performance metrics) Control & Enablement objectives (to defined risk appetite) Domain model (organisation & infrastructure policy architecture) Trust model (inter-domain service requirements) Etty © The SABSA Institute C.I.C 2021 74  INE DLCAMSF230904 Information Flows & Transformations Logical Logical Domain 1 information Logical Domain 2 1 flow Presented Presented information information É Transformation Domain 1 (Application) Physical Collected Transformed Data Transformed data Transfer input data data StoredD Stored Data A Data B Data C ata D Data E a a Data Domain 1 Data Domain 2 Data Domain 3 © The SABSA Institute C.I.C 2021 75  DLCAMSF230904 0 Contains Static & Dynamic Information Information Type Properties Example Services Example O E Static Information Does not move or change in the short term EE Master records and files (such as customer information) Executable object code Configuration information for systems and applications Free format messages Confidentiality protection Integrity protection Availability protection such as used in e-mail E Structured application Confidentiality protection O Messages such as Integrity protection E Dynamic Dynamic database queries Availability protection Information Information using SQL Authenticity of source Transaction information Non-repudiation System and service management information © The SABSA Institute C.I.C 2021 76  DLCAMSF230904 Business Transaction Services Eto Business transactions are a special case of dynamic information. Protecting them implies some specific security services: Business user / entity identification: to identify uniquely every business user.& entity Business user / entity authentication: to verify the identity of every business user & entity, as a pre-requisite to granting access to business resources and services. Business user / entity authorisation: to ensure that every business user & entity has been authorised for access to the functions and information needed to carry out legitimate business activities, and that access to other, unauthorised functions É and information is specifically prevented. Business transaction integrity protection: to ensure that business transactions are completed as expected, and that they are protected from unauthorised modification, duplication, replay, delay or deletion. Business transaction authentication: to ensure that all business transactions are initiated by authenticated entities. Business transaction non-repudiation: to give assurance that all entities involved in a business transaction cannot later deny having participated to the transaction. © The SABSA Institute C.I.C 2021 77  DLCAMSF230904 Primary Security Services Primary security services are wholly embedded testee within a domain element Self-contained within the element to provide security functionality that secures the element Domain 8E Primary Service Primary Service o Example: A primary service wholly contained within an application element secures the application to specified functionality (such as confidentiality) © The SABSA Institute C.I.C 2021 78  DLCAMSF230904 Secondary Security Services PEE Secondary security services operate between elements in a domain They secure the communications between the elements Domain Primary Service Secondary Service Primary Service Example: A secondary service between elements in an application 0 domain secures the communication between them to specified functionality (such as confidentiality). The service is not wholly self- contained within the code of a single element but has a secondary deployment such as in layer 7 of the OSI stack. © The SABSA Institute C.I.C 2021 79  DLCAMSF230904 Implicit Security Services Implicit security services are implicit ÉI_in a domain – they secure the domain from within o Domain Primary Service Secondary Service Primary Service Example: Both primary and secondary services in our previous examples are Providing ‘applications security’ from within the applications domain © The SABSA Institute C.I.C 2021 80  DLCAMSF230904 It Explicit Security Services Explicit security services are explicitly requested from one domain to another Domain 1 Secures Domain 1 Element Implicit Service from within t.EE Explicit request Secures Explicit Service Implicit Service Domain 2 Secures Domain 1 from within Domain 2 by delivering service from Domain 2 Example: Applications domain requests service from common services domain through an API © The SABSA Institute C.I.C 2021 81  DLCAMSF230904 Enterprise Common Security API Third-Party Vendor Application Adaptors are software IEEE Applications É modules that convert the calls from 3rd party applications into those of the ECSS Enterprise Applications and