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
Arnab	Chattopadhayay
Senior	Director
MetricStream	Inc.
Enterprise	Architecture
• A	field	born	about	30	years	ago
• Initially	targeted	to	address	two	problems
– System	complexity...
Enterprise	Architectural	Methodologies
• Consortia-developed	Frameworks
– ISO	19439
– RM-ODP	(ITU-T	X.901-904)
– TOGAF
• D...
A	Brief	History	of	Enterprise	Architecture
Zacman’s first	article
1987
TAFIM	released
1994
Clinger-Cohen	bill	passed
1996 ...
Enterprise	Security	Architecture	Evolution
Ref:	Wikipedia
Focus	for	today’s	presentation
• Zachman Framework	for	Enterprise	
Architectures
• TOGAF
How	are	we	going	to	discuss
• Each	approach	would	be	described	in	the	context	of	
the	following	real-life	problems	of	a	fi...
Enterprise	Architecture	Approaches	Comparison	Metric	
(1)
• Taxonomy	completeness	(how	well	you	can	use	the	methodology	to...
Enterprise	Architecture	Approaches	Comparison	Metric	
(2)
• Governance	guidance	(how	much	help	the	methodology	will	be	in	...
Case	Study
• DreamKart is	an	eCommerce company	selling	wide	
range	of	products	to	retail	market
• It	has	the	following	sys...
Challenges
• DreamKart requires	regional	specializations.	For	example,	different	offers	
and	product	ranges	are	needed	to	...
Zachman Framework (1)
• Although	the	name	states,	it	isn’t	a	‘Framework’	in	true	sense
– A	framework	is	defined	as	a	struc...
Zachman Framework (2)
• Two	dimensions
– Players	in	the	game
– Architectural	Artifacts
• Players	in	the	game:	Actors
• Arc...
Zachman Framework (3)
• Zachman Framework	is	typically	depicted	as	a	6	x	6	matrix
– Columns:	Communication	Interrogatives	...
Zachman Framework	(4)
Source:	zachmaninternational.com
How	Zachman Taxonomy	can	help	DreamKart (1)	
• Three suggestions
• First:	use	Zachman Taxonomy	to	the	fact	that	every	arch...
How	Zachman Taxonomy	can	help	DreamKart (2)	
• Third:	cells	in	columns	should	be	related	to	each	other.
– Example:take	the...
How	Zachman Taxonomy	can	help	DreamKart -
Summary
• Five	ways	Zachman Taxonomy	can	help:
– Ensure	that	every	stakeholder's...
What	Zachman Taxonomy	does	not	
provide
• Does	not	provide	step-by-step	process	to	create	new	
architecture
• Does	not	pro...
TOGAF
• Developed	and	owned	by	The	Open	Group
• Divides	enterprise	architecture	into	four	categories:
– Business	Architect...
TOGAF	Description	(1)
• TOGAF	views	the	world	of	enterprise	architecture	as	a	continuum	of	
architectures,	ranging	from	hi...
TOGAF	Description	(2)
• TOGAF	calls	the	most	specific	level	the	Organizational	
Architectures.	These	are	the	architectures...
TOGAF	Enterprise	Continuum
TOGAF	ADM	Processes
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for
developin...
How	TOGAF	can	be	used	to	help	DreamKart (1)
• DreamKart assigned	one	experienced	TOGAF	Architect	to	lead	the	
assignment
•...
How	TOGAF	can	be	used	to	help	DreamKart (2)
• In	Phase	A,	she	will	ensure	that:
– the	project	has	the	necessary	support	wi...
How	TOGAF	can	be	used	to	help	DreamKart (3)
• The	Architectural	Vision	created	in	Phase	A	will	be	the	main	
input	into	Pha...
How	TOGAF	can	be	used	to	help	DreamKart (4)
• Phase	C does	for	the	information-systems	architecture	what	Phase	B	does	
for...
How	TOGAF	can	be	used	to	help	DreamKart (5)
• Phase	E evaluates	
– the	various	implementation	possibilities
– identifies	t...
Challenges	of	TOGAF
• Much	of	the	results	of	the	TOGAF	process	will	be	determined	as	much	by	
the	Architect/DreamKart rela...
Comparison	of	the	EA	approaches
Criteria Zachman TOGAF
Taxonomy	Completeness 4 2
Process	Completeness 1 4
Reference	Model	...
So,	the	Winner	for	DreamKart is
• TOGAF
Enterprise	Security	Architecture
• Enterprise information security	
architecture (EISA)	is	a	part	of enterprise	
architect...
Cyber	Security	Frameworks
• A	Cyber	Security Framework is	a	risk-based	
compilation	of	guidelines	designed	to	help	
organi...
Well	Known	Cyber	Security	
Frameworks
• ISO/IEC	27001	&	27002	(formerly	ISO	17799)
• NIST	SP	800-53:	Security	and	Privacy	...
Sherwood	Applied	Business	Security	Architecture	
(SABSA)
SABSA Model
The SABSA Model comprises six layers. It is based on ...
SABSA	Model
• Comprises	of	six	layers
• Based	on	Zachman framework/taxonomy
• The	Security	Service	Management	Architecture...
Source:	sabsa.org
SABSA	Lifecycle
• Strategy	and	Planning
• Design
• Implement
• Manage	and	Measure
SABSA	Business	Attribute	Profile
• Business	Attribute	Profile	is	at	the	heart	of	SABSA
• It	is	the	artifact	that	link	secu...
Using	SABSA
Define	
Contextual	
Security	
Architecture
Define	
Conceptual	
Security	
Architecture
Define	Logical	
Security...
Contextual	Architecture	Development	Process
• Gather,	Assesses	and	Analyze	Business	Requirements	and	Current	State
– Strat...
• Define	Business	Attributes	Profiles
– Select	Business	Attributes	mapped	to	Business	Drivers
– Define	enterprise	specific...
• Derive	Conceptual	Time	Model
– Deliverables:	Security	related	Lifetime	and	Deadlines
• Derive	Trust	Model
– Entities	(In...
How	Strategy	and	Concept	phase	fits	together
WHAT?
Business	
Driver
WHY?
CSF
WHEN?
Time
HOW?
Function
WHO?
People
WHERE?
L...
Logical	Security	Architecture	Development	Process
• Define	Security	Policy	Architecture
– Deliverables:	Security	Policy	Ar...
Physical	Security	Architecture	Development	Process
• Review	Business	Data	Model
– Input:	Pre-existing	business	data	model
...
Component	Security	Architecture	Development	Process
• Define	Syntax	of	Security	Data	Structure
– Input:	Data	Dictionary
– ...
Operations	Security	Architecture	Development	Process
• Develop	Framework	for	Assurance	and	Operational	Continuity
– Delive...
Bringing	All	Together
Business	Strategy
Goals
Relatio
nship
Market
Regula
tion
People
Materi
als
Financ
e
Produc
tion
Logi...
How	SABSA	can	be	integrated	with	TOGAF
Thank	You
Enterprise Security Architecture
Upcoming SlideShare
Loading in …5
×

Enterprise Security Architecture

5,077 views

Published on

Enterprise Architecture
Enterprise Architectural Methodologies
History of Enterprise Architecture
Zachman Frameworks,Taxonomy.



Published in: Technology

Enterprise Security Architecture

  1. 1. Enterprise Security Architecture Arnab Chattopadhayay Senior Director MetricStream Inc.
  2. 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. 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. 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 1999 2002 FEA replaces FEAF TOGAF EE 8.0 released 2003 2003 FEA mostly complete 2011 TOGAF 9.1
  5. 5. Enterprise Security Architecture Evolution Ref: Wikipedia
  6. 6. Focus for today’s presentation • Zachman Framework for Enterprise Architectures • TOGAF
  7. 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. 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. 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. 10. Case Study • DreamKart is an eCommerce company 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. 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. 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. 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. 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. 15. Zachman Framework (4) Source: zachmaninternational.com
  16. 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. 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. 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. 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. 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. 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. 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. 23. TOGAF Enterprise Continuum
  24. 24. TOGAF ADM Processes The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. Source: The Open Group
  25. 25. How TOGAF can be used to help DreamKart (1) • DreamKart assigned 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. 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. 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. 28. How TOGAF can be used to help DreamKart (4) • Phase C does 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. 29. How TOGAF can be used to help DreamKart (5) • Phase E evaluates – 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. 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. 31. Comparison of the EA approaches Criteria Zachman TOGAF Taxonomy Completeness 4 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. 32. So, the Winner for DreamKart is • TOGAF
  33. 33. Enterprise Security Architecture • Enterprise information security 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. 34. Cyber Security Frameworks • A Cyber Security Framework is 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. 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. 36. Sherwood Applied Business Security Architecture (SABSA) SABSA Model The SABSA Model 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. 37. 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 – 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. 38. Source: sabsa.org
  39. 39. SABSA Lifecycle • Strategy and Planning • Design • Implement • Manage and Measure
  40. 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
  41. 41. Using SABSA Define Contextual Security Architecture Define Conceptual Security Architecture Define Logical Security Architecture Define Physical Security Architecture Define Component Security Architecture Define Operational Security Architecture
  42. 42. 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
  43. 43. • 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)
  44. 44. • 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
  45. 45. How Strategy and Concept phase fits together WHAT? Business Driver WHY? CSF WHEN? Time HOW? Function WHO? People WHERE? Location Assets Risks Criticality Dependency Responsibility Logistics Attributes Profile Control Objectives Time Model Trust Model Domain Model Security Strategy Critical Business Processes and Models CONTEXTUAL LAYER CONCEPTUAL LAYER
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. Bringing All Together Business Strategy Goals Relatio nship Market Regula tion People Materi als Financ e Produc tion Logisti cs BAP Risk Model Trust Model Security Strategy Process Design Policy & Legal Framework Technical Design Logical Security Services Confidentiality Identification Registration Certification Directories Authentication Authorization Access Control Audit Trail Physical Security Mechanism Encryption Naming Procedures Signatures Databases Passwords ACLs Firewalls Event Logs Components Trusted Business Operations ProductsTools
  51. 51. How SABSA can be integrated with TOGAF
  52. 52. Thank You

×