• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • 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.


  • 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
  • 14. Framework Approach - Example
  • 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…
  • 24. Decompose functions:
  • 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
  • 27. From: http://pyovevit.blogspot.com/2008/10/open-group-architecture-framework-togaf.html
  • 28. Methodology Approach – Example #2 Federal Enterprise Architecture (FEA)
  • 29. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel:
  • 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
  • 31. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf 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)
  • 33. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Data Layer
  • 34. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf FEA Metamodel Services and Components 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
  • 36. http://www.whitehouse.gov/omb/egov/documents/FTF_Metamodel_Reference_Pilot_Final_December_2006.pdf Policies Standards FEA - interface with Policies and Standards
  • 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.