Ea Relationship To Security And The Enterprise V1

November 10, 2008 Page 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.


3 D’s

• Diplomacy

• Disclaimer

• Disclosure


Enterprise Architecturevs.

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




• EA:– Goals are stated as return on investment

(ROI), net present value (NPV), annual loss expectancy (ALE), etc.





• SA:– Goal stated as … what?


Enterprise Security ArchitectureGoal = 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

Pathologic Bureaucratic Generative

Don’t want to know May not find out Actively seek

Messengers “shot” Heard if they arrive Messengers rewarded

Responsibility shirked Compartmentalized Responsibility shared

Failure punished Local repairs only Failures beget reforms

Ideas discouraged Ideas beget problems Ideas welcomed

Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997


Risk Management Culture

Pathologic Bureaucratic Generative

Don’t want to know May not find out Actively seek

Messengers “shot” Heard if they arrive Messengers rewarded

Responsibility shirked Compartmentalized Responsibility shared

Failure punished Local repairs only Failures beget reforms

Ideas discouraged Ideas beget problems Ideas welcomed

Source: “Managing the Risks of Organizational Accidents”, J.T. Reason, Ashgate Publishing Ltd., 1997



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

Page 13


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



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



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



Identity Management

Authentication

AuthorizationStrategic Goal:

FIPS201

Tactical Alternatives (some examples):

One-Time-Password “Wired” Token w/PIN “Wireless” Token w/Biometric



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:

PRODUCTION

DESIGN RELATED ACTIVITIES

DEVELOPMENT ENVIRONMENTS (no production data)

TESTING ENVIRONMENTS (no production data)

Pre-Production: verification of production readiness. Also serves as a production look-alike for emergency patch testing and deployment)

User Acceptance

Testing (UAT/QA)

Certification Environment

Source Code Analysis built

into IDE

White-Box Application Scanning

results of code audits, QA tests, and root-cause

analyses

PER-PROJECT ACTIVITIES:Gather Business RequirementsPerform Risk Ranking Assessment (default=high)Select threat profiles, trust model, regulatory drivers, and information classificationPerform factor analysis, security policy design, information labeling, and tier analysisCreate Use Cases & Abuse Cases

PRE-DESIGN ACTIVITIES:Maintain Library of secure code samplesMaintain Library of standard security tools Maintain virtual SecDev “Center of Excellence” staffed with matrixed “Militia” of developersMaintain SW/HW Config StandardsMaintain SW/HW Architect StandardsDocument the maintenance, versioning, and code promotion processes and controlsCodify “Build vs. Buy” criteria & restrictionsTrain developers on Source Code Analyzer

Pre-Production Staging

Certification Environment: simulates production enclaves, load-balancers, and redundancy. Test failover, audit, logging, security mechanisms, etc. at full load. Code will require three Certificates of Security Assurance: Hardware Configuration Software Configuration Secure Code Config

User Training Environment

Production (with one or more

replicas)

Load Balancers

Application Firewalls

3rd Party Penetration

Testing

Integration Testing: test new components, test cohabitation with other co-resident applications, and regression testing of existing functionality

Project Team

Developer IDE

Unit Testing

Integration Testing

Black-Box Penetration

Testing

Design Review Board

DEFECT REPORTING FLOW

CODE PROMOTION FLOW

CONFIGURATION ACTIVITY

SECURITY SCANNING ACTIVITY

App

licat

ion

Dev

elop

me

nt S

ecur

ity R

evie

w B

oard

Enclave Firewalls

Intrusion Detection & Prevention Systems

Cha

nge

Con

trol

Bo

ard

SDLC PIPELINE


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:



This is the layer where policies, laws, regulations,

etc. impinge via the creation of Business

Requirements

FEA Metamodel

Strategy and Performance Layer



FEA Metamodel

Strategy and Performance Layer



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)



FEA Metamodel

Data Layer



FEA Metamodel

Services and Components Layer



This is where Technology

Standards impinge via use of existing

(or creation of new) Services and Components

FEA Metamodel

Technology Layer



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

Policy Architecture OperationsEngineeringDesign

• 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

Policy Architecture OperationsEngineeringDesign

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 segmentarchitecture 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

EnterpriseTransition Strategy


Roadmap(FEAF: “Transition Plan”)

Current State(FEAF: “Baseline”)

Mature Enterprise Architecture Practice

Desired Future State(FEAF: “Target”)

Policies

Standards

Policies

Standards

ArchitectureDeliverables


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.”



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]



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 ArchitectureDepartment 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 ModelBusiness Reference Model

103: Enterprise Architecture112: Policy and Guidance Development136: System Development137: Lifecycle/Change Management139: IT Infrastructure Maintenance140: Information Security263: System and Network Monitoring 302: Internal Risk Mgmt and Mitigation

Technical Reference ModelTechnical Reference Model

858: Virtual Private Network859: Legislative / Compliance860: Authentication / Single Sign-on862: Supporting Network Services (eg. LDAP, DNS, etc.)863: Service Transport (https, ipsec, etc.)867: Integrated Development Env. (IDE)868: Software Configuration Management869: Test Management884: Certificates / Digital Signatures885: Supporting Security Services (eg. s/MIME, TLS, SAML, etc.)896: Enterprise Application Integration (BPM)901: Service Description / Interface (SOA)

Performance Reference ModelPerformance Reference Model

445: Security446: Privacy471: Availability472: Reliability

Service Component Reference ModelService Component Reference Model

542: Risk Management543: Workgroup / Groupware582: Digital Rights Management640: Instrumentation and Testing641: Software Development648: Identification and Authentication649: Access Control650: Cryptography651: Digital Signature Management/PKI652: Intrusion Prevention653: Intrusion Detection654: Incident Response655: Audit Trail and Capture Analysis656: Certification and Accreditation657: FISMA Management and Reporting658: Virus Protection659: Email673: Community Management

FEA SECURITY ARCHITECTUREOrganized 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.