1 / 47

OMG Technical Meeting - March 2013 Presentation to UPDM Group Security View

OMG Technical Meeting - March 2013 Presentation to UPDM Group Security View. Introduction Presentation Objectives Background Overview Security View Details Next Steps Q&A. Agenda. Introduce DRAFT Security View For each sub-view: Purpose, Description, Concepts

bert-stafford
Download Presentation

OMG Technical Meeting - March 2013 Presentation to UPDM Group Security View

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OMG Technical Meeting - March 2013 Presentation to UPDM Group Security View

  2. Introduction Presentation Objectives Background Overview Security View Details Next Steps Q&A Agenda 2

  3. Introduce DRAFT Security View For each sub-view: Purpose, Description, Concepts Conceptual Architecture & Deliverables Sample attribution template Convey essence and flow of security lifecycle; Our road ahead for SecV Presentation Objectives 3

  4. Background Drivers • “Security at the front” not as an afterthought • Information & IT Security Capability • confidentiality, integrity, availability, non-repudiation, and audit-ability • of defence information and the supporting systems and networks. • Pan-enterprise Security

  5. Background Collaborators • Security is “special” • normally involves Specialists • has unique perspectives • IM & IT Security at the forefront • Key Collaborators: • IM & IT Security (D IM Secur) • IT Engineering & Integration (DIMEI)

  6. Background Outcome • Redesign and partitioning of SecV-1 into 1a and 1b • No change to existing SecV-2 and 3 • Discovery of new business requirements leading to SecV-4, 5, 6 & 7

  7. Overview Draft Sub-views SecV-1a: Asset Security Domain & Valuation Rating SecV-1b: Asset-at-Node Security Strength Requirement SecV-2: Data Element Security Matrix SecV-3: Aggregated Information Security Matrix SecV-4: Security Control Specification SecV-5: Security Control Profile SecV-6: Security Control Service Profile SecV-7: Asset-At-Node Threat Mitigation

  8. Security Methodology (1/1) SecV-1a Asset Security Domain & Valuation Rating SecV-1b Asset-at-Node Security Strength Requirement SecV-2 Data Element Security Matrix SecV-3 Aggregated Information Security Matrix Conduct Asset Sensitivity; Assign Security Domain & Valuation Rating Conduct TRA; Assign Security Strength Requirement Assess IERs and SDEs; Assign Security Classification Register Classified Data Element Combinations Asset Classification and Valuations Lists TRA Results and Security Strength Requirements Resource Flow & IER & SDE Assessments Data Element Combinations Risk Register 8

  9. Security Methodology (2/2) SecV-4 Security Control Specification SecV-5 Security Control Profile SecV-6 Security Control Service Profile SecV-7 Asset-at-Node Threat Mitigation Define Security Controls (CSEC & DND) Establish Security Control Profile for Asset (FoS) & Asset-at-Node Define Security Services; Establish Security Control Service Profile Establish Security Services to address Asset-at-Node Security Needs Security Control Taxonomy Security Control Profile for Asset & Asset-at-Node Security Service Taxonomy & Service Profiles Asset-at-Node Threat Mitigation Specification 9

  10. SecV-1a : Asset Security Domain and Valuation Rating The Asset (typically a member at some level of abstraction within the Asset FoS – Family of Systems) would undergo an AssetSensitivity Analysis; the resulting Statement of Sensitivity is described and referenced in SecV-1a. Based on the sensitivity analysis, the Security Officer determines and assigns a Security Domain to the Asset. The DND Security Officer is also able to assign a Valuation Rating (Very Low to Very High) to the Asset. SecV-1a Purpose 10

  11. Asset within FoS Structure Asset Materiel System Personnel Cash Weapons IT System e.g. SAP Communications SAP Sub-System A/R SAP Sub-System G/L SAP Sub-System Payroll SAP Application Module G/L 01 SAP Application Module G/L 02 SAP Application Module 03 11

  12. Security Classification Taxonomy Security Domain (e.g.) UNCLASSIFIED PROTECTED A PROTECTED B PROTECTED C CONFIDENTIAL SECRET TOP SECRET … Security Caveat (e.g.) CANUK NATO AUSCANNZUKUS CANUS FOUR EYES FIVE EYES …

  13. SecV-1a Conceptual Model Recommends Asset Statement of Sensitivity Determines Results in Valuation Rating Asset (FoS) Security Domain Values Classifies Information Systems Cash Equipment INCLUDES Resource Sub Types Personnel Real Property 13

  14. SecV-1a Attribution Template Example: Data Collection Dialog for Asset Valuation and Security Classification

  15. SecV-1b: Asset-At-Node Security Strength Requirement The logical Asset classified & valued via SecV-1a “deployed” (assigned) to a Node (OV-2) Initiates a Threat Risk Assessment (TRA) being now referred to as Asset-At-Node. SecV-1b enables the capture of relevant information from the TRA, including links to threats, vulnerabilities, impacts, and control objectives. The TRA enables the DND Security Officer to assign a Security Strength Requirement Rating to the Asset at Node. SecV-1b Purpose 15

  16. SecV-1b Conceptual Model Security Strength Requirement Matrix Exposure Impact Node Asset Asset-at-Node Threat Risk Assessment (TRA) Recommends Determines Assignment of Asset to Node Initiates Security Control Objectives Assigned to Operational Node Refer OV-2 16

  17. SecV-1b Attribution Template Example: Data Collection Dialog for Asset@Node TRA and Security Strength Requirement

  18. SecV-2 – Data Element Security Matrix The OV-3 and SV-6 sub-views require that the security parameters of each Information Exchange Requirement (IER) and System Data Exchange (SDE) be analyzed and documented. The security classification of an IER or SDE is based on the fact that it contains one or more data elements of that security level. SecV-2 enables the security classification and requirements of the set of data elements that comprise the IER or SDE. Covers both privacy and national security issues. SecV-2 Purpose 18

  19. SecV-2 Data Model (DADM) 19

  20. SecV-3 Purpose SecV-3 – Aggregated Information Security Matrix Aggregation of Data can result in higher classified Information Registration of Data Element Combinations Potential for security issues is captured “Some analysis required” 20

  21. SecV-3 Data Model (DADM) 21

  22. SecV-4 Purpose SecV-4 Security Control Specification • SecV-4 enables definition and maintenance of Security Controls in a taxonomy • Security Controls • reusable objects that can be shared • and associated to Assets; • Allows Security Control XREF to policies, legislation and regulations, standards, other knowledge artifacts, e.g.: • ITSG 33 Annex 3 (CSEC) • NIST 800-53 Rev 3 22

  23. SecV-4 Conceptual Model INCLUDES: Management Technical Operational Security Control Class Comprises For Example: Access Control Awareness and Training Personnel Security Security Control Family Organizes XREF links to Knowledge Artifacts in Corporate Memory, Web or elsewhere Security Control Links For Example: AC 17 – Remote Access 23

  24. SecV-4 Attribution Template Example: Data Collection Dialog for Security Control Specification

  25. SecV-5: Security Control Profile SecV-5 enables the association of Security Controls that are applicable to an Asset (FoS). This is referred to as the AssetSecurity Control Profile. SecV-5 further allows the Security Officer to create and maintain a similar Profile for the Asset-At-Node; The Asset-at-Node would automatically inherit (as default) the Asset Security Control Profile as a starting point. The end result is titled the Asset-At-Node Security Control Profile. SecV-5 Purpose 25

  26. SecV-5 Conceptual Model Node Asset Asset (FoS) Asset Security Control Profile Refers Identifies Security Control Deployed to Asset-At-Node Security Control Profile Selects Requires 26

  27. SecV-5 Attribution Template Example: Data Collection Dialog for Security Control Profile

  28. Sec V-6: Security Control Service Profile SecV-6 does two distinct things: enables the specification and maintenance of the Security Service links a subset of Security Services to a Security Control; this is referred to as the Security Control Service Profile. Security Services reusable security mitigation mechanisms. can be automated or manual automated security services can be further defined in terms of its hardware and software components. SecV-6 Purpose 28

  29. SecV-6 Conceptual Model (1/2) Security Service Sub-Type Automated Security Service Non-Automated Security Service Comprises Security Service Software Component Security Service Hardware Component 29

  30. SecV-6(1) Attribution Template Example: Data Collection Dialog for Security Service Specification

  31. SecV-6 Conceptual Model (2/2) Security Control (SecV-4) Manages Security Control Service Profile Mitigated By Security Service 31

  32. SecV-6(2) Attribution Template Example: Data Collection Dialog for Service Control Service Profile

  33. SecV-7: Asset-At-Node Threat Mitigation SecV-7 enables creation and maintenance of an Asset-At-Node Threat Mitigation Package: comprises a subset of Security Services needed by the Security Controls to protect the Asset-at-Node. Selection is influenced by the Strength Requirement Rating SecV-7 Purpose 33

  34. SecV-7 Conceptual Model Node Asset Asset-At-Node Security Control Profile Refer SecV-5 Security Control Service Profile Refer SecV-4 Security Control Requires Refer SecV-6 Asset-at-Node Threat Mitigation Package Selects Security Service Mitigation Security Control Service Comprises Refer SecV-1b Asset-At-Node Security Strength Requirement Influences 34

  35. SecV-7 Attribution Template Example: Data Collection Dialog for Threat Mitigation Package

  36. Asset-At-Node Mitigation Lifecycle Deployed to Asset Refer SecV-1a has Asset-at-Node Security Control Profile Asset-At-Node Security Strength Requirement Determines TRA Refer SecV-5 Establishes Refer SecV-1b has Security Control Objectives Security Control Refer SecV-4 Required by Influences Node Asset Security Control Service Profile Asset-at-Node Threat Mitigation Pkg Security Control Service Mitigated By Refer SecV-6 (2) Refer SecV-6 (1) Refer SecV-7 Asset

  37. Theoretical product, at this point Much work remains ensure responsive to needs Confirm concepts are valid, not redundant Validation effort initiated Update at next meeting in June. Road Ahead 37

  38. Security View Road Map 15 Mar EA IOC FOC Today 2012 2013 2014 ACTIVITY S O N D J F M A M J J A S O N D J F M A M J J A S O N D Preliminary Development Work Presentation of Draft to OMG Testing and validation Finalize Security Views Presentation of Final to OMG Publish SecV in DNDAF Implement SecV in Qualiware

  39. Looking for Feedback and Encouraging Wider Collaboration Contacts: VINCENT.QUESNEL@forces.gc.a EA Programme Support (613) 993-6164 GREG.ERICKSON@forces.gc.ca EA Development (613) 990-8341 Q&A 39

  40. SecV-1a Class Diagram 40

  41. SecV-1b Class Diagram 41

  42. SecV-2 Class Diagram 42

  43. SecV-3 Class Diagram 43

  44. SecV-4 Class Diagram 44

  45. SecV-5 Class Diagram 45

  46. SecV-6 Class Diagram 46

  47. SecV-7 Class Diagram 47

More Related