Downloaded 150 times
![Zachman Framework
Source: zachmaninternational.com
[Executive Mgmt
Perspective]
[Business Mgmt
Perspective]
[Architect’s
Perspective]
[Engineer’s
Perspective]
[Technician’s
Perspective]](https://image.slidesharecdn.com/1-161114084643/75/Enterprise-Security-Architecture-7-2048.jpg)
Uploaded byPriyanka Aash
Enterprise Security Architecture
The document discusses enterprise security architecture, highlighting the importance of comprehensive methods for defining security across systems. It explores the Zachman framework for organizing architectural artifacts and introduces the SABSA model as a business-driven approach to security architecture. SABSA emphasizes alignment with business goals, risk management, and provides a detailed lifecycle for security architecture development.
More Related Content
Similar to Enterprise Security Architecture
Enterprise Security Architecture
- 1. Enterprise Security Architecture Arnab Chattopadhayay VicePresident, Engineering Infoworks Inc.
- 2. About Me • Loveto design, build and protect large scale systems • IAM, Cryptography, Consulting, Program Management and Governance • Large MNC to startup across the globe • VP Engineering of Infoworks (a silicon valley Big Data Startup) • Prior to this, I had worked with British Telecom Research, BT Consulting, iViZ and MetricStream • Patent – USPTO 9,348,901 • MS (Telecom Engineering), University College London
- 3. Enterprise Architecture •A fieldborn about 30 years ago •Initially targeted to address two problems •System complexity •Inadequate business alignment
- 4. Enterprise Architectural Methodologies •Consortia-developed Frameworks • ISO 19439 • RM-ODP (ITU-T X.901-904) • TOGAF • Defense Industry Framework • DoDAF • MODAF • NAF • Open Source Frameworks • TRAK • SABSA • Proprietary Frameworks • Zachman Frameworks • IAF (Capgemini, 1993) • Government Framework • ESAAF • FEAF • NIST Enterprise Architecture Model
- 5. 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
- 6. Zachman Framework •The Zachman"Framework" is actually a taxonomy for organizing architectural artifacts •Two dimensions • Players in the game • Architectural Artifacts •Players in the game: Actors •Architectural Artifacts: the What, How, Where, When, Who and Why
- 7. Zachman Framework Source: zachmaninternational.com [ExecutiveMgmt Perspective] [Business Mgmt Perspective] [Architect’s Perspective] [Engineer’s Perspective] [Technician’s Perspective]
- 8. 4 Ways Zachmanhelps in Architecture Dev •Every stakeholder's perspective is captured •Completeness of every artifact •Provide strong traceability •Improve Tech-Business Alignment
- 9. What Zachman doesnot provide •Step-by-step process to create new architecture •Validating an architecture •Deciding future architecture •It is not a Methodology
- 10. Enterprise Information SecurityArchitecture •Is the practice of applying comprehensive and rigorous methods for describing security of current and future systems • Ref: Wikipedia •Applied to people, process and technologies •Goals • Provide structure • Enable business-to-security alignment • Enforce Top down approach • Strong traceability • Abstract complex concepts • Establish common lingua of information security
- 11. Well Known CyberSecurity Frameworks •NIST CSF •Sherwood Applied Business Security Architecture (SABSA) •We will discuss SABSA in details
- 12. What is SABSA •Methodologyfor Building Security Architecture: •Business-driven •Risk and opportunity focused •Includes security service management • Comprised of a number of integrated frameworks, models, methods and processes
- 13. SABSA Model • Comprisesof six layers • Based on Zachman framework/taxonomy • The Security Service Management Architecture has been placed vertically across the other five layers • Each horizontal layer is made of a series of vertical communication interrogatives • What (Assets) • Why (Motivation) • How (Process and Technology) • Who (People) • Where (Location) • When (Time)
- 14.
- 15. Business Driven Architecture •Neverlosing site of the organisation’s goals, objectives, success factors and targets •Contextual architecture captures and presents the full set of relevant requirements
- 16. Credible Abstraction isKey •Meaningful traceability is enabled by credible abstraction from business context to business security context •Traceability therefore starts by delivering two slightly different sets of requirements: •Business Requirement: Business reputation •Business Driver for Security: What can security do to protect reputation
- 17. Business Attributes Profiling •Conceptualabstraction of a real business requirement •Standardized and re- usable set of specifications •Provides standardized lingua
- 18. Attributes Profiling Rules& Features • Can be tangible or intangible • Requires a meaningful name and details • Can be customized specifically for a particular organization • Requires a measurement approach and metric • Must be validated (and preferably created) by senior management & the business stake-holders • Performance targets are basis for reporting and/or SLAs in the SABSA Manage & Measure phase
- 19. Two-way Traceability –Drivers to Attributes
- 20. Two-way Traceability –Attributes to Drivers
- 21. Sample of BusinessDrivers Driver ID 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
- 23. Implementation - UserAttribute Business Attribute Business Attribute Definition Measurement Approach Metric Type 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 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 Protected The exchanged information must remain confidential between exchanging parties and must remain untampered Conformance with confidentiality and integrity policies Hard
- 24. 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
- 25. 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
- 26. 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
- 27. 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
- 28.
- 29.
- 30. 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?
- 31.
- 32.
Editor's Notes
- #6 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)
- #9 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.
- #11 Provide structure, coherence and cohesiveness. Must enable business-to-security alignment. Defined top-down beginning with business strategy. Ensure that all models and implementations can be traced back to the business strategy, specific business requirements and key principles. Provide abstraction so that complicating factors, such as geography and technology religion, can be removed and reinstated at different levels of detail only when required. Establish a common "language" for information security within the organization
- #12 From a security architecture point of view, when compared to other security frameworks such as SABSA, NCF has gaps. Among other things, NCF lacks business alignment, traceability and assurance capabilities. For example, the NCF implementation process relies heavily on executives to inform the business about mission priority, risk appetite and budget. This information is critical to the selection of NCF Profiles for an organization. However, business executives are just now starting to engage in conversations about cybersecurity. This is a marked improvement over years past and NCF deserves credit for acting as a catalyst to start those conversations. Executive involvement is a step in the right direction but we still need to help executives and security professionals articulate their organization's security requirements in a way that yields business alignment and leads to successful implementations. Without a good understanding of the business drivers for security and the strategies that go along with them, it is very difficult for security architects to tailor their NCF Profiles effectively in a way that aligns the security technical solutions with the business risk appetite.
- #13 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