Abstract image of a woman sitting on books and studying on a laptop

Ea Relationship To Security And The Enterprise V1

Download as PPT, PDF
P
pk4

The document discusses different frameworks and methodologies for enterprise architecture (EA) and enterprise security architecture (SA). EA focuses on optimizing business value through mapping business activities, while SA focuses on protecting business assets through a balanced security program. SA goals depend on an organization's risk management culture, which can range from generative to bureaucratic to pathologic. The document provides examples of using the TOGAF and Federal EA frameworks to structure SA.

TechnologyBusiness
1 of 48
Downloaded 97 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Enterprise Security Architecture Prentice Kinser, CISSP-ISSAP caveat emptor : This material is furnished as-is. The author makes no warranties of any kind, including, but not limited to fitness for purpose, merchantability, exclusivity, or freedom from patent, trademark, or copyright infringement. The findings, interpretations, and conclusions expressed herein are those of the author and do not necessarily reflect the views of any employers, past or present. Use of any product names, images, or trademarks in this material is not intended in any way to infringe on the rights of the trademark holder, nor is it intended to positively or negatively endorse any product or solution. Permission is granted for free usage of all or portions of this document, including derived works, provided proper acknowledgement is given.
3 D’s Diplomacy Disclaimer Disclosure
Enterprise Architecture vs. Enterprise Security Architecture EA: Frameworks (Zachman, FEAF, IEEE-1471, etc.) Methodologies (TOGAF, DoDAF, RUP/EUP, FEA, etc.) Goal is to optimize business value from enterprise assets through creation, and then reengineering, of a map of all business activities - their value, cost, and interrelationships SA: Frameworks (SABSA, ISO 17799, etc.) Methodologies (COBIT, AICPA, etc.) Reactionary (Risk Assessment, Audit Response, Incident Management, Regulatory minimalism [panic response to GLBA, HIPAA, FISMA, etc.]) Goal is to provide an appropriately balanced program to protect business assets
Enterprise Architecture vs. Enterprise Security Architecture EA: Goals are stated as return on investment (ROI), net present value (NPV), annual loss expectancy (ALE), etc.
 
Source: Gartner IT Security Summit, Tom Scholtz, 4-6 June 2007, Washington, D.C., “Advanced Security Architecture Practice”
Enterprise Architecture vs. Enterprise Security Architecture SA: Goal stated as … what?
Enterprise Security Architecture Goal = TRUST Source: Gartner IT Security Summit, Jeffrey Wheatman and Paul E. Proctor, 4-6 June 2007, Washington, D.C., “How to Conduct a Risk Assessment: A Play in Three Acts”
Enterprise Security Architecture… Framework? Methodology? Reactionary? Depends on your Risk Management Culture …
Risk Management Culture Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997 Ideas welcomed Ideas beget problems Ideas discouraged Failures beget reforms Local repairs only Failure punished Responsibility shared Compartmentalized Responsibility shirked Messengers rewarded Heard if they arrive Messengers “shot” Actively seek May not find out Don’t want to know Generative Bureaucratic Pathologic
Risk Management Culture Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997 Reactionary Framework Methodology Ideas welcomed Ideas beget problems Ideas discouraged Failures beget reforms Local repairs only Failure punished Responsibility shared Compartmentalized Responsibility shirked Messengers rewarded Heard if they arrive Messengers “shot” Actively seek May not find out Don’t want to know Generative Bureaucratic Pathologic
Enterprise Architecture vs. Enterprise Security Architecture EA: Goal is to optimize business value from business assets through creation, and then reengineering, of a map of all enterprise activities - their value, cost, and interrelationships SA: Goal is to provide an appropriately balanced program to protect all business assets in the enterprise Security Architect must keep a foot in BOTH worlds – can’t create “balance” w/o understanding interrelationships in the broader EA context
HOW TO SCOPE THE SECURITY TARGET ARCHITECTURES?
Framework Approach - Example
Begin decomposition into individual Target Architecture domains: Access Control enables an enterprise to manage WHO has access to WHAT , it is supported with a collection of administration tools for defining the whos, the whats, and the circumstances under which access is granted or denied, and it allows the enterprise to delegate and exercise fiduciary responsibilities, such as substantiating access approvals, demonstrating access enforcement, and detecting cross-functional impacts of policy exceptions.
Access Control Target Architecture domain further decomposed into three parts: Identity Management (the ability to centrally provision and de-provision identities and credentials through workflow and automated processes) Example: Vetting the documentation a person uses to prove their identity, and issuing appropriately configured badges, account ID’s, and access credentials (passwords, tokens, smart cards, etc.). Authentication (the process of validating a claimed identity) Example: Presenting picture ID badge to security guard who validates ID badge against the presenter. Authorization (the set of permissions afforded to an identity) Example: Granting the person access to a building based on a predetermined policy.
Drill down into Tactical and Strategic goals, and include timeframe recommendations: Strategic Goal: All Employees use FIPS201 compliant or compatible smart-cards: 2008: detailed design completed and modifications to policies and procedures finalized 2009: infrastructure build-out completed and new HR procedures implemented 2010: all new employees and a majority of existing employees are issued FIPS compatible identity cards 2011: rollout of FIPS compatible identity cards is complete, and rollout of FIPS compatible PACS is complete Tactical Alternative: two-factor authentication utilizing one-time-password token technology conforming with the NIST SP800-63 standard for Level-3 Assurance (this is primarily to enable rapid elimination of single-factor authentication on platforms that are unable to support cryptographic smart-cards) Identity Management Authentication Authorization
Tactical and Strategic goals (cont.): Strategic Goal: All non-employees utilize smart card technology conforming with one of the following options: FIPS201 compatible technology issued by enterprise or delegated RA FIPS201 compliant technology issued by a federally-recognized entity Federation using FIPS201-style public certificates and CRLs Tactical Alternatives: Vendor-proprietary point-to-point federation assertions (eg. SAML) that are signed using FIPS201-style public certificates and CRLs One-time-password token technology conforming with the NIST SP800-63 standard for Level-3 Assurance Identity Management Authentication Authorization
Tactical and Strategic goals (cont.): Strategic Goal: All users of enterprise resources (irrespective of employer) are tracked using a Universally Unique Identifier (UUID). Each individual person gets one and only one UUID, irrespective of the number of user ID’s, federated identities, or roles held by that individual over their lifetime. End game: Consolidation of Identity Management Systems and Processes will occur, organically and via integration with ITIL and CMDB practices. The new Identity Management paradigm is that everyone is external . Identity Management Authentication Authorization
Tactical and Strategic goals (cont.): Strategic Goal: No more “single-factor” Authentication 2007 system administrator accounts 2008 NOS accounts (Windows, UNIX, Cisco IOS, etc.) 2009 Network Access Control (NAC) 2011 all other interactive systems Identity Management Authentication Authorization
Tactical and Strategic goals (cont.): Identity Management Authentication Authorization Strategic Goal: FIPS201 Tactical Alternatives (some examples): One-Time-Password “Wired” Token w/PIN “Wireless” Token w/Biometric
Tactical and Strategic goals (cont.): Strategic Goal: Enable Identity-Aware Compliance Reporting and Enforcement: Strategic Creation of an Authoritative Source for Entitlement Data (or an interim Tactical consolidation point that acts as an authoritative source of truth). Vendor Neutral Functional Components per OASIS XACML functional decomposition. Standardized Authorization Model (syntax and semantics) along the lines of ANSI/INCITS 359, NIST RBAC specification CS1.1, and Navy Enterprise Dynamic Access Control (EDAC) project. Enable Compliance Management that can combine traditional CMDB configuration information with Globally Authoritative sources of Identity and Entitlement information Identity Management Authentication Authorization
Choose the next Target Architecture: It is my personal opinion that the single biggest security-related Achilles’ heel for most enterprises is a lack of integration of security practices into the Software/Systems Development process…
Decompose functions:
Methodology Approach – Example #1 TOGAF™ (The Open Group Architecture Framework)
The Open Group Architecture Framework (TOGAF) The architecture is typically modeled at four levels or domains: 1. Business (or business process) architecture which defines the business strategy, governance, organization, and key business processes of the organization 2. Applications architecture which provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization 3. Data architecture which describes the structure of an organization's logical and physical data assets and the associated data management resources 4. Technical architecture or Technology architecture which describes the hardware, software and network infrastructure needed to support the deployment of core, mission-critical applications
From: http://pyovevit.blogspot.com/2008/10/open-group-architecture-framework-togaf.html
Methodology Approach – Example #2 Federal Enterprise Architecture (FEA)
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel:
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf This is the layer where policies, laws, regulations, etc. impinge via the creation of Business Requirements FEA Metamodel Strategy and Performance Layer
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Strategy and Performance Layer
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Business Layer (business processes in each LOB are deconstructed into sub-functions, which are responsible for executing strategic requirements enumerated in the previous layer)
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Data Layer
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Services and Components Layer
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf This is where Technology Standards impinge via use of existing (or creation of new) Services and Components FEA Metamodel Technology Layer
http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf Policies Standards FEA - interface with Policies and Standards
“ Informal and ad-hoc EA processes . Some inventories of information for a given architecture layer may exist, but it is not linked to other layers of the architecture and is incomplete.” Federal EA Maturity Level 1: Initial http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Confusion regarding who to consult and who makes decisions
Federal EA Maturity Level 2: Baseline “ The agency has developed a baseline architecture . The architecture has an enterprise-wide scope and communicates a clear line of sight between EA layers.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Mandates ( , etc.) Business Requirements
Federal EA Maturity Level 3: Target “ The agency has developed target architecture . Architecture elements are aligned to agency programs and lines of business . The target architecture addresses priorities and performance objectives identified in the agency’s strategic plan. Architecture has an enterprise-wide scope and communicates a clear line of sight between EA layers.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
Federal EA Maturity Level 4: Integrated “ The agency has developed at least one segment architecture for a core mission line of business, business service or enterprise service . The relevant business owner has approved the segment architecture in writing. The agency’s transition strategy shows migration to the target architecture.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
Federal EA Maturity Level 5: Optimized “ The agency has developed multiple segment architectures to support core mission lines of business, business services or enterprise services . The segment architectures are incorporated into the overall agency EA. The relevant business owners have approved segment architectures in writing.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Enterprise Transition Strategy
Roadmap (FEAF: “Transition Plan”) Current State (FEAF: “Baseline”) Mature Enterprise Architecture Practice Desired Future State (FEAF: “Target”) Policies Standards Policies Standards Architecture Deliverables
Governance and FEA Program Management • “ Description: The agency must govern and manage the implementation and use of EA policies and processes. This includes the appointment of a Chief Architect (CA), allocation of resources and the sponsorship of EA at the executive level. The agency’s EA Program Management Office governs the development, implementation and maintenance of the EA.” • “ Rationale: Effective governance and program management assures agency compliance with EA processes and procedures and facilitates executive support.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
FEA artifacts typically used to satisfy a specific maturity level: … SDLC Guide “A System Development Life Cycle (SDLC) guide describes the agency’s approved policies and methodology for software development projects. Subjects covered by an SDLC guide may include relevant industry or government standards , approved software development tools and languages, policies on reuse of existing components, and a methodology or framework for software development .” … Transition Strategy “The Transition Strategy is a critical component of an effective EA practice. It describes the overall plan for an organization to achieve its target “to-be” EA within a specified timeframe. It clearly links proposed agency investments to the target architecture . Also, the Transition Strategy helps to define logical dependencies between transition activities (programs and projects) and helps to define the relative priority of these activities (for investment purposes).” [we call this Road Mapping ] http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
Agencies Included in the FEA Assessment Process: U.S. Army Corps of Engineers (USACE) Department of Commerce (DOC) Department of Defense (DoD) Department of Education (ED) Department of Energy (DOE) Department of Health and Human Services (HHS) Department of Homeland Security (DHS) Department of Housing and Urban Development (HUD) Department of Interior (DOI) Department of Justice (DOJ) Department of Labor (DOL) Department of State (State) and US Agency for International Development (USAID) Joint Enterprise Architecture Department of Transportation (DOT) Department of Treasury (Treasury) Department of Veterans Affairs (VA) Environmental Protection Agency (EPA) General Services Administration (GSA) National Aeronautics and Space Administration (NASA) National Science Foundation (NSF) Office of Management and Budget (OMB) Office of Personnel Management (OPM) Social Security Administration (SSA) Small Business Administration (SBA) Smithsonian Institution (Smithsonian) U.S. Department of Agriculture (USDA) (http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf)
Business Reference Model 103: Enterprise Architecture 112: Policy and Guidance Development 136: System Development 137: Lifecycle/Change Management 139: IT Infrastructure Maintenance 140: Information Security 263: System and Network Monitoring 302: Internal Risk Mgmt and Mitigation Technical Reference Model 858: Virtual Private Network 859: Legislative / Compliance 860: Authentication / Single Sign-on 862: Supporting Network Services (eg. LDAP, DNS, etc.) 863: Service Transport (https, ipsec, etc.) 867: Integrated Development Env. (IDE) 868: Software Configuration Management 869: Test Management 884: Certificates / Digital Signatures 885: Supporting Security Services (eg. s/MIME, TLS, SAML, etc.) 896: Enterprise Application Integration (BPM) 901: Service Description / Interface (SOA) Performance Reference Model 445: Security 446: Privacy 471: Availability 472: Reliability Service Component Reference Model 542: Risk Management 543: Workgroup / Groupware 582: Digital Rights Management 640: Instrumentation and Testing 641: Software Development 648: Identification and Authentication 649: Access Control 650: Cryptography 651: Digital Signature Management/PKI 652: Intrusion Prevention 653: Intrusion Detection 654: Incident Response 655: Audit Trail and Capture Analysis 656: Certification and Accreditation 657: FISMA Management and Reporting 658: Virus Protection 659: Email 673: Community Management FEA SECURITY ARCHITECTURE Organized by Federal Enterprise Architecture Layers http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v23_Final_Oct_2007.pdf
Some Best Practices Take the time to talk to all the stakeholders – stress that your goal is to providing air-cover for them to do what they already know needs to be done, and even invite the more talented/invested of your participants to write sections of the architecture documents. Make sure everyone understands that “security architecture” is not static. It is a cascading hierarchy of evolving models and living artifacts -- a continuous process that flexes to accommodate new business requirements and rapidly evolving threat and regulatory landscapes. Include a vision of the “target” or “end-game”, and include intermediate steps (“roadmap”) as well. Without this, the architecture can sound “ivory tower”. Don’t fixate on structure or format; promote action. Be opportunistic: elevate the priority of architecture deliverables that will have an immediate positive impact on key projects. Security architecture is a means to an end, not an end in itself. Intertwine Technology and Business viewpoints (non-trivial). Onus is on Security Architect to learn business principles, terminology, etc. Align with Enterprise Architecture (non-trivial). Onus is on Security Architect to learn enterprise architecture principles, terminology, etc.
Some More Best Practices Provide enough abstraction to reduce complicating factors (technology religious wars, organizational boundaries, etc.). Note this may just delay the inevitable political battles, but it will at least keep them at bay until buyoff can be obtained on the higher level objectives. Include multiple options; avoid one-size-fits-all. Reference architectures must allow some leeway for choice. Dive deep as often as possible and appropriate (strive to provide immediate value wherever feasible – see appendix) Pictures are your friend, especially if they can be used to tell stories Governance is your friend. Review and approval of Security Architectures allows SA to be prioritized and enforced, and helps overcome any organizational isolation of the SA function. Time constraints prevent us from getting into: rigorous taxonomy, ontology, nomenclature, etc. – this is important a process that begins with pure business strategy (the process above assumes ISO/IEC 17799 is a reasonable starting point. FISMA, HIPAA, COBIT, etc. can also serve as reasonable staring points.) metrics for measuring the maturity of a security architecture function Humility – don’t believe your own PR. Always be open minded.

More Related Content

PDF
Risk-driven and Business-outcome-focused Enterprise Security Architecture Fra...
Craig Martin
 
PDF
Security architecture
Duncan Unwin
 
PDF
Enterprise Security Architecture: From access to audit
Bob Rhubart
 
PPTX
Does Anyone Remember Enterprise Security Architecture?
rbrockway
 
PDF
Information Security Architecture: Building Security Into Your Organziation
Seccuris Inc.
 
PPTX
Security models for security architecture
Vladimir Jirasek
 
PDF
TOGAF 9 - Security Architecture Ver1 0
Maganathin Veeraragaloo
 
PDF
2010-02 Building Security Architecture Framework
Raleigh ISSA
 
Risk-driven and Business-outcome-focused Enterprise Security Architecture Fra...
Craig Martin
 
Security architecture
Duncan Unwin
 
Enterprise Security Architecture: From access to audit
Bob Rhubart
 
Does Anyone Remember Enterprise Security Architecture?
rbrockway
 
Information Security Architecture: Building Security Into Your Organziation
Seccuris Inc.
 
Security models for security architecture
Vladimir Jirasek
 
TOGAF 9 - Security Architecture Ver1 0
Maganathin Veeraragaloo
 
2010-02 Building Security Architecture Framework
Raleigh ISSA
 

What's hot (19)

PDF
Zachman Enterprise Security Architecture
Joaquin Marques
 
PDF
Enterprise%20 security%20architecture%20 %20business%20driven%20security
wardell henley
 
PDF
Enterprise Information Security Architecture_Paper_1206
Apoorva Ajmani
 
PDF
Enterprise Security Architecture
Kris Kimmerle
 
PPTX
Enterprise Architecture and Information Security
John Macasio
 
PPTX
The Future of Security Architecture Certification
danb02
 
PPT
Security architecture analyses brief 21 april 2015
Bill Ross
 
PPTX
iCode Security Architecture Framework
Mohamed Ridha CHEBBI, CISSP
 
PDF
Introduction to International Standardization
Kris Kimmerle
 
PDF
Security services mind map
David Kennedy
 
PDF
Safeguarding the Enterprise
ADGP, Public Grivences, Bangalore
 
PDF
Making Executives Accountable for IT Security
Seccuris Inc.
 
PDF
Defense In-Depth
Will Kelly
 
DOCX
" The Invisible Person ... the Security Architect "
Bill Ross
 
PDF
Top 10 IT Security Issues 2011
Redspin, Inc.
 
PDF
Cybersecurity solution-guide
AdilsonSuende
 
PDF
Cybersecurity domains-map-3.0
Oscar Ferreira
 
DOC
The security risk management guide
Sergey Erohin
 
PDF
Cyber Crime Conference 2017 - DFLabs Supervised Active Intelligence - Andrea ...
DFLABS SRL
 
Zachman Enterprise Security Architecture
Joaquin Marques
 
Enterprise%20 security%20architecture%20 %20business%20driven%20security
wardell henley
 
Enterprise Information Security Architecture_Paper_1206
Apoorva Ajmani
 
Enterprise Security Architecture
Kris Kimmerle
 
Enterprise Architecture and Information Security
John Macasio
 
The Future of Security Architecture Certification
danb02
 
Security architecture analyses brief 21 april 2015
Bill Ross
 
iCode Security Architecture Framework
Mohamed Ridha CHEBBI, CISSP
 
Introduction to International Standardization
Kris Kimmerle
 
Security services mind map
David Kennedy
 
Safeguarding the Enterprise
ADGP, Public Grivences, Bangalore
 
Making Executives Accountable for IT Security
Seccuris Inc.
 
Defense In-Depth
Will Kelly
 
" The Invisible Person ... the Security Architect "
Bill Ross
 
Top 10 IT Security Issues 2011
Redspin, Inc.
 
Cybersecurity solution-guide
AdilsonSuende
 
Cybersecurity domains-map-3.0
Oscar Ferreira
 
The security risk management guide
Sergey Erohin
 
Cyber Crime Conference 2017 - DFLabs Supervised Active Intelligence - Andrea ...
DFLABS SRL
 
Ad

Viewers also liked (20)

PDF
Enterprise Security Architecture for Cyber Security
The Open Group SA
 
PDF
Smart Security Architectures for YOUR Business!
Dr David Probert
 
PPTX
Security architecture frameworks
John Arnold
 
PPTX
NIST CyberSecurity Framework: An Overview
Tandhy Simanjuntak
 
PPTX
Bi and strategic decision making
Phillip Higgins
 
PDF
SABSA - TOGAF Integration White Paper
SABSAcourses
 
PDF
The Heatmap
 - Why is Security Visualization so Hard?
Raffael Marty
 
PDF
Togaf 9 Capability Based Planning Ver1 0
Maganathin Veeraragaloo
 
PDF
Designing Virtual Network Security Architectures
Priyanka Aash
 
PPTX
SABSA Implementation(Part VI)_ver1-0
Maganathin Veeraragaloo
 
PDF
Capability-based planning with TOGAF & ArchiMate
Anastasios Papazoglou
 
PDF
Practical Enterprise Security Architecture
Priyanka Aash
 
PPTX
ea2009 Enterprise Architecture keynote Final
Marc Caltabiano
 
PPT
Enterprise Architecture: Current-Target-Transition - Andy Blumenthal
Andy (Avraham) Blumenthal
 
PPTX
Lucid IT & UXC Consulting: The Cloud Opportunity: Building on Your Investment...
j_white
 
PPTX
Enterprise Security Architecture
Priyanka Aash
 
PPTX
EA maturity models
Paul Sullivan
 
PPTX
A Summary of TOGAF's Architecture Capability Framework
Paul Sullivan
 
PPTX
Modelling Security Architecture
narenvivek
 
PDF
Enterprise Security Architecture
Priyanka Aash
 
Enterprise Security Architecture for Cyber Security
The Open Group SA
 
Smart Security Architectures for YOUR Business!
Dr David Probert
 
Security architecture frameworks
John Arnold
 
NIST CyberSecurity Framework: An Overview
Tandhy Simanjuntak
 
Bi and strategic decision making
Phillip Higgins
 
SABSA - TOGAF Integration White Paper
SABSAcourses
 
The Heatmap
 - Why is Security Visualization so Hard?
Raffael Marty
 
Togaf 9 Capability Based Planning Ver1 0
Maganathin Veeraragaloo
 
Designing Virtual Network Security Architectures
Priyanka Aash
 
SABSA Implementation(Part VI)_ver1-0
Maganathin Veeraragaloo
 
Capability-based planning with TOGAF & ArchiMate
Anastasios Papazoglou
 
Practical Enterprise Security Architecture
Priyanka Aash
 
ea2009 Enterprise Architecture keynote Final
Marc Caltabiano
 
Enterprise Architecture: Current-Target-Transition - Andy Blumenthal
Andy (Avraham) Blumenthal
 
Lucid IT & UXC Consulting: The Cloud Opportunity: Building on Your Investment...
j_white
 
Enterprise Security Architecture
Priyanka Aash
 
EA maturity models
Paul Sullivan
 
A Summary of TOGAF's Architecture Capability Framework
Paul Sullivan
 
Modelling Security Architecture
narenvivek
 
Enterprise Security Architecture
Priyanka Aash
 
Ad

Similar to Ea Relationship To Security And The Enterprise V1 (20)

PDF
Security-by-Design in Enterprise Architecture
The Open Group SA
 
PPTX
Business value of Enterprise Security Architecture
Ajay Kumar Uppal
 
PDF
Enterprise Architecture - Information Security
Ajay Kumar Uppal
 
PPT
Securing Citizen Facing Applications
edwinlorenzana
 
PPTX
Conceptual security architecture
MubashirAslam5
 
PPTX
crisc_wk_5.pptx
dotco
 
PDF
What is Enterprise Security Architecture (ESA)?
John Gardner, CMC
 
PPTX
Chapter 1 Security Framework
Karthikeyan Dhayalan
 
PDF
Safeguarding the Enterprise. A new approach.
ADGP, Public Grivences, Bangalore
 
PDF
Denver ISSA Chapter Meetings - Changing the Security Paradigm
Identity Defined Security Alliance
 
PPTX
ESA for Business
Maganathin Veeraragaloo
 
PDF
Identiverse Zero Trust Customer Briefing, Identiverse 2019
Identity Defined Security Alliance
 
PDF
SABSA vs. TOGAF in a RMF NIST 800-30 context
David Sweigert
 
PPTX
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
SilvioHayashi
 
PPTX
MS. Cybersecurity Reference Architecture
angelohammond
 
PPTX
Cyber Security # Lec 5
Kabul Education University
 
PDF
Why Integrating Network Technology & Security Makes Sense Now
Abaram Network Solutions
 
PDF
CISSP Cheatsheet.pdf
shyedshahriar
 
PPTX
Visual Security.pptx
JohnArnold86359
 
PDF
G05.2013 gartner top security trends
Satya Harish
 
Security-by-Design in Enterprise Architecture
The Open Group SA
 
Business value of Enterprise Security Architecture
Ajay Kumar Uppal
 
Enterprise Architecture - Information Security
Ajay Kumar Uppal
 
Securing Citizen Facing Applications
edwinlorenzana
 
Conceptual security architecture
MubashirAslam5
 
crisc_wk_5.pptx
dotco
 
What is Enterprise Security Architecture (ESA)?
John Gardner, CMC
 
Chapter 1 Security Framework
Karthikeyan Dhayalan
 
Safeguarding the Enterprise. A new approach.
ADGP, Public Grivences, Bangalore
 
Denver ISSA Chapter Meetings - Changing the Security Paradigm
Identity Defined Security Alliance
 
ESA for Business
Maganathin Veeraragaloo
 
Identiverse Zero Trust Customer Briefing, Identiverse 2019
Identity Defined Security Alliance
 
SABSA vs. TOGAF in a RMF NIST 800-30 context
David Sweigert
 
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
SilvioHayashi
 
MS. Cybersecurity Reference Architecture
angelohammond
 
Cyber Security # Lec 5
Kabul Education University
 
Why Integrating Network Technology & Security Makes Sense Now
Abaram Network Solutions
 
CISSP Cheatsheet.pdf
shyedshahriar
 
Visual Security.pptx
JohnArnold86359
 
G05.2013 gartner top security trends
Satya Harish
 

Recently uploaded (20)

PDF
Accessing-Finance-in-Jordan-MENA 2024 2025.pdf
Mustafa Kuğu
 
PDF
IT-ITes Industry bjjbnkmkhkhknbmhkhmjhjkhj
yatharthjutt100311
 
PDF
INTERSPEECH 2025 「Recent Advances and Future Directions in Voice Conversion」
NU_I_TODALAB
 
PDF
The-Future-of-Automotive-Quality-is-Here-AI-Driven-Engineering.pdf
Kalilur Rahman
 
PDF
Produktkatalog für HOBO Datenlogger, Wetterstationen, Sensoren, Software und ...
Metrics GmbH
 
DOCX
Basics of Cloud Computing - Cloud Ecosystem
suthak11
 
PDF
Transform-Your-Supply-Chain-with-AI-Driven-Quality-Engineering.pdf
Kalilur Rahman
 
PDF
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
Michael Weaver
 
PDF
Enhancing plagiarism detection using data pre-processing and machine learning...
IAESIJAI
 
PDF
Convolutional neural network based encoder-decoder for efficient real-time ob...
IAESIJAI
 
PPTX
Training Program for knowledge in solar cell and solar industry
RabindranathKaibarty
 
PDF
Dell Pro Micro: Speed customer interactions, patient processing, and learning...
Principled Technologies
 
PPTX
MuleSoft-Compete-Deck for midddleware integrations
zupittejas
 
PPTX
Module 1 Introduction to Web Programming .pptx
kamleshkc191
 
PDF
The-2025-Engineering-Revolution-AI-Quality-and-DevOps-Convergence.pdf
Kalilur Rahman
 
PDF
Lung cancer patients survival prediction using outlier detection and optimize...
IAESIJAI
 
PPTX
Internet of Everything -Basic concepts details
sendilkumar66
 
PDF
giants, standing on the shoulders of - by Daniel Stenberg
Daniel Stenberg
 
PDF
Early detection and classification of bone marrow changes in lumbar vertebrae...
IAESIJAI
 
PDF
Co-training pseudo-labeling for text classification with support vector machi...
IAESIJAI
 
Accessing-Finance-in-Jordan-MENA 2024 2025.pdf
Mustafa Kuğu
 
IT-ITes Industry bjjbnkmkhkhknbmhkhmjhjkhj
yatharthjutt100311
 
INTERSPEECH 2025 「Recent Advances and Future Directions in Voice Conversion」
NU_I_TODALAB
 
The-Future-of-Automotive-Quality-is-Here-AI-Driven-Engineering.pdf
Kalilur Rahman
 
Produktkatalog für HOBO Datenlogger, Wetterstationen, Sensoren, Software und ...
Metrics GmbH
 
Basics of Cloud Computing - Cloud Ecosystem
suthak11
 
Transform-Your-Supply-Chain-with-AI-Driven-Quality-Engineering.pdf
Kalilur Rahman
 
AI.gov: A Trojan Horse in the Age of Artificial Intelligence
Michael Weaver
 
Enhancing plagiarism detection using data pre-processing and machine learning...
IAESIJAI
 
Convolutional neural network based encoder-decoder for efficient real-time ob...
IAESIJAI
 
Training Program for knowledge in solar cell and solar industry
RabindranathKaibarty
 
Dell Pro Micro: Speed customer interactions, patient processing, and learning...
Principled Technologies
 
MuleSoft-Compete-Deck for midddleware integrations
zupittejas
 
Module 1 Introduction to Web Programming .pptx
kamleshkc191
 
The-2025-Engineering-Revolution-AI-Quality-and-DevOps-Convergence.pdf
Kalilur Rahman
 
Lung cancer patients survival prediction using outlier detection and optimize...
IAESIJAI
 
Internet of Everything -Basic concepts details
sendilkumar66
 
giants, standing on the shoulders of - by Daniel Stenberg
Daniel Stenberg
 
Early detection and classification of bone marrow changes in lumbar vertebrae...
IAESIJAI
 
Co-training pseudo-labeling for text classification with support vector machi...
IAESIJAI
 

Ea Relationship To Security And The Enterprise V1

  • 1. Enterprise Security Architecture Prentice Kinser, CISSP-ISSAP caveat emptor : This material is furnished as-is. The author makes no warranties of any kind, including, but not limited to fitness for purpose, merchantability, exclusivity, or freedom from patent, trademark, or copyright infringement. The findings, interpretations, and conclusions expressed herein are those of the author and do not necessarily reflect the views of any employers, past or present. Use of any product names, images, or trademarks in this material is not intended in any way to infringe on the rights of the trademark holder, nor is it intended to positively or negatively endorse any product or solution. Permission is granted for free usage of all or portions of this document, including derived works, provided proper acknowledgement is given.
  • 2. 3 D’s Diplomacy Disclaimer Disclosure
  • 3. Enterprise Architecture vs. Enterprise Security Architecture EA: Frameworks (Zachman, FEAF, IEEE-1471, etc.) Methodologies (TOGAF, DoDAF, RUP/EUP, FEA, etc.) Goal is to optimize business value from enterprise assets through creation, and then reengineering, of a map of all business activities - their value, cost, and interrelationships SA: Frameworks (SABSA, ISO 17799, etc.) Methodologies (COBIT, AICPA, etc.) Reactionary (Risk Assessment, Audit Response, Incident Management, Regulatory minimalism [panic response to GLBA, HIPAA, FISMA, etc.]) Goal is to provide an appropriately balanced program to protect business assets
  • 4. Enterprise Architecture vs. Enterprise Security Architecture EA: Goals are stated as return on investment (ROI), net present value (NPV), annual loss expectancy (ALE), etc.
  • 5.  
  • 6. Source: Gartner IT Security Summit, Tom Scholtz, 4-6 June 2007, Washington, D.C., “Advanced Security Architecture Practice”
  • 7. Enterprise Architecture vs. Enterprise Security Architecture SA: Goal stated as … what?
  • 8. Enterprise Security Architecture Goal = TRUST Source: Gartner IT Security Summit, Jeffrey Wheatman and Paul E. Proctor, 4-6 June 2007, Washington, D.C., “How to Conduct a Risk Assessment: A Play in Three Acts”
  • 9. Enterprise Security Architecture… Framework? Methodology? Reactionary? Depends on your Risk Management Culture …
  • 10. Risk Management Culture Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997 Ideas welcomed Ideas beget problems Ideas discouraged Failures beget reforms Local repairs only Failure punished Responsibility shared Compartmentalized Responsibility shirked Messengers rewarded Heard if they arrive Messengers “shot” Actively seek May not find out Don’t want to know Generative Bureaucratic Pathologic
  • 11. Risk Management Culture Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997 Reactionary Framework Methodology Ideas welcomed Ideas beget problems Ideas discouraged Failures beget reforms Local repairs only Failure punished Responsibility shared Compartmentalized Responsibility shirked Messengers rewarded Heard if they arrive Messengers “shot” Actively seek May not find out Don’t want to know Generative Bureaucratic Pathologic
  • 12. Enterprise Architecture vs. Enterprise Security Architecture EA: Goal is to optimize business value from business assets through creation, and then reengineering, of a map of all enterprise activities - their value, cost, and interrelationships SA: Goal is to provide an appropriately balanced program to protect all business assets in the enterprise Security Architect must keep a foot in BOTH worlds – can’t create “balance” w/o understanding interrelationships in the broader EA context
  • 13. HOW TO SCOPE THE SECURITY TARGET ARCHITECTURES?
  • 15. Begin decomposition into individual Target Architecture domains: Access Control enables an enterprise to manage WHO has access to WHAT , it is supported with a collection of administration tools for defining the whos, the whats, and the circumstances under which access is granted or denied, and it allows the enterprise to delegate and exercise fiduciary responsibilities, such as substantiating access approvals, demonstrating access enforcement, and detecting cross-functional impacts of policy exceptions.
  • 16. Access Control Target Architecture domain further decomposed into three parts: Identity Management (the ability to centrally provision and de-provision identities and credentials through workflow and automated processes) Example: Vetting the documentation a person uses to prove their identity, and issuing appropriately configured badges, account ID’s, and access credentials (passwords, tokens, smart cards, etc.). Authentication (the process of validating a claimed identity) Example: Presenting picture ID badge to security guard who validates ID badge against the presenter. Authorization (the set of permissions afforded to an identity) Example: Granting the person access to a building based on a predetermined policy.
  • 17. Drill down into Tactical and Strategic goals, and include timeframe recommendations: Strategic Goal: All Employees use FIPS201 compliant or compatible smart-cards: 2008: detailed design completed and modifications to policies and procedures finalized 2009: infrastructure build-out completed and new HR procedures implemented 2010: all new employees and a majority of existing employees are issued FIPS compatible identity cards 2011: rollout of FIPS compatible identity cards is complete, and rollout of FIPS compatible PACS is complete Tactical Alternative: two-factor authentication utilizing one-time-password token technology conforming with the NIST SP800-63 standard for Level-3 Assurance (this is primarily to enable rapid elimination of single-factor authentication on platforms that are unable to support cryptographic smart-cards) Identity Management Authentication Authorization
  • 18. Tactical and Strategic goals (cont.): Strategic Goal: All non-employees utilize smart card technology conforming with one of the following options: FIPS201 compatible technology issued by enterprise or delegated RA FIPS201 compliant technology issued by a federally-recognized entity Federation using FIPS201-style public certificates and CRLs Tactical Alternatives: Vendor-proprietary point-to-point federation assertions (eg. SAML) that are signed using FIPS201-style public certificates and CRLs One-time-password token technology conforming with the NIST SP800-63 standard for Level-3 Assurance Identity Management Authentication Authorization
  • 19. Tactical and Strategic goals (cont.): Strategic Goal: All users of enterprise resources (irrespective of employer) are tracked using a Universally Unique Identifier (UUID). Each individual person gets one and only one UUID, irrespective of the number of user ID’s, federated identities, or roles held by that individual over their lifetime. End game: Consolidation of Identity Management Systems and Processes will occur, organically and via integration with ITIL and CMDB practices. The new Identity Management paradigm is that everyone is external . Identity Management Authentication Authorization
  • 20. Tactical and Strategic goals (cont.): Strategic Goal: No more “single-factor” Authentication 2007 system administrator accounts 2008 NOS accounts (Windows, UNIX, Cisco IOS, etc.) 2009 Network Access Control (NAC) 2011 all other interactive systems Identity Management Authentication Authorization
  • 21. Tactical and Strategic goals (cont.): Identity Management Authentication Authorization Strategic Goal: FIPS201 Tactical Alternatives (some examples): One-Time-Password “Wired” Token w/PIN “Wireless” Token w/Biometric
  • 22. Tactical and Strategic goals (cont.): Strategic Goal: Enable Identity-Aware Compliance Reporting and Enforcement: Strategic Creation of an Authoritative Source for Entitlement Data (or an interim Tactical consolidation point that acts as an authoritative source of truth). Vendor Neutral Functional Components per OASIS XACML functional decomposition. Standardized Authorization Model (syntax and semantics) along the lines of ANSI/INCITS 359, NIST RBAC specification CS1.1, and Navy Enterprise Dynamic Access Control (EDAC) project. Enable Compliance Management that can combine traditional CMDB configuration information with Globally Authoritative sources of Identity and Entitlement information Identity Management Authentication Authorization
  • 23. Choose the next Target Architecture: It is my personal opinion that the single biggest security-related Achilles’ heel for most enterprises is a lack of integration of security practices into the Software/Systems Development process…
  • 25. Methodology Approach – Example #1 TOGAF™ (The Open Group Architecture Framework)
  • 26. The Open Group Architecture Framework (TOGAF) The architecture is typically modeled at four levels or domains: 1. Business (or business process) architecture which defines the business strategy, governance, organization, and key business processes of the organization 2. Applications architecture which provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization 3. Data architecture which describes the structure of an organization's logical and physical data assets and the associated data management resources 4. Technical architecture or Technology architecture which describes the hardware, software and network infrastructure needed to support the deployment of core, mission-critical applications
  • 28. Methodology Approach – Example #2 Federal Enterprise Architecture (FEA)
  • 30. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf This is the layer where policies, laws, regulations, etc. impinge via the creation of Business Requirements FEA Metamodel Strategy and Performance Layer
  • 32. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Business Layer (business processes in each LOB are deconstructed into sub-functions, which are responsible for executing strategic requirements enumerated in the previous layer)
  • 35. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf This is where Technology Standards impinge via use of existing (or creation of new) Services and Components FEA Metamodel Technology Layer
  • 37. “ Informal and ad-hoc EA processes . Some inventories of information for a given architecture layer may exist, but it is not linked to other layers of the architecture and is incomplete.” Federal EA Maturity Level 1: Initial http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Confusion regarding who to consult and who makes decisions
  • 38. Federal EA Maturity Level 2: Baseline “ The agency has developed a baseline architecture . The architecture has an enterprise-wide scope and communicates a clear line of sight between EA layers.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Mandates ( , etc.) Business Requirements
  • 39. Federal EA Maturity Level 3: Target “ The agency has developed target architecture . Architecture elements are aligned to agency programs and lines of business . The target architecture addresses priorities and performance objectives identified in the agency’s strategic plan. Architecture has an enterprise-wide scope and communicates a clear line of sight between EA layers.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
  • 40. Federal EA Maturity Level 4: Integrated “ The agency has developed at least one segment architecture for a core mission line of business, business service or enterprise service . The relevant business owner has approved the segment architecture in writing. The agency’s transition strategy shows migration to the target architecture.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
  • 41. Federal EA Maturity Level 5: Optimized “ The agency has developed multiple segment architectures to support core mission lines of business, business services or enterprise services . The segment architectures are incorporated into the overall agency EA. The relevant business owners have approved segment architectures in writing.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf Enterprise Transition Strategy
  • 42. Roadmap (FEAF: “Transition Plan”) Current State (FEAF: “Baseline”) Mature Enterprise Architecture Practice Desired Future State (FEAF: “Target”) Policies Standards Policies Standards Architecture Deliverables
  • 43. Governance and FEA Program Management • “ Description: The agency must govern and manage the implementation and use of EA policies and processes. This includes the appointment of a Chief Architect (CA), allocation of resources and the sponsorship of EA at the executive level. The agency’s EA Program Management Office governs the development, implementation and maintenance of the EA.” • “ Rationale: Effective governance and program management assures agency compliance with EA processes and procedures and facilitates executive support.” http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
  • 44. FEA artifacts typically used to satisfy a specific maturity level: … SDLC Guide “A System Development Life Cycle (SDLC) guide describes the agency’s approved policies and methodology for software development projects. Subjects covered by an SDLC guide may include relevant industry or government standards , approved software development tools and languages, policies on reuse of existing components, and a methodology or framework for software development .” … Transition Strategy “The Transition Strategy is a critical component of an effective EA practice. It describes the overall plan for an organization to achieve its target “to-be” EA within a specified timeframe. It clearly links proposed agency investments to the target architecture . Also, the Transition Strategy helps to define logical dependencies between transition activities (programs and projects) and helps to define the relative priority of these activities (for investment purposes).” [we call this Road Mapping ] http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf
  • 45. Agencies Included in the FEA Assessment Process: U.S. Army Corps of Engineers (USACE) Department of Commerce (DOC) Department of Defense (DoD) Department of Education (ED) Department of Energy (DOE) Department of Health and Human Services (HHS) Department of Homeland Security (DHS) Department of Housing and Urban Development (HUD) Department of Interior (DOI) Department of Justice (DOJ) Department of Labor (DOL) Department of State (State) and US Agency for International Development (USAID) Joint Enterprise Architecture Department of Transportation (DOT) Department of Treasury (Treasury) Department of Veterans Affairs (VA) Environmental Protection Agency (EPA) General Services Administration (GSA) National Aeronautics and Space Administration (NASA) National Science Foundation (NSF) Office of Management and Budget (OMB) Office of Personnel Management (OPM) Social Security Administration (SSA) Small Business Administration (SBA) Smithsonian Institution (Smithsonian) U.S. Department of Agriculture (USDA) (http://www.whitehouse.gov/omb/egov/documents/OMB_EA_Assessment_Framework_v22_Final.pdf)
  • 46. Business Reference Model 103: Enterprise Architecture 112: Policy and Guidance Development 136: System Development 137: Lifecycle/Change Management 139: IT Infrastructure Maintenance 140: Information Security 263: System and Network Monitoring 302: Internal Risk Mgmt and Mitigation Technical Reference Model 858: Virtual Private Network 859: Legislative / Compliance 860: Authentication / Single Sign-on 862: Supporting Network Services (eg. LDAP, DNS, etc.) 863: Service Transport (https, ipsec, etc.) 867: Integrated Development Env. (IDE) 868: Software Configuration Management 869: Test Management 884: Certificates / Digital Signatures 885: Supporting Security Services (eg. s/MIME, TLS, SAML, etc.) 896: Enterprise Application Integration (BPM) 901: Service Description / Interface (SOA) Performance Reference Model 445: Security 446: Privacy 471: Availability 472: Reliability Service Component Reference Model 542: Risk Management 543: Workgroup / Groupware 582: Digital Rights Management 640: Instrumentation and Testing 641: Software Development 648: Identification and Authentication 649: Access Control 650: Cryptography 651: Digital Signature Management/PKI 652: Intrusion Prevention 653: Intrusion Detection 654: Incident Response 655: Audit Trail and Capture Analysis 656: Certification and Accreditation 657: FISMA Management and Reporting 658: Virus Protection 659: Email 673: Community Management FEA SECURITY ARCHITECTURE Organized by Federal Enterprise Architecture Layers http://www.whitehouse.gov/omb/egov/documents/FEA_CRM_v23_Final_Oct_2007.pdf
  • 47. Some Best Practices Take the time to talk to all the stakeholders – stress that your goal is to providing air-cover for them to do what they already know needs to be done, and even invite the more talented/invested of your participants to write sections of the architecture documents. Make sure everyone understands that “security architecture” is not static. It is a cascading hierarchy of evolving models and living artifacts -- a continuous process that flexes to accommodate new business requirements and rapidly evolving threat and regulatory landscapes. Include a vision of the “target” or “end-game”, and include intermediate steps (“roadmap”) as well. Without this, the architecture can sound “ivory tower”. Don’t fixate on structure or format; promote action. Be opportunistic: elevate the priority of architecture deliverables that will have an immediate positive impact on key projects. Security architecture is a means to an end, not an end in itself. Intertwine Technology and Business viewpoints (non-trivial). Onus is on Security Architect to learn business principles, terminology, etc. Align with Enterprise Architecture (non-trivial). Onus is on Security Architect to learn enterprise architecture principles, terminology, etc.
  • 48. Some More Best Practices Provide enough abstraction to reduce complicating factors (technology religious wars, organizational boundaries, etc.). Note this may just delay the inevitable political battles, but it will at least keep them at bay until buyoff can be obtained on the higher level objectives. Include multiple options; avoid one-size-fits-all. Reference architectures must allow some leeway for choice. Dive deep as often as possible and appropriate (strive to provide immediate value wherever feasible – see appendix) Pictures are your friend, especially if they can be used to tell stories Governance is your friend. Review and approval of Security Architectures allows SA to be prioritized and enforced, and helps overcome any organizational isolation of the SA function. Time constraints prevent us from getting into: rigorous taxonomy, ontology, nomenclature, etc. – this is important a process that begins with pure business strategy (the process above assumes ISO/IEC 17799 is a reasonable starting point. FISMA, HIPAA, COBIT, etc. can also serve as reasonable staring points.) metrics for measuring the maturity of a security architecture function Humility – don’t believe your own PR. Always be open minded.

Editor's Notes

  • #2: How many enterprise architects does it take to change a light bulb? (8) One to develop a technology roadmap for the line of business requiring illumination. This roadmap will address lighting requirements for the next 3-5 years. Another to spin up a System-wide workgroup to determine what light bulb brands, form-factors, and wattages are currently acceptable for use. A third architect is needed to propose light bulb standards so that other lines of business who also may require illumination now or in the future will have readily available and approved options. A Chief Architect is needed to review and sign-off on the new light bulb standard after it has been adequately vetted system-wide. Yet another architect must be assigned to the Book of Business project team to help complete the documentation artifacts required by the Project Management Standards, and to opine on why the business should acquire a 150-watt light bulb instead of the 25-watt bulb they have in their budget. And then we need an architect to help define the functional and non-functional requirements which will be documented in the RFP to be submitted to at least seven light bulb suppliers. A seventh architect will assist the business line in analyzing the RFP responses and advising them on which light bulb supplier should be selected from a future technology perspective. And the eighth architect, who truly is multi-talented, is needed to support: CONTRACTS as they negotiate cost, warranty and ongoing support from light bulb suppliers; PROCUREMENT as they acquire said light bulbs; PROJECT IMPLEMENTATION TEAM to hold the ladder while the engineer screws in the light bulb and, finally….. To prepare a report to the CIO and all the management oversight and governance councils explaining why this business has had to use candles for the last 18 months.