Enterprise Information Security Architecture (EISA) - Revision history

User at 10:56, 16 July 2023

2023-07-16T10:56:24Z

User at 19:34, 4 January 2023

2023-01-04T19:34:22Z

Show changes

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T15:42:50Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

Show changes

User at 19:53, 26 March 2020

2020-03-26T19:53:32Z

User at 19:52, 26 March 2020

2020-03-26T19:52:05Z

User at 22:21, 5 December 2019

2019-12-05T22:21:11Z

User at 22:20, 5 December 2019

2019-12-05T22:20:24Z

User at 22:19, 5 December 2019

2019-12-05T22:19:49Z

User at 21:21, 5 December 2019

2019-12-05T21:21:23Z

User at 21:08, 5 December 2019

2019-12-05T21:08:06Z

← Older revision		Revision as of 10:56, 16 July 2023
Line 17:		Line 17:
	[[File:EISA.png\|550px\|Dimensions of EISA Framework]]		[[File:EISA.png\|550px\|Dimensions of EISA Framework]]

−	The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines. Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.	+	The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines. Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the [[Enterprise Architecture\|enterprise architecture]], allowing further changes to be integrated easily.

← Older revision		Revision as of 19:53, 26 March 2020
Line 8:		Line 8:

	This framework goes into many levels of detail that vary according to practical considerations such as budget. This allows decision makers to make the most informed decisions about where to invest their resources and where to align organizational goals and processes to support core missions or business functions.		This framework goes into many levels of detail that vary according to practical considerations such as budget. This allows decision makers to make the most informed decisions about where to invest their resources and where to align organizational goals and processes to support core missions or business functions.
		+

	'''The Structure and Content of an EISA Framework'''<br />		'''The Structure and Content of an EISA Framework'''<br />

@@ Line 1: / Line 1: @@
-'''Enterprise Information Security Architecture (EISA)''' is the process of instituting a complete information security solution to the architecture of an enterprise, ensuring the security of business information at every point in the architecture. In other words, it is the enterprise and its activities that are to be secured, and the security of computers and networks is only a means to this end.<ref>Defining Enterprise Information Security Architecture (EISA) [https://pdfs.semanticscholar.org/4053/e1dc0fc5dac4d1e612b51ebab67e399ff351.pdf Daniel K. Sigei]</ref>
+'''Enterprise Information Security Architecture (EISA)''' is the process of instituting a complete [[Information Security|information security]] solution to the [[Enterprise Architecture|architecture of an enterprise]], ensuring the security of business information at every point in the architecture. In other words, it is the enterprise and its activities that are to be secured, and the security of computers and networks is only a means to this end.<ref>Defining Enterprise Information Security Architecture (EISA) [https://pdfs.semanticscholar.org/4053/e1dc0fc5dac4d1e612b51ebab67e399ff351.pdf Daniel K. Sigei]</ref>
@@ Line 16: / Line 16: @@
 [[File:EISA.png|550px|Dimensions of EISA Framework]]
-The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines.  Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.
+The EISA should describe how security is woven into the fabric of the [[Business|business]]. The EISA process must allow inputs from and interface points with design components from other planning disciplines.  Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.
@@ Line 66: / Line 66: @@
 Wherever possible, all of the above should be related explicitly to the organization's strategy, goals, and operations. The enterprise information security architecture will document the current state of the technical security components listed above, as well as an ideal-world desired future state (Reference Architecture) and finally a "Target" future state which is the result of engineering tradeoffs and compromises vs. the ideal. Essentially the result is a nested and interrelated set of models, usually managed and maintained with specialised software available on the market.
-Such exhaustive mapping of IT dependencies has notable overlaps with both metadata in the general IT sense, and with the ITIL concept of the configuration management database. Maintaining the accuracy of such data can be a significant challenge.
+Such exhaustive mapping of IT dependencies has notable overlaps with both [[Metadata|metadata]] in the general IT sense, and with the [[ITIL (Information Technology Infrastructure Library)|ITIL]] concept of the configuration management [[Database (DB)|database]]. Maintaining the accuracy of such data can be a significant challenge.
 Along with the models and diagrams goes a set of best practices aimed at securing adaptability, scalability, manageability etc. These systems engineering best practices are not unique to enterprise information security architecture but are essential to its success nonetheless. They involve such things as componentization, asynchronous communication between major components, standardization of key identifiers and so on.
-Successful application of enterprise information security architecture requires appropriate positioning in the organization. The analogy of city-planning is often invoked in this connection, and is instructive.
+Successful application of enterprise information security architecture requires appropriate positioning in the [[Organization|organization]]. The analogy of city-planning is often invoked in this connection, and is instructive.
 An intermediate outcome of an architecture process is a comprehensive inventory of business security strategy, business security processes, organizational charts, technical security inventories, system and interface diagrams, and network topologies, and the explicit relationships between them. The inventories and diagrams are merely tools that support decision making. But this is not sufficient. It must be a living process.

← Older revision		Revision as of 22:21, 5 December 2019
Line 24:		Line 24:


−	[[File:BITS.jpg\|~~400px~~\|One-dimensional view of Enterprise Architecture]]<br />	+	[[File:BITS.jpg\|300px\|One-dimensional view of Enterprise Architecture]]<br />
	source: Wikipedia		source: Wikipedia

← Older revision		Revision as of 22:20, 5 December 2019
Line 24:		Line 24:


−	[[File:BITS.jpg\|~~200px~~\|One-dimensional view of Enterprise Architecture]]<br />	+	[[File:BITS.jpg\|400px\|One-dimensional view of Enterprise Architecture]]<br />
	source: Wikipedia		source: Wikipedia

@@ Line 18: / Line 18: @@
 The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines.  Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.
 Enterprise Information Security Architecture Topics<ref>Enterprise Information Security Architecture Topics [https://en.wikipedia.org/wiki/Enterprise_information_security_architecture Wikipedia]</ref>
-*Positioning
+'''Enterprise Information Security Architecture Topics<ref>Enterprise Information Security Architecture Topics [https://en.wikipedia.org/wiki/Enterprise_information_security_architecture Wikipedia]</ref>'''
 Enterprise information security architecture was first formally positioned by Gartner in their whitepaper called “Incorporating Security into the Enterprise Architecture Process”. This was published on 24 January 2006. Since this publication, [[Security Architecture|security architecture]] has moved from being a silo based architecture to an enterprise focused solution that incorporates business, information and technology. The picture below represents a one-dimensional view of enterprise architecture as a [[Service Oriented Architecture (SOA)|service-oriented architecture]]. It also reflects the new addition to the [[Enterprise Architecture|enterprise architecture]] family called “Security”. [[Business Architecture|Business architecture]], [[Information Architecture|information architecture]] and [[Information Technology Architecture|technology architecture]] used to be called BIT for short. Now with security as part of the architecture family it has become BITS.
@@ Line 28: / Line 29: @@
 Security architectural change imperatives now include things like
-Business roadmaps
+*'''Goals'''
-Legislative and legal requirements
+**Provide structure, coherence and cohesiveness.
-Technology roadmaps
+**Must enable business-to-security alignment.
-Industry trends
+**Defined top-down beginning with business strategy.
-Risk trends
+**Ensure that all models and implementations can be traced back to the business strategy, specific business requirements and key principles.
-Visionaries
+**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.
-Goals
+**Establish a common "language" for information security within the organization
-Given these descriptions, whose levels of detail will vary according to affordability and other practical considerations, decision makers are provided the means to make informed decisions about where to invest resources, where to realign organizational goals and processes, and what policies and procedures will support core missions or business functions.
+*'''Methodology'''
 A strong enterprise information security architecture process helps to answer basic questions like:
 Wherever possible, all of the above should be related explicitly to the organization's strategy, goals, and operations. The enterprise information security architecture will document the current state of the technical security components listed above, as well as an ideal-world desired future state (Reference Architecture) and finally a "Target" future state which is the result of engineering tradeoffs and compromises vs. the ideal. Essentially the result is a nested and interrelated set of models, usually managed and maintained with specialised software available on the market.
 Such exhaustive mapping of IT dependencies has notable overlaps with both metadata in the general IT sense, and with the ITIL concept of the configuration management database. Maintaining the accuracy of such data can be a significant challenge.
 Along with the models and diagrams goes a set of best practices aimed at securing adaptability, scalability, manageability etc. These systems engineering best practices are not unique to enterprise information security architecture but are essential to its success nonetheless. They involve such things as componentization, asynchronous communication between major components, standardization of key identifiers and so on.
@@ Line 77: / Line 74: @@
 The organization must design and implement a process that ensures continual movement from the current state to the future state. The future state will generally be a combination of one or more
+*Closing gaps that are present between the current organization strategy and the ability of the IT security dimensions to support it
-Closing gaps that are present between the current organization strategy and the ability of the IT security dimensions to support it
+*Closing gaps that are present between the desired future organization strategy and the ability of the security dimensions to support it
-Closing gaps that are present between the desired future organization strategy and the ability of the security dimensions to support it
+*Necessary upgrades and replacements that must be made to the IT security architecture based on supplier viability, age and performance of hardware and software, capacity issues, known or anticipated regulatory requirements, and other issues not driven explicitly by the organization's functional management.
-Necessary upgrades and replacements that must be made to the IT security architecture based on supplier viability, age and performance of hardware and software, capacity issues, known or anticipated regulatory requirements, and other issues not driven explicitly by the organization's functional management.
+*On a regular basis, the current state and future state are redefined to account for evolution of the architecture, changes in organizational strategy, and purely external factors such as changes in technology and customer/vendor/government requirements, and changes to both internal and external threat landscapes over time.

← Older revision		Revision as of 21:21, 5 December 2019
Line 17:		Line 17:

	The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines. Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.		The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines. Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.
		+
		+	Enterprise Information Security Architecture Topics<ref>Enterprise Information Security Architecture Topics [https://en.wikipedia.org/wiki/Enterprise_information_security_architecture Wikipedia]</ref>
		+	*Positioning
		+	Enterprise information security architecture was first formally positioned by Gartner in their whitepaper called “Incorporating Security into the Enterprise Architecture Process”. This was published on 24 January 2006. Since this publication, [[Security Architecture\|security architecture]] has moved from being a silo based architecture to an enterprise focused solution that incorporates business, information and technology. The picture below represents a one-dimensional view of enterprise architecture as a [[Service Oriented Architecture (SOA)\|service-oriented architecture]]. It also reflects the new addition to the [[Enterprise Architecture\|enterprise architecture]] family called “Security”. [[Business Architecture\|Business architecture]], [[Information Architecture\|information architecture]] and [[Information Technology Architecture\|technology architecture]] used to be called BIT for short. Now with security as part of the architecture family it has become BITS.
		+
		+
		+	[[File:BITS.jpg\|200px\|One-dimensional view of Enterprise Architecture]]<br />
		+	source: Wikipedia
		+
		+
		+	Security architectural change imperatives now include things like
		+
		+	Business roadmaps
		+	Legislative and legal requirements
		+	Technology roadmaps
		+	Industry trends
		+	Risk trends
		+	Visionaries
		+	Goals
		+	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
		+	Methodology
		+	The practice of enterprise information security architecture involves developing an architecture security framework to describe a series of "current", "intermediate" and "target" reference architectures and applying them to align programs of change. These frameworks detail the organizations, roles, entities and relationships that exist or should exist to perform a set of business processes. This framework will provide a rigorous taxonomy and ontology that clearly identifies what processes a business performs and detailed information about how those processes are executed and secured. The end product is a set of artifacts that describe in varying degrees of detail exactly what and how a business operates and what security controls are required. These artifacts are often graphical.
		+
		+	Given these descriptions, whose levels of detail will vary according to affordability and other practical considerations, decision makers are provided the means to make informed decisions about where to invest resources, where to realign organizational goals and processes, and what policies and procedures will support core missions or business functions.
		+
		+	A strong enterprise information security architecture process helps to answer basic questions like:
		+
		+	What is the information security risk posture of the organization?
		+	Is the current architecture supporting and adding value to the security of the organization?
		+	How might a security architecture be modified so that it adds more value to the organization?
		+	Based on what we know about what the organization wants to accomplish in the future, will the current security architecture support or hinder that?
		+	Implementing enterprise information security architecture generally starts with documenting the organization's strategy and other necessary details such as where and how it operates. The process then cascades down to documenting discrete core competencies, business processes, and how the organization interacts with itself and with external parties such as customers, suppliers, and government entities.
		+
		+	Having documented the organization's strategy and structure, the architecture process then flows down into the discrete information technology components such as:
		+
		+	Organization charts, activities, and process flows of how the IT Organization operates
		+	Organization cycles, periods and timing
		+	Suppliers of technology hardware, software, and services
		+	Applications and software inventories and diagrams
		+	Interfaces between applications - that is: events, messages and data flows
		+	Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
		+	Data classifications, Databases and supporting data models
		+	Hardware, platforms, hosting: servers, network components and security devices and where they are kept
		+	Local and wide area networks, Internet connectivity diagrams
		+	Wherever possible, all of the above should be related explicitly to the organization's strategy, goals, and operations. The enterprise information security architecture will document the current state of the technical security components listed above, as well as an ideal-world desired future state (Reference Architecture) and finally a "Target" future state which is the result of engineering tradeoffs and compromises vs. the ideal. Essentially the result is a nested and interrelated set of models, usually managed and maintained with specialised software available on the market.
		+
		+	Such exhaustive mapping of IT dependencies has notable overlaps with both metadata in the general IT sense, and with the ITIL concept of the configuration management database. Maintaining the accuracy of such data can be a significant challenge.
		+
		+	Along with the models and diagrams goes a set of best practices aimed at securing adaptability, scalability, manageability etc. These systems engineering best practices are not unique to enterprise information security architecture but are essential to its success nonetheless. They involve such things as componentization, asynchronous communication between major components, standardization of key identifiers and so on.
		+
		+	Successful application of enterprise information security architecture requires appropriate positioning in the organization. The analogy of city-planning is often invoked in this connection, and is instructive.
		+
		+	An intermediate outcome of an architecture process is a comprehensive inventory of business security strategy, business security processes, organizational charts, technical security inventories, system and interface diagrams, and network topologies, and the explicit relationships between them. The inventories and diagrams are merely tools that support decision making. But this is not sufficient. It must be a living process.
		+
		+	The organization must design and implement a process that ensures continual movement from the current state to the future state. The future state will generally be a combination of one or more
		+
		+	Closing gaps that are present between the current organization strategy and the ability of the IT security dimensions to support it
		+	Closing gaps that are present between the desired future organization strategy and the ability of the security dimensions to support it
		+	Necessary upgrades and replacements that must be made to the IT security architecture based on supplier viability, age and performance of hardware and software, capacity issues, known or anticipated regulatory requirements, and other issues not driven explicitly by the organization's functional management.
		+	On a regular basis, the current state and future state are redefined to account for evolution of the architecture, changes in organizational strategy, and purely external factors such as changes in technology and customer/vendor/government requirements, and changes to both internal and external threat landscapes over time.
		+
		+
		+	== See Also ==
		+	[[Enterprise Architecture\|Enterprise Architecture]]
		+	[[Enterprise_Architecture_Framework\|Enterprise Architecture Framework]]<br />
		+	[[Enterprise_Architecture_Management_(EAM)\|Enterprise Architecture Management (EAM)]]<br />
		+	[[Enterprise_Architecture_Value_Framework_(EAVF)\| Enterprise Architecture Value Framework (EAVF)]]<br />
		+	[[Application_Architecture\|Application Architecture]]<br />
		+	[[Business_Architecture\|Business Architecture]]<br />
		+	[[Architected, Model-Driven Development (AMD)]]<br />
		+	[[Architected Rapid Application Development (ARAD)]]<br />
		+	[[Architectural Pattern\|Architectural Pattern]]<br />
		+	[[Architectural Principles\|Architectural Principles]]<br />
		+	[[Architectural Risk\|Risks in Architecture]]<br />
		+	[[Architectural Style\|Architectural Style]]<br />
		+	[[Architecture Description Language (ADL)\|Architecture Description Language (ADL)]]<br />
		+	[[Architecture Development Method (ADM)\|Architecture Development Method (ADM)]]<br />
		+	[[Architecture Driven Modernization\|Architecture Driven Modernization]]<br />
		+	[[Architecture Tradeoff Analysis Method (ATAM)\|Architecture Tradeoff Analysis Method (ATAM)]]<br />
		+	[[IT_Governance\|IT Governance (Governance of Information Technology)]]<br />
		+	[[Corporate Governance]]<br />
		+	[[Governance]]<br />
		+	[[Governance, Risk And Compliance (GRC)]]<br />
		+	[[Information Architecture]]<br />
		+	[[Security Architecture]]<br />
		+	[[Information Security]]<br />
		+	[[Information Security Governance]]<br />
		+	[[Security Reference Model (SRM)]]<br />
		+	[[Cyber Security]]
		+
		+
		+	=== References ===
		+	<references/>

@@ Line 14: / Line 14: @@
 The three key dimensions of the EISA framework are as follows:
-[[File:EISA.png|400px|Dimensions of EISA Framework]]
+[[File:EISA.png|550px|Dimensions of EISA Framework]]
 The EISA should describe how security is woven into the fabric of the business. The EISA process must allow inputs from and interface points with design components from other planning disciplines.  Then, as the architecture and security processes mature, the EISA can have a more symbiotic relationship with the enterprise architecture, allowing further changes to be integrated easily.