Download as PDF, PPTX
![Zachman Framework (1)
• Although the name states, it isn’t a ‘Framework’ in true sense
– A framework is defined as a structure for supporting or enclosing
something else, especially a skeletal support used as the basis for
something being constructed; An external work platform; a scaffold; A
fundamental structure, as for a written work; A set of assumptions,
concepts, values, and practices that constitutes a way of viewing reality
[source: American Heritage Dictionary]
• Zachman can be called a Taxonomy
– The classification of organisms in an ordered system that indicates natural
relationships; The science, laws, or principles of classification; systematics;
Division into ordered groups or categories
• The Zachman "Framework" is actually a taxonomy for organizing
architectural artifacts (in other words, design documents,
specifications, and models) that takes into account both who the
artifact targets (for example, business owner and builder) and what
particular issue (for example, data and functionality) is being
addressed
• Zachman used Building industry as an analogy](https://image.slidesharecdn.com/sacon-presentation-issue2-160713114603/85/Enterprise-Security-Architecture-12-320.jpg)
Uploaded byPriyanka Aash
Enterprise Security Architecture
The document discusses enterprise architecture frameworks and how they can help DreamKart, an ecommerce company facing several IT challenges. It describes the Zachman Framework, which provides a taxonomy for organizing architecture artifacts, and TOGAF, which defines an architecture development method (ADM) process. Using Zachman's taxonomy, DreamKart could classify artifacts, ensure all stakeholder perspectives are considered, and trace business requirements to technical implementations. However, Zachman alone does not provide a process for creating new architectures. TOGAF's ADM process could guide DreamKart in developing enterprise architectures by moving from generic to specific. Using both approaches could help address DreamKart's problems.
More Related Content
Similar to Enterprise Security Architecture
Enterprise Security Architecture
- 1.
- 2. Enterprise Architecture • A field born about 30 years ago • Initially targeted to address two problems –System complexity – Inadequate business alignment – Resulting into • More Cost, Less Value
- 3. Enterprise Architectural Methodologies • Consortia-developed Frameworks – ISO 19439 –RM-ODP (ITU-T X.901-904) – TOGAF • Defense Industry Framework – DoDAF – MODAF – NAF • Government Framework – ESAAF – FEAF – NIST Enterprise Architecture Model • Open Source Frameworks – TRAK – SABSA • Proprietary Frameworks • Zachman Frameworks • IAF (Capgemini, 1993)
- 4. A Brief History of Enterprise Architecture Zacman’s first article 1987 TAFIM released 1994 Clinger-Cohen bill passed 1996 1998 TAFIM retired FEAF 1.2 released 19992002 FEA replaces FEAF TOGAF EE 8.0 released 2003 2003 FEA mostly complete 2011 TOGAF 9.1
- 5.
- 6.
- 7. How are we going to discuss • Each approach would be described in the context of the following real-life problems of a fictional enterprise – IT systems that have become unmanageably complex and increasingly expensive to maintain –IT systems that are hindering the organization's ability to respond to current and future market conditions in a timely and cost-effective manner – Mission-critical information that is consistently out-of-date and/or wrong – A culture of distrust between the business and technology sides of the organization • The question that we would address is: – How would the enterprise choose from the approaches
- 8. Enterprise Architecture Approaches Comparison Metric (1) • Taxonomy completeness (how well you can use the methodology to classify the various architectural artifacts) • Process completeness (how fully the methodology guides you through a step-by-step process for creating an enterprise architecture) •Reference-model guidance (how useful the methodology is in helping you build a relevant set of reference models) • Practice guidance(how much the methodology helps you assimilate the mindset of enterprise architecture into your organization and develop a culture in which it is valued and used) • Maturity model (how much guidance the methodology gives you in assessing the effectiveness and maturity of different organizations within your enterprise in using enterprise architecture) • Business focus (refers to whether the methodology will focus on using technology to drive business value, in which business value is specifically defined as either reduced expenses and/or increased income)
- 9. Enterprise Architecture Approaches Comparison Metric (2) • Governance guidance (how much help the methodology will be in understanding and creating an effective governance model for enterprise architecture) • Partitioning guidance (how well the methodology will guide you into effective autonomous partitions of the enterprise, which is an important approach to managing complexity) •Prescriptive catalogue (how well the methodology guides you in setting up a catalogue of architectural assets that can be reused in future activities) • Vendor neutrality (how likely you are to get locked-in to a specific consulting organization by adopting this methodology) • Information availability (amount and quality of free or inexpensive information about this methodology) • Time to value (the length of time you will likely be using this methodology before you start using it to build solutions that deliver high business value)
- 10. Case Study • DreamKart is an eCommercecompany selling wide range of products to retail market • It has the following systems: – Sales management – Customer portal – Inventory management – Logistics management – Warehouse management – Identity and Access Management – Billing – Credit check – A range of integrated third party services
- 11. Challenges • DreamKart requires regional specializations. For example, different offers and product ranges are needed to be supported in different regions •The logistics companies were acquired and they maintain their own systems and processes • There are number of different inventory management systems • The technical debt is significant and is increasing since changing one system impacts a number of others and rolling out patch in production requires to take systems down • Lines of code is more than one million • Introduction of new features is time consuming and effect the system stability • Due to that, there has been tussle between sales and IT department and as a result, the two departments are not working together. • As a result, the IT is building software without good validation from the user organization
- 12. Zachman Framework (1) •Although the name states, it isn’t a ‘Framework’ in true sense – A framework is defined as a structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed; An external work platform; a scaffold; A fundamental structure, as for a written work; A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality [source: American Heritage Dictionary] • Zachman can be called a Taxonomy – The classification of organisms in an ordered system that indicates natural relationships; The science, laws, or principles of classification; systematics; Division into ordered groups or categories • The Zachman "Framework" is actually a taxonomy for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed • Zachman used Building industry as an analogy
- 13. Zachman Framework (2) •Two dimensions – Players in the game – Architectural Artifacts • Players in the game: Actors • Architectural Artifacts: the What, How, Where, When, Who and Why • The second dimension is independent of the first – Both the Builder and the Owner need to know the ‘What’ – But, they need to know different ‘What’ • From a Business Owner’s perspective, ‘Data’ means business entity – Example: Customer, Product, Demographic Groups, Inventory • From the developer’s perspective i.e. Builder’s perspective, ‘Data’ means rows and columns organized into table, mathematical joins to implement relationships
- 14. Zachman Framework (3) •Zachman Framework is typically depicted as a 6 x 6 matrix – Columns: Communication Interrogatives – Rows: Reification Transformation – The Framework Classification is represented by 36 cells – Each cell represents a player’s perspective (e.g. business owner) and a descriptive focus (e.g. data) • Moving horizontally changes description of the system from same player’s perspective • Moving vertically pin down to single focus but changes players
- 15.
- 16. How Zachman Taxonomy can help DreamKart (1) •Three suggestions • First: use Zachman Taxonomy to the fact that every architecture artifact must live in one and only one cell – For an artifact if it is not possible to establish its cell unambiguously, then there is something wrong in the selection of the artifact – As DreamKartbegins accumulating artifacts in the development of Enterprise Architecture, it can use the Zachman grid to clarify the focus of each of these artifacts. • Example: artifacts relating to a service-oriented architecture live mostly in the third row (designer's perspective). They generally will not be of interest to the business owner • Second: achieve architectural completeness by completing every cell – A cell is complete when it contains sufficient artifacts to fully define the system for one specific player looking at one specific descriptive focus – When every cell is populated with appropriate artifacts, there is sufficient amount of detail to fully describe the system from the perspective of every stakeholders looking at the system from every possible angle (descriptive focus). So, DreamKart can use the Zachman grid to ensure that appropriate discussions are occurring between all of the important stakeholders
- 17. How Zachman Taxonomy can help DreamKart (2) •Third: cells in columns should be related to each other. – Example:take the data column (the first column) of the Zachman grid. From the business owner’s perspective, data is information about the business. From the database administrator's perspective, data is rows and columns in the database – While the business owner thinks about data quite differently from the database administrator, there should be some relationship between these perspectives. Somebody should be able to follow CxO’s business requirements and show that the database design is, in fact, being driven by those requirements. If the requirements that are not traceable down to the database design, we must ask if the business needs will be met by this architecture. On the other hand, it there are database-design elements that do not trace back to business requirements, we might ask if we have included unnecessary design at the database level
- 18. How Zachman Taxonomy can help DreamKart - Summary •Five ways Zachman Taxonomy can help: – Ensure that every stakeholder's perspective has been considered for every descriptive focal point – Improve the DreamKart Enterprise Architecture artifacts themselves by sharpening each of their focus points to one particular concern for one particular audience – Ensure that all of CxO’s business requirements can be traced down to some technical implementation – Convince Business function of the organization that the technical team isn't planning on building a bunch of useless functionality – Convince Technology team that the business folks are including IT teams in their planning
- 19. What Zachman Taxonomy does not provide • Does not provide step-by-step process to create new architecture •Does not provide much help in validating an architecture • Does not provide help in deciding future architecture • Inference: Zachman alone would not be sufficient to meet DreamKart’s challenges
- 20. TOGAF • Developed and owned by The Open Group • Divides enterprise architecture into four categories: –Business Architecture: describes the processes the business uses to meet its goals – Application Architecture: describes how specific applications are designed and how they interacts with each other – Data Architecture: describes how enterprise data stores are organized and accessed – Technical Architecture: describes the hardware and software infrastructure that supports applications and their interactions • Although TOGAF claims itself to be a framework, the most important part of TOGAF is known as Architecture Development Method (ADM) which is an architecture development process – Since ADM is the most visible part of TOGAF, I categorize (and many in the industry as well) it as architecture process • TOGAF compliments Zachman – Zachman tells how to categorize architecture artifacts – TOGAF gives the process to create them
- 21. TOGAF Description (1) • TOGAF views the world of enterprise architecture as a continuum of architectures, ranging from highly generic to highly specific. • It calls this continuum the Enterprise Continuum. •It views the process of creating a specific enterprise architecture as moving from the generic to the specific. • TOGAF's ADM provides a process for driving this movement from the generic to the specific • TOGAF calls most generic architectures Foundation Architectures. – These are architectural principles that can, theoretically, be used by any IT organization in the universe. • TOGAF calls the next level of specificity Common Systems Architectures. These are principles that one would expect to see in many—but, perhaps, not all—types of enterprises • TOGAF calls the next level of specificity Industry Architectures. These are principles that are specific across many enterprises that are part of the same domain
- 22. TOGAF Description (2) • TOGAF calls the most specific level the Organizational Architectures. These are the architectures that are specific to a given enterprise • TOGAF defines the various knowledge bases that live in the Foundation Architecture. –Technical Reference Model (TRM) – Standards Information Base (SIB) • The TRM is a suggested description of a generic IT architecture. • The SIB is a collection of standards and pseudo-standards that The Open Group recommends that you consider in building an IT architecture • A point of debate – Many in the industry thinks that both the TRM and the SIB are flawed. They are biased toward application portability, at the expense of application interoperability and application autonomy.
- 23.
- 24. TOGAF ADM Processes The TOGAF ArchitectureDevelopment Method (ADM) provides a tested and repeatable process for developing architectures. Source: The Open Group
- 25. How TOGAF can be used to help DreamKart (1) • DreamKartassigned one experienced TOGAF Architect to lead the assignment • In the Preliminary Phase, she meets with the major players at DreamKart to introduce the TOGAF process Her three goals in the preliminary phase are to: – Make sure everybody is comfortable with the process – Modify the TOGAF process, as necessary, to fit within the DreamKart culture – Set up the governance system that will oversee future architectural work at DreamKart • She will work closely with CxOs to understand the business philosophy, business models, and strategic drivers of DreamKart. • She will work closely with the IT team to define the architectural principles that drive technological architectures at DreamKart and document those principles using the TOGAF-recommended format • As soon as the Request for Architecture Work (or some equivalent) has been received, the TOGAF consultant starts working on Phase A
- 26. How TOGAF can be used to help DreamKart (2) • In Phase A, she will ensure that: –the project has the necessary support within DreamKart – define the scope of the project – identify constraints – document the business requirements – establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture • The culmination of Phase A will be a Statement of Architecture Work, which must be approved by the various stakeholders before the next phase of the ADM begins. • The output of this phase is to create an architectural vision for the first pass through the ADM cycle • The TOGAF Architect will guide DreamKart in: – choosing the project, – validating the project against the architectural principles established in the Preliminary Phase – ensure that the appropriate stakeholders have been identified and their issues have been addressed
- 27. How TOGAF can be used to help DreamKart (3) • The Architectural Vision created in Phase A will be the main input into Phase B •The Architect’s goal in Phase B is to create a detailed baseline and target business architecture and perform a full analysis of the gaps between them. – She will work primarily with Business Owners to achieve this. • Phase B is quite involved. It involves: – business modeling, – highly detailed business analysis – technical-requirements documentation • A successful Phase B requires input from many stakeholders. – The major outputs will be a detailed description of the baseline and target business objectives, and gap descriptions of the business architecture
- 28. How TOGAF can be used to help DreamKart (4) • Phase Cdoes for the information-systems architecture what Phase B does for the business architecture • In this phase, the Architect works primarily with the IT Team. TOGAF defines nine specific steps, each with multiple sub-steps: – Develop baseline data-architecture description – Review and validate principles, reference models, viewpoints, and tools – Create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations – Select data-architecture building blocks – Conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders – Review qualitative criteria (for example, performance, reliability, security, integrity) – Complete data architecture – Conduct checkpoint/impact analysis – Perform gap analysis • The most important deliverable from this phase will be the Target Information and Applications Architecture. • Phase D completes the technical architecture—the infrastructure necessary to support the proposed new architecture.
- 29. How TOGAF can be used to help DreamKart (5) • Phase Eevaluates – the various implementation possibilities – identifies the major implementation projects that might be undertaken – evaluates the business opportunity associated with each • The TOGAF standard recommends that the Architect’s first pass at Phase E "focus on projects that will deliver short-term payoffs and so create an impetus for proceeding with longer-term projects.“ • In Phase F, the Architect works with DreamKart governance body to sort the projects identified in Phase E into priority order that include not only the cost and benefits (identified in Phase E), but also the risk factors • In Phase G, the Architect takes the prioritized list of projects and creates architectural specifications for the implementation projects. These specifications will include acceptance criteria and lists of risks and issues • The final Phase is H. In this phase, Teri modifies the architectural change- management process with any new artifacts created in this last iteration and with new information that becomes available
- 30. Challenges of TOGAF • Much of the results of the TOGAF process will be determined as much by the Architect/DreamKart relationship as it will by the TOGAF specification itself. TOGAF is meant to be highly adaptable, and details for the various architectural artifacts is sparse •TOGAF allows phases to be done incompletely, skipped, combined, reordered, or reshaped to fit the needs of the situation. So, it should be no surprise if two different Architects end up using two very different processes—even when working with the same organization. • TOGAF is even more flexible about the actual generated architecture – TOGAF is, to a surprising degree, "architecture-agnostic“ – The final architecture might be good, bad, or indifferent – TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture – For this, you are dependent on the experience of your staff and/or TOGAF consultant – People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely disappointed (as they will be with any of the methodologies)
- 31. Comparison of the EA approaches Criteria Zachman TOGAF Taxonomy Completeness4 2 Process Completeness 1 4 Reference Model Guidance 1 3 Practice Guidance 1 2 Maturity Model 1 1 Business Focus 1 2 Governance Guidance 1 2 Partitioning Guidance 1 2 Prescriptive Catalog 1 2 Vendor Neutrality 2 4 Information Availability 2 4 Time to Value 1 3 Assuming, all criteria have same weightage, the weighted average scores are: Zachman: 1.41 TOGAF: 2.58
- 32.
- 33. Enterprise Security Architecture • Enterprise informationsecurity architecture (EISA) is a part of enterprise architecture focusing on information security throughout the enterprise • The name implies a difference that may not exist between small/medium-sized businesses and larger organizations Source: Wikipedia
- 34. Cyber Security Frameworks • A Cyber Security Frameworkis a risk-based compilation of guidelines designed to help organizations assess current capabilities and draft a prioritized roadmap toward improved cybersecurity practices Source: NIST
- 35. Well Known Cyber Security Frameworks • ISO/IEC 27001 & 27002 (formerly ISO 17799) • NIST SP 800-53: Security and Privacy Controls for Federal Information Systems and Organizations •Sherwood Applied Business Security Architecture (SABSA) • NIST SP 800-39: Risk Management Framework • Security in Major IT Management Frameworks
- 36. Sherwood Applied Business Security Architecture (SABSA) SABSA Model The SABSAModel comprises six layers. It is based on the well-known Zachman framework1 for developing model for enterprise architecture, although it has been adapted somewhat to a security view of the world.
- 37. SABSA Model • Comprises of six layers • Based on Zachmanframework/taxonomy • The Security Service Management Architecture has been placed vertically across the other five layers – Security management issues arises in every horizontal layer • Each horizontal layers are made of a series of vertical communication interrogatives – What (Assets) – Why (Motivation) – How (Process and Technology) – Who (People) – Where (Location) – When (Time)
- 38.
- 39. SABSA Lifecycle • Strategy and Planning • Design •Implement • Manage and Measure
- 40. SABSA Business Attribute Profile • Business Attribute Profile is at the heart of SABSA • It is the artifact that link security architecture with requirement engineering •This is also the linkage between enterprise architecture like TOGAF and SABSA • Each SABSA Business Attribute is an abstraction of real-life business requirements created from years of business consulting knowledgebase • Each SABSA Business Attribute in the taxonomy has detailed definition and guideline metric for their selection • A Business Attribute Profile is built by the architects – using the taxonomy as a guideline to select the relevant attributes for the business case in hand – redefining each selected attribute in terms of the business case – developing a measurement approach, specific metrics and performance targets related to the business case – adding new attributes and new definitions as required to fulfil the business requirements in the specific case in hand • The Manage & Measure activity in the SABSA Lifecycle is based upon the SABSA Business Attribute Profile – that was set out during the Strategy & Planning activity, – which has been customized specifically to conceptualize the business of this unique organization
- 42.
- 43. Contextual Architecture Development Process • Gather, Assesses and Analyze Business Requirements and Current State – Strategy, Drivers, Goals, CSF, Motivations and Risks –Business Processes and Functions – People and Organization – Location and Time dependencies – Budgets and Constraints – Technology Infrastructure – Service and Systems Management, Management Processes – Security Policy and Practices – Deliverable: Working Document • Use Business Attribute List as a prompt to state key Business Drivers – Input: Business Attribute Database – Deliverables: Business Model • Extract other requirements – Assess, analyze and collate to create a set of output artifacts – Deliverables: Business Process Model, Organization and Relationship Model, Business Geography Model, Time Dependency Model • Analyze Business Risk – Assets in the form of Business Attributes with enterprise specific description – Threat (prompted by Threat Database) – Impacts (prompted by business knowledge) – Technical Vulnerabilities, Procedural Vulnerabilities – Deliverables: Business Risk Model
- 44. • Define Business Attributes Profiles – Select Business Attributes mapped to Business Drivers –Define enterprise specific business attributes, measurement approach, metrics and performance targets – Input: Business Attribute Database – Deliverables: Business Attribute Profile • Derive Control Objectives from Business Risk Model and Business Attribute Profile – Deliverables: Updated Business Risk Model with Control Objectives • Assess Current State of Security against Business Risk Model and Control Objectives – Deliverables: Enterprise Security Posture Analysis Document • Derive Conceptual Domain Model – Deliverables: Security Domain Model Conceptual Architecture Development Process (1)
- 45. • Derive Conceptual Time Model – Deliverables: Security related Lifetime and Deadlines •Derive Trust Model – Entities (Internal and External) – Trust Relationship – Deliverables: Security Entity Model and Trust Framework • Derive Major Security Strategies – Mapped to Control Objectives and Business Attribute Profile – Deliverables: Security Strategy Conceptual Architecture Development Process (2) Get Sign-off and Buy-in to Conceptual Architecture
- 46. How Strategy and Concept phase fits together WHAT? Business Driver WHY? CSF WHEN? Time HOW? Function WHO? People WHERE? Location Assets Risks CriticalityDependency Responsibility Logistics Attributes Profile Control Objectives Time Model Trust Model Domain Model Security Strategy Critical Business Processes and Models CONTEXTUAL LAYER CONCEPTUAL LAYER
- 47. Logical Security Architecture Development Process • Define Security Policy Architecture – Deliverables: Security Policy Architecture •Perform Policy Gap Analysis – Use posture analysis artifact • Define Security Policies – Deliverables: Security Policies • Define Security Services bases on Policies, Strategies and Control Objectives – Deliverables: Logical Security Services • Define Entity Schema and Privilege Profiles – Deliverables: Entity Schema and Privilege Profiles • Define Security Domains and Association – Deliverables: Security Domains and Association • Define Security Processing Cycle – Deliverables: Security Processing Cycle • Perform Services Gap Analysis – Deliverables: SIP Get Sign-off and Buy-in to SIP
- 48. Physical Security Architecture Development Process • Review Business Data Model – Input: Pre-existing business data model •Define Security Data – Deliverables: Business Data Model updated with Security Data • Define Security Rules, Practice and Procedures – Deliverables: Security Rules, Practices and Procedures • Define Security Mechanism – Based on Policies, Rules, Practices, Strategies and Security Services – Deliverables: Security Mechanisms • Define Applications, User Communities and Design Security User Interface for each application – Deliverables: Users, Applications and the User Interface for Security • Define Platform and Network Infrastructure – Deliverables: Platform and Network Infrastructure Physical Layout • Define Capacity and Resilience Requirements – Using Business Attribute Profile – Deliverables: Platform and Network Infrastructure Capacity Plan and Resilience Model
- 49. Component Security Architecture Development Process • Define Syntax of Security Data Structure – Input: Data Dictionary –Deliverables: Detailed Security Data Structure • Define Security Standard – Deliverables: Security Standards • Select Security Products and Tools – Input: Product Marketing Information – Deliverables: Security Products and Tools • Define Detailed Access Rights for Users and Application Entities – Deliverables: Identities, ACL, Actions • Define Details of Infrastructure – Deliverables: Processes, Nodes, Addresses and Protocols • Define Capacity and Resiliency Requirements using Business Attribute Profile – Deliverables: Security Step Timing and Sequencing
- 50. Operations Security Architecture Development Process • Develop Framework for Assurance and Operational Continuity – Deliverables: Framework for Assurance and Operational Continuity •Develop Operational Risk Management Framework – Deliverables: Operational Risk Management Framework • Develop Security Service Management and Support Framework – Deliverables: Security Service Management and Support Framework • Develop User Management and Support Framework – Deliverables: User Management and Support Framework • Develop Security Management Frameworks for Sites, Networks and Applications – Deliverables: Security Management Framework • Develop Security Operations Schedule – Deliverables: Framework for Managing Security Operations Schedule
- 51.
- 52.
- 53.