Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise Security Architecture


Published on

Enterprise Architecture
Enterprise Architectural Methodologies
A Brief History of Enterprise Architecture
Zachman Framework
Business Attributes
Features & Advantages
SABSA Lifecycle
SABSA Development Process
SMP Maturity Levels

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Enterprise Security Architecture

  1. 1. Enterprise Security Architecture Arnab Chattopadhayay Vice President, Engineering Infoworks Inc.
  2. 2. About Me • Love to 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. 3. Enterprise Architecture •A field born about 30 years ago •Initially targeted to address two problems •System complexity •Inadequate business alignment
  4. 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. 5. 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
  6. 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. 7. Zachman Framework Source: [Executive Mgmt Perspective] [Business Mgmt Perspective] [Architect’s Perspective] [Engineer’s Perspective] [Technician’s Perspective]
  8. 8. 4 Ways Zachman helps in Architecture Dev •Every stakeholder's perspective is captured •Completeness of every artifact •Provide strong traceability •Improve Tech-Business Alignment
  9. 9. What Zachman does not provide •Step-by-step process to create new architecture •Validating an architecture •Deciding future architecture •It is not a Methodology
  10. 10. Enterprise Information Security Architecture •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. 11. Well Known Cyber Security Frameworks •NIST CSF •Sherwood Applied Business Security Architecture (SABSA) •We will discuss SABSA in details
  12. 12. What is SABSA •Methodology for 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. 13. 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 • 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. 14. ©SABSA foundation, 2010
  15. 15. Business Driven Architecture •Never losing site of the organisation’s goals, objectives, success factors and targets •Contextual architecture captures and presents the full set of relevant requirements
  16. 16. Credible Abstraction is Key •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. 17. Business Attributes Profiling •Conceptual abstraction of a real business requirement •Standardized and re- usable set of specifications •Provides standardized lingua
  18. 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. 19. Two-way Traceability – Drivers to Attributes
  20. 20. Two-way Traceability – Attributes to Drivers
  21. 21. Sample of Business Drivers 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
  22. 22. Implementation - User Attribute 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. SABSA Development Process
  28. 28. SMP Maturity Levels
  29. 29. 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?
  30. 30. SABSA Vitality Framework
  31. 31. Thank You