![Information Security and Security Architecture: Two Complementary Ambits The Open Group 3 rd Security Practitioners Conference July 22 – 23, 2009 Toronto, Ontario Murray Rosenthal, CISA Risk Management & Information Security I&T Strategic Planning & Architecture City of Toronto [email_address]](https://image.slidesharecdn.com/opengroup-spcrosenthalv3-101019093313-phpapp01/85/Open-group-spc-rosenthal-v3-1-320.jpg)
![Information Security and Security Architecture: Two Complementary Ambits The Open Group 3 rd Security Practitioners Conference July 22 – 23, 2009 Toronto, Ontario Murray Rosenthal, CISA Risk Management & Information Security I&T Strategic Planning & Architecture City of Toronto [email_address]](https://image.slidesharecdn.com/opengroup-spcrosenthalv3-101019093313-phpapp01/85/Open-group-spc-rosenthal-v3-19-320.jpg)
Open group spc rosenthal v3
- 1. Information Security and Security Architecture: Two Complementary Ambits The Open Group 3 rd Security Practitioners Conference July 22 – 23, 2009 Toronto, Ontario Murray Rosenthal, CISA Risk Management & Information Security I&T Strategic Planning & Architecture City of Toronto [email_address]
- 2. Problem Statement: Intent vs. Reality Intent Organizations stand up information security and security architecture as essential risk management practices, in line with “due care” standards. Requirement to design, develop and stand up programmatic approaches to information security on an authoritative, sustainable basis. Requirement to design, develop and deploy systems that comply with generally accepted architectural standards. Reality Obfuscation of practice “edges”. Obfuscation of organizational spans of control. Obfuscation of authority. Obfuscation of professional skill sets. Information security ≠ security architecture. Security architecture ≠ information security. Ready-Fire-Aim. Absence of a strategic plan and strategic planning for information security and security architecture.
- 7. Generally Accepted INFOSEC Assertions Confidentiality Integrity Availability Data-centric Identification Authentication Authorization Entity-centric ( h uman/system ) Non-repudiation Information Security Ecosystem Attribution Information Security Ecosystem Sustainability Risk - based Subsystems Data - centric Scalability Persistence Pervasiveness Organic INFOSEC Ecosystem Sustainable Risk - based Subsystems Data-centric Scalable Persistent Boundaryless Pervasive Organic INFOSEC Ecosystem Risk Mitigation Approaches Deterrence Avoidance Acceptance Transfer Recovery Restoration
- 9. Generally Accepted INFOSEC Assertions Confidentiality Integrity Availability Data-centric Identification Authentication Authorization Entity-centric ( h uman/system ) Non-repudiation Risk Mitigation Approaches Deterrence Avoidance Acceptance Transfer Recovery Restoration Reviewed and Audited Planned, Managed, Measurable and Measured Development Lifecycle Requirement Staff Aware and Trained Adequate Resources Committed Addressed and Enforced in Policy Roles Responsibilities, Segregation of Duties Risk-based Viewed as a Business Requirement. Accountable Leaders Enterprise- wide INFOSEC Governance Information Security Governance Attribution Information Security Governance
- 13. S E C U R I T Y A R C H I T E C T U R E
- 14. If You Don’t Have Security Architecture… Project Level Program Level Let the project lapse and not go forward Lack of artefacts = lack of security design credibility. Let the enterprise go out of business Security architecture becomes a poster child as the business tailspins out of control. Reverse-engineer the project’s “as is” models Takes time and costs money. Reverse-engineer the enterprise’s “as is” models from the existing enterprise Takes time and costs money. Trial-and-Error Application of security artefacts is ad hoc, or not at all. Trial-and-Error Security artefacts are created informally, or not at all, and are not authoritative.
- 15. SABSA Framework Security Operations Schedule Security of Sites, Networks and Platforms Application and User Management and Support Security Service Management and Support Operational Risk Management Assurance of Operational Continuity Operational Security Step Timing and Sequencing Processes, Nodes, Addresses and Protocols Identities, Functions, Action and ACLs Security Products and Tools Security Standards Detailed Data Structures Component Control Structure Execution Platform and Network Infrastructure Users, Applications and the User Interface Security Mechanisms Security Rules, Practices & Procedures Business Data Model Physical Security Processing Cycle Security Domain Definitions and Associations Entity Schema and Privilege Profiles Security Services Security Policies Business Information Model Logical Security-Related Lifetimes and Deadlines Security Domain Model Security Entity Model and Trust Framework Security Strategies and Architectural Layering Control Objectives Business Attributes Profile Conceptual Business Time Dependencies Business Geography Business Organization and Relationships Business Process Model Business Risk Model The Business Contextual Time (When) Location (Where) People (Who) Process (How) Motivation (Why) Assets (What)
- 16. Disentangling Two Complementary Ambits
- 18. Harvestable Nuggets Develop strategic plans and implementation schedules for information security and security architecture, respectively. Disentangle spans of control and authorities. Institute practice “edge” management and anti-collision protocols. Recruit based on differentiated skill sets and practice requirements.
- 19. Information Security and Security Architecture: Two Complementary Ambits The Open Group 3 rd Security Practitioners Conference July 22 – 23, 2009 Toronto, Ontario Murray Rosenthal, CISA Risk Management & Information Security I&T Strategic Planning & Architecture City of Toronto [email_address]
Editor's Notes
- #18: The schematic is a conceptual reference model that recognizes both EA and non-EA deliverables within a generalized organizational context. The model acknowledges that, in complex organizations, there is a need for both (a) information security practitioners who are focused on sustainable and authoritative INFOSEC program development and (b) security architects who are responsible for the design and on-going care-and-feeding of artefacts used to construct complex systems. These artefacts are owned and operated by security architects and are “pure play” security abstractions that directly affect security posture considerations in system construction. This set of security architecture artefacts are vertical in their orientation. There is another set of artefacts, owned and operated by business, information, application and technology domain architects, that contain security architecture representations or consideration points. For example, a technology domain architect contains an interoperability specification standard into which security architecture requirements are infused. An application architect publishes a specification that externalizes all applicable web services. The security architect infuses the specification with security architecture considerations. In these situations, security architecture is said to be horizontal .