Ea Relationship To Security And The Enterprise V1


Published on

My philosophy on Enterprise Architecture

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Ea Relationship To Security And The Enterprise V1

  1. 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. 2. 3 D’s <ul><li>Diplomacy </li></ul><ul><li>Disclaimer </li></ul><ul><li>Disclosure </li></ul>
  3. 3. Enterprise Architecture vs. Enterprise Security Architecture <ul><li>EA: </li></ul><ul><ul><li>Frameworks (Zachman, FEAF, IEEE-1471, etc.) </li></ul></ul><ul><ul><li>Methodologies (TOGAF, DoDAF, RUP/EUP, FEA, etc.) </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><li>SA: </li></ul><ul><ul><li>Frameworks (SABSA, ISO 17799, etc.) </li></ul></ul><ul><ul><li>Methodologies (COBIT, AICPA, etc.) </li></ul></ul><ul><ul><li>Reactionary (Risk Assessment, Audit Response, Incident Management, Regulatory minimalism [panic response to GLBA, HIPAA, FISMA, etc.]) </li></ul></ul><ul><ul><li>Goal is to provide an appropriately balanced program to protect business assets </li></ul></ul>
  4. 4. Enterprise Architecture vs. Enterprise Security Architecture <ul><li>EA: </li></ul><ul><ul><li>Goals are stated as return on investment (ROI), net present value (NPV), annual loss expectancy (ALE), etc. </li></ul></ul>
  5. 6. Source: Gartner IT Security Summit, Tom Scholtz, 4-6 June 2007, Washington, D.C., “Advanced Security Architecture Practice”
  6. 7. Enterprise Architecture vs. Enterprise Security Architecture <ul><li>SA: </li></ul><ul><ul><li>Goal stated as … what? </li></ul></ul>
  7. 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”
  8. 9. Enterprise Security Architecture… <ul><ul><li>Framework? </li></ul></ul><ul><ul><li>Methodology? </li></ul></ul><ul><ul><li>Reactionary? </li></ul></ul><ul><ul><li>Depends on your </li></ul></ul><ul><ul><li>Risk Management Culture … </li></ul></ul>
  9. 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
  10. 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
  11. 12. Enterprise Architecture vs. Enterprise Security Architecture <ul><li>EA: </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>SA: </li></ul><ul><ul><li>Goal is to provide an appropriately balanced program to protect all business assets in the enterprise </li></ul></ul><ul><li>Security Architect must keep a foot in BOTH worlds – can’t create “balance” w/o understanding interrelationships in the broader EA context </li></ul>
  13. 14. Framework Approach - Example
  14. 15. Begin decomposition into individual Target Architecture domains: <ul><li>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. </li></ul>
  15. 16. Access Control Target Architecture domain further decomposed into three parts: <ul><li>Identity Management (the ability to centrally provision and de-provision identities and credentials through workflow and automated processes) </li></ul><ul><ul><li>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.). </li></ul></ul><ul><li>Authentication (the process of validating a claimed identity) </li></ul><ul><ul><li>Example: Presenting picture ID badge to security guard who validates ID badge against the presenter. </li></ul></ul><ul><li>Authorization (the set of permissions afforded to an identity) </li></ul><ul><ul><li>Example: Granting the person access to a building based on a predetermined policy. </li></ul></ul>
  16. 17. Drill down into Tactical and Strategic goals, and include timeframe recommendations: <ul><li>Strategic Goal: All Employees use FIPS201 compliant or compatible smart-cards: </li></ul><ul><li>2008: detailed design completed and modifications to policies and procedures finalized </li></ul><ul><li>2009: infrastructure build-out completed and new HR procedures implemented </li></ul><ul><li>2010: all new employees and a majority of existing employees are issued FIPS compatible identity cards </li></ul><ul><li>2011: rollout of FIPS compatible identity cards is complete, and rollout of FIPS compatible PACS is complete </li></ul><ul><li>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) </li></ul>Identity Management Authentication Authorization
  17. 18. Tactical and Strategic goals (cont.): <ul><li>Strategic Goal: All non-employees utilize smart card technology conforming with one of the following options: </li></ul><ul><ul><li>FIPS201 compatible technology issued by enterprise or delegated RA </li></ul></ul><ul><ul><li>FIPS201 compliant technology issued by a federally-recognized entity </li></ul></ul><ul><ul><li>Federation using FIPS201-style public certificates and CRLs </li></ul></ul><ul><li>Tactical Alternatives: </li></ul><ul><ul><li>Vendor-proprietary point-to-point federation assertions (eg. SAML) that are signed using FIPS201-style public certificates and CRLs </li></ul></ul><ul><ul><li>One-time-password token technology conforming with the NIST SP800-63 standard for Level-3 Assurance </li></ul></ul>Identity Management Authentication Authorization
  18. 19. Tactical and Strategic goals (cont.): <ul><li>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. </li></ul><ul><li>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 . </li></ul>Identity Management Authentication Authorization
  19. 20. Tactical and Strategic goals (cont.): <ul><li>Strategic Goal: No more “single-factor” Authentication </li></ul><ul><ul><li>2007 system administrator accounts </li></ul></ul><ul><ul><li>2008 NOS accounts (Windows, UNIX, Cisco IOS, etc.) </li></ul></ul><ul><ul><li>2009 Network Access Control (NAC) </li></ul></ul><ul><ul><li>2011 all other interactive systems </li></ul></ul>Identity Management Authentication Authorization
  20. 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
  21. 22. Tactical and Strategic goals (cont.): <ul><li>Strategic Goal: Enable Identity-Aware Compliance Reporting and Enforcement: </li></ul><ul><li>Strategic Creation of an Authoritative Source for Entitlement Data (or an interim Tactical consolidation point that acts as an authoritative source of truth). </li></ul><ul><li>Vendor Neutral Functional Components per OASIS XACML functional decomposition. </li></ul><ul><li>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. </li></ul><ul><li>Enable Compliance Management that can combine traditional CMDB configuration information with Globally Authoritative sources of Identity and Entitlement information </li></ul>Identity Management Authentication Authorization
  22. 23. Choose the next Target Architecture: <ul><li>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… </li></ul>
  23. 24. Decompose functions:
  24. 25. Methodology Approach – Example #1 TOGAF™ (The Open Group Architecture Framework)
  25. 26. The Open Group Architecture Framework (TOGAF) <ul><li>The architecture is typically modeled at four levels or domains: </li></ul><ul><li>1. Business (or business process) architecture which defines the business strategy, governance, organization, and key business processes of the organization </li></ul><ul><li>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 </li></ul><ul><li>3. Data architecture which describes the structure of an organization's logical and physical data assets and the associated data management resources </li></ul><ul><li>4. Technical architecture or Technology architecture which describes the hardware, software and network infrastructure needed to support the deployment of core, mission-critical applications </li></ul>
  26. 27. From: http://pyovevit.blogspot.com/2008/10/open-group-architecture-framework-togaf.html
  27. 28. Methodology Approach – Example #2 Federal Enterprise Architecture (FEA)
  28. 29. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel:
  29. 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
  30. 31. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Strategy and Performance Layer
  31. 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)
  32. 33. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Data Layer
  33. 34. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Services and Components Layer
  34. 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
  35. 36. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf Policies Standards FEA - interface with Policies and Standards
  36. 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 <ul><li>Confusion regarding who to consult and who makes decisions </li></ul>
  37. 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
  38. 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
  39. 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
  40. 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
  41. 42. Roadmap (FEAF: “Transition Plan”) Current State (FEAF: “Baseline”) Mature Enterprise Architecture Practice Desired Future State (FEAF: “Target”) Policies Standards Policies Standards Architecture Deliverables
  42. 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
  43. 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
  44. 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)
  45. 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
  46. 47. Some Best Practices <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Include a vision of the “target” or “end-game”, and include intermediate steps (“roadmap”) as well. Without this, the architecture can sound “ivory tower”. </li></ul><ul><li>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. </li></ul><ul><li>Intertwine Technology and Business viewpoints (non-trivial). Onus is on Security Architect to learn business principles, terminology, etc. </li></ul><ul><li>Align with Enterprise Architecture (non-trivial). Onus is on Security Architect to learn enterprise architecture principles, terminology, etc. </li></ul>
  47. 48. Some More Best Practices <ul><li>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. </li></ul><ul><li>Include multiple options; avoid one-size-fits-all. Reference architectures must allow some leeway for choice. </li></ul><ul><li>Dive deep as often as possible and appropriate (strive to provide immediate value wherever feasible – see appendix) </li></ul><ul><li>Pictures are your friend, especially if they can be used to tell stories </li></ul><ul><li>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. </li></ul><ul><li>Time constraints prevent us from getting into: </li></ul><ul><ul><li>rigorous taxonomy, ontology, nomenclature, etc. – this is important </li></ul></ul><ul><ul><li>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.) </li></ul></ul><ul><ul><li>metrics for measuring the maturity of a security architecture function </li></ul></ul><ul><li>Humility – don’t believe your own PR. Always be open minded. </li></ul>