2010 ea conf ra track presentation 20100506

367 views

Published on

NSA presentation about PRISM

Published in: Education, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
367
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Architects = ERAC Architecture Owner = ESF SMEs = ESF, CI, COCOMS, JS, SVCs
  • The Enterprise-wide Access to Networks and Collaboration Services (EANCS) Reference Architecture (RA) is the first Department-level RA developed by the Enterprise Reference Architecture Cell (ERAC) for the DoD Chief Information Officer. The following slides describe the basis for the RA, its purpose and scope, the approach used in its development, its primary data sources, and the DoDAF architecture artifacts used in its description and their relationship to the five key elements of an RA. Slides also describe how the RA was aligned with the DoD Information Enterprise Architecture (DoD IEA) and how compliance with the DoD IEA was documented.
  • The goal of the EANCS RA is to assist ASD (NII)/DoD CIO in addressing warfighter requirements identified in the Global Information Grid (GIG) 2.0 Operational Reference Architecture (ORA), as expanded upon by the Vice Chairman of the Joint Chiefs of Staff (VCJCS). The GIG 2.0 ORA describes a key attribute for achieving and maintaining an information advantage for the warfighter as “Global Authentication, Access Control, and Directory Services.” Requirements for this attribute are that: Any authorized user, advantaged or disadvantaged, have one identity and be granted authorization and provided with seamless access to the information they need from anywhere, at any time. Commanders know and trust that their units have access to the information they need to conduct their missions and that proper visibility and oversight of access and authentication processes have been established. The VCJCS increased the urgency of this requirement by establishing an immediate need for DoD users to be able to “go anywhere in DoD, login, and be productive.” The EANCS RA was developed as the basis for an implementation roadmap to guide development/acquisition of key elements of the Enterprise Services Security Foundation (ESSF), which defines those security services needed in the DoD Information Enterprise (IE). To meet GIG 2.0 and VCJCS requirements he RA needed to describe authentication and authorization and access control required for a user, regardless of location, to obtain access to a specified set of designated, sometimes called “collaboration,” enterprise services on either NIPRNet or SIPRNet . The RA was to focus on network login, global authentication, and granting of authorization to just designated enterprise services. But it was also to be able to guide implementation of an initial authentication and authorization and access control capability within six to nine months of architecture completion to support the Enterprise User Initiative in providing a “real” capability to “go anywhere, login, and be productive.” Key characteristics of the architecture were to be use of : standard, common credentials for authentication (i.e., PKI/CAC for NIPRNet and PKI/hard token for SIPRNet) and authoritative identity attributes for authorization and access control using the Attribute Based Access Control (ABAC) concept.
  • The purpose of the EANCS RA is to describe the capability for accessing designated/collaboration services in support of secure information sharing across the Department. It provides architectural patterns to guide, standardize, and enable the most rapid and cost-effective implementation of global authentication and authorization and access control capabilities. The EANCS RA is a “to-be” architectural description of an objective capability and its associated requirements. It describes objective requirements, principles/rules, patterns, and technical positions for authentication and authorization and access control applicable across DoD. The RA’s description can be applied to selected use cases to develop specific implementation guidance for authentication and authorization based on a set of conditions described in a scenario or mission thread. The scope of the RA was limited to: Approved DoD Networks Authentication of designated users with portable identity credentials Access to designated, globally accessible enterprise services via end user devices that are hardwired (not wirelessly connected) to a network Control of access to designated enterprise services based on user attributes.
  • The Owner of the RA is the Enterprise Services and Integration (ES&I) directorate in the Office of the DoD Deputy CIO. The Architects were members of the ERAC in the Architecture and Infrastructure (A&I) Directorate, also in the Deputy CIO’s office. The Working Group (WG) was composed of representatives from: ASD(NII) and the Office of the Deputy CIO; Military Services; Joint Staff J6; Defense Information Systems Agency (DISA)/Enterprise User Initiative; National Security Agency (NSA); and the Defense Manpower Data Center (DMDC). The ERAC leveraged the six step architecture development method from the DoD Architecture Framework (DoDAF) v2.0 in developing the EANCS RA. The Purpose, Perspective, and Scope of the RA were first established in collaboration with the Architecture Owner and key members of the WG. The WG developed a Concept of Operations (CONOPS) for EANCS, which served as context for the RA and set boundaries for the architecture. The ERAC used existing documentation provided by the WG as authoritative baseline information for the RA; the remainder of the information needed for architecture development was then collected from Subject Matter Experts (SMEs), either WG members themselves or individuals made available by WG members from their parent organizations. Once sufficient architecture information had been collected, the ERAC organized that information into DoDAF 2.0 viewpoints and views and developed an RA document. The WG was involved in reviewing the document for content and the ERAC adjusted content in accordance with these reviews throughout architecture development. A Final Draft was submitted to the WG, and its content was approved by the Architecture Owner, in December 2009. The RA has since been submitted to the Architecture and Standards Review Group (ASRG) and is currently awaiting approval for federation into the DoD Enterprise Architecture (EA).
  • The content of the EANCS RA was extracted or derived primarily from four authoritative sources: Enterprise Security Management (ESM) Documents (Draft) – These documents, developed by NSA and based on the GIG Information Assurance (IA) Architecture, describe required functions and high level processes associated with ESM. These functions provide for dynamic IA services, processes, and devices to optimize the enterprise for mission operations. The EANCS RA used the ESM authentication and privilege management functions and related processes as the basis for process patterns. Global Information Grid (GIG) 2.0 Operational Reference Architecture (ORA) - Provides a decomposition of the activities associated with GIG 2.0 attributes. The EANCS RA used authentication and authorization activities from the GIG 2.0 ORA “Global Authentication, Access Control, and Directory Services” attribute as steps in process patterns. Enterprise Services Security Foundation (ESSF) Implementation Roadmap (Draft) - The unifying construct for aligning security-related efforts to enable the delivery of DoD Enterprise Service (ES) capabilities. This document provides a taxonomy and description for DoD security services. The EANCS RA used the ESSF Authentication and Authorization & Access Control services as the framework for its capability description. Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, v1.0 – This document outlines a common framework for ICAM within the Federal Government and provides supporting implementation guidance for program managers, leadership, and other stakeholders as they plan and execute segment architecture for ICAM management programs. The ESSF structure was based on the FICAM. The EANCS RA aligned with the FICAM to ensure the authentication and authorization and access control it described were compliant with Federal guidelines. Many of the Technical Positions in the RA were taken from the FICAM.
  • The resulting RA contains the five key elements of a Department-level RA, as shown in this diagram. Strategic Purpose consists of: AV-1 Overview and Summary Information : based on CONOPS with WG input and approval; describes scope and context for RA OV-1 High-Level Operational Concept: describes concept for authentication, and authorization and access control to enable requirement to login and be productive (access designated enterprise services) from anywhere in DoD; provides both a User/Consumer and a Service Provider perspective Principles are contained in: OV-6a Operational Rules Model: identifies principles and rules to constrain development of solutions; extracted from source documents and established during RA development Patterns consist of: OV-5a Operational Activity Decomposition Tree: organizes and defines activities required to accomplish operational concept; derived from GIG 2.0 ORA activities (Global Authentication, Access Control, and Directory Services pillar) and functions from draft Enterprise Security Management (ESM) documents OV-6c Event Trace Description (Process Pattern): describes process pattern for authentication and authorization and access control; uses activities from OV-5a Technical Positions are contained in: StdV-1 Standards Profile: list of high-level policies and standards that apply to authentication and authorization and access control; derived from Federal Identity, Credential, and Access Management (FICAM) Vocabulary consists of: AV-2 Integrated Dictionary: provides definitions for EANCS RA activities, process steps, swim lanes, and information elements
  • The EANCS RA was built with the DoD IEA and its description of net-centric concepts and requirements in mind. The result is a description of authentication and authorization and access control services that can operate effectively in the net-centric DoD IE.
  • The next two slides describe how the EANCS RA was developed in line with the DoD IEA. As the ERAC worked with the Architecture Owner to establish purpose, perspective, and scope for the RA, it also reviewed the DoD IEA, related net-centric concepts, and the DoD net-centric vision to understand how EANCS should operate in a net-centric DoD IE. During this assessment, it was determined the DoD IEA Priority Areas of Secured Availability (SA) and Data and Services Deployment (DSD) were most applicable to the RA – authentication and authorization and access control are key enablers of SA and are to be delivered as services in the ESSF, with a need to conform to DSD. To address SA principles and rules, two net-centric assumptions, as shown, were incorporated into the AV-1 for the RA. The CONOPS developed by the EANCS WG took the perspective of a user who needs access to a network and enterprise services while away from his home station. In order to describe how authentication and authorization and access control services would need to operate to enable this requirement, the EANCS RA needed to extend this perspective to include that of providers of these two services. A net-centric operational concept with these two perspectives was developed as part of the RA’s Strategic Purpose. This CONOPS includes the two OV-1s shown. At the same time, the ERAC assessed which of the JCAs authentication and authorization and access control would enable. It was determined the RA was primarily describing services enabling the Tier 4 JCA of User Access within the Net-Centric/Enterprise Services/Core Enterprise Services JCA. However, these services would also indirectly enable the Tier 3 JCAs subordinate to the Net-Centric/ Information Assurance JCA: Secure Information Exchange, Protect Data and Networks, and Respond to Attack/Event. The scope associated with these JCAs was built into the RA and its description shows how authentication and authorization and access control address these related capabilities.
  • The ERAC developed a set of guiding principles and rules from key authoritative sources to provide context and constrain and direct development of the RA. These principles and rules were used as constraints in developing the OV-1 high-level operational concept graphic, the OV-5a activity decomposition, and the OV-6c process patterns in the RA. They also are designed to influence and direct development of follow-on implementation guidance and solution architectures. The RA’s Guiding Principles and Rules incorporate one Global Principle, one SA Principle, one DSD Rule, and one SA Rule from the DoD IEA. The process patterns in the RA were determined to align with three activities in the DoD IEA: A2.8.4 Oversee Authentication Processes and its sole child activity A2.8.4.1 Manage Authentication Processes enable and constrain the authentication process in the RA. The Oversee Authentication Processes activity constrains development of mechanisms that perform authentication; in doing so, it determines how the authentication process pattern in the RA can be done. SA authorities will “identify, test, and certify” any of these authentication mechanisms in accordance with the Manage Authentication Processes activity to ensure they meet specific requirements from the parent activity. A2.8.5 Oversee Privilege Management Initiative enables and constrains the authorization and access control process. SA authorities use this activity “to develop and maintain an attribute management infrastructure for the Department.” Such an infrastructure is essential for carrying out authorization and access control in a net-centric DoD IE. By governing available attributes and associated mechanisms enabling authorization and access control, the DoD IEA activity constrains how the process steps defined in the RA can be carried out. Net-centric terminology from the DoD IEA was incorporated throughout the RA description. In particular, the RA uses this terminology in discussing the DoD Net-Centric vision and how it applies, the perspectives the RA takes of the DoD IE, and the DSD and SA priority areas and their role in constraining EANCS operations.
  • To make compliance with the DoD IEA visible to users and reviewers and to ensure it was understood how solutions guided by the RA are to comply with the DoD IEA, two sections dealing with DoD IEA alignment were specifically added to the RA Document: A section describing RA alignment with JCAs and the DoD IEA Priority Areas was added to Section 2 Context. Text descriptions for how process patterns align with selected DoD IEA activities were added to Section 4.2.2 Authentication Process Pattern and 4.2.3 Authorization and Access Control Process Pattern. For Assessment purposes, the Tab A table in DoD IEA Appendix E was used as a template in completing a Compliance Matrix for the EANCS RA. In addition, the Enhanced Information Support Plan (EISP) tool was used to develop an ISP excerpt for the RA addressing DoD IEA alignment. The “Guidance for DoD Information Enterprise Architecture in EISP 2.0” document was used to determine the questions that needed to be answered to make DoD IEA compliance visible. Information and text from the RA document was then inserted into the tool in the proper places to answer these questions. When this was complete, a Compliance Matrix was generated using the reporting application for EISP and the appropriate style sheet.
  • FOR OFFICIAL USE ONLY FOR OFFICIAL USE ONLY
  • FOR OFFICIAL USE ONLY FOR OFFICIAL USE ONLY
  • 2010 ea conf ra track presentation 20100506

    1. 1. Reference Architecture Track Terry Hagle, Office of DoD CIO/AS&I 703-607-0235 terry.hagle@osd.mil 2010 EA Conference
    2. 2. Agenda  Enterprise Reference Architecture Cell (ERAC) Overview – Terry Hagle  Reference Architecture (RA)– Steve Ring – Principles – Technical Positions – Patterns  Enterprise-wide Access to Network and Collaboration Services (EANCS) RA – Norm Minekime  DoD Information Enterprise Architecture (IEA) – Al Mazyck – Purpose/Background – Content – Application of the DoD IEA • Example EANCS RA – Compliance with the DoD IEA • Example EANCS RA 2
    3. 3. ERAC OVERVIEW 3
    4. 4. Enterprise Reference Architecture Cell (ERAC)  Components have expressed the need for more detailed guidance – Enterprise patterns and processes – Army CIO/G-6 Comment on DoD IEA v1.1: “…establish a separate DoD IEA Reference Architecture with sufficient granularity to enable interoperability across the DOD IE/GIG. To foster such interoperability, these reference architectures would need to include processes, process patterns and service patterns, as well as service interfaces and metrics.”  Purpose: – Develop the reference architecture (artifacts) – Assist IT Decision Makers/Components/Programs/Solution Architects as directed • Work as an advisor to the functional architect • Assist in the proper application of the DoD IEA, DoDAF and DARS – Conduct architecture assessments as directed • Assess architecture compliance w/DoD IEA • Event Driven - Net Centric Reviews (ED-NCR) • JCIDS/DAS Milestone Reviews  Management: – ERAC funded by and resources managed by EA&S – Taskings and guidance from the EGB/ASRG 4
    5. 5. Enterprise Reference Architecture Mission Statement  The intent of Reference Architecture is to: Normalize the institutional understanding of capabilities at the enterprise level and provide a common set of principles, patterns, and technical positions for use within the DoD to guide development of Enterprise, Segment, or Solution architectures.  Development of a Reference Architecture is a process that results in the required content 5
    6. 6. Reference Architecture Description  Five components of a Reference Architecture: – Strategic Purpose • Describes the context, scope, goals, purpose, and intended use of the RA – Principles • High-level statements about the IT environment that tie back to business goals • Incorporate values, organizational culture, and business goals • Drive Technical Positions (and Patterns) – Technical Positions • Statements that provide technical guidance (standards, technologies, etc) for use with each major architectural component or service – Patterns/Templates • Diagrams that address the distribution of systems functions and how they relate topologically • Models that show relationships between components specified by the Technical Positions – Vocabulary  Reference Architecture Description 6
    7. 7. ERAC Process for Developing RA  The ERAC leverages the six step architecture development process of the DoDAF  The process steps are: – Clarify Purpose (Architects & Architecture Owner) – Clarify Scope (Architects & Architecture Owner) – Identify key questions (Architects & Architecture Owner) – Determine required data/information (architects) – Collect and Organize data/information (architects collect & organize, SMEs provide) – Analyze architecture data/information (architects) – Document the results (architects) – Use or apply results (Architecture Owner) 7
    8. 8. Proposed RA Product Structure  DoDAF Models to Be Developed: AV-1, AV-2, OV-1, OV-5a, OV-6a/c, and StdV-1  Overview and Summary Information (AV-1) – Contract between Architecture Owner and Architect – Guides development of the RA – Executive level presentation of RA – DM2: Vocabulary and Semantics  Reference Architecture Document – Introduction (Content from AV-1) – Context and Relationships (Resulting Principles) – Term Definitions – Architectural Patterns – Generic Standards and profiles – policy – Use Case/Use Case Analysis o Implementation Specifics o Specific Technical Standards and Profiles o Deployment and Performance Considerations 8
    9. 9. http://cio-nii.defense.gov/sites/diea/ DoD IEA Website 9
    10. 10. REFERENCE ARCHITECTURE 10
    11. 11. Purpose  DoD CIO intends to use Reference Architecture as a means to provide Department-wide Guidance for architectures and solutions  Reference Architecture, as currently used within DoD…  Is defined at different levels of detail and abstraction (from specific to generalized) with…  Has little agreement and much confusion  Has multiple meanings relative to the context of the environment  To support the DoD CIO intent, a common definition of Reference Architecture is needed that…  Provides policy and direction to the DoD enterprise (commands, services, agencies) that guides and constrains architectures and solutions  Can be equally applied across the wide spectrum of DoD environments  IT/ Business and Service (SOA) domains  Warfighter domains 11
    12. 12. Objectives of a Reference Architecture  To direct, guide and constrain architectures and solutions within a domain  To serve as a reference foundation of concepts, components and their relationships  May be used for comparison and alignment purposes Reference ArchitectureReference Architecture Stakeholder Requirements Guides and constrains the development of ArchitecturesArchitectures andand SolutionsSolutions Diagram derived from: The Importance of Reference Architecture, Architecture and Change (A&C), 2007, http://www.architectureandchange.com/2007/12/29/the-importance-of-reference-architecture 12
    13. 13. Reference Architecture is… an authoritative source of unambiguous architecture information within a domain environment … … that guides and constrains multiple architectures and solutions… … by providing patterns of abstract architectural elements, based on a strategic purpose, principles, technical positions, together with a common vocabulary. 13
    14. 14. DomainDomain Building a Reference Architecture (The Five Components) Reference Architecture Components PrinciplesPrinciples Patterns Vocabulary TechnicalTechnical PositionsPositions Strategic Purpose Architecture/Architecture/ SolutionSolution “A” Guides Constrains Authoritative Source Architecture/Architecture/ SolutionSolution “B” 14
    15. 15. DoDAF Models Utilized in RAAV-1 Overview & Summary Information CV-1: Vision – overall strategic concept and high level scope OV-1 High Level Operational Concept Graphic – what solution architectures are intended to do and how they are supposed to do it OV-6a Operational Rules Model SvcV-10a Services Rules Model SV-10a Systems Rules Model OV-4 Organizational Relationships Chart – architectural stakeholders StdV-1 Standards Profile Operational Patterns OV-2 Operational Resource Flows OV-5 {a,b} Activity diagrams Service Patterns SvcV-1 Service Interfaces SvcV-2 Service Resource Flows SvcV-4 Service Functionality SvcV-10b Service State Transitions System Patterns SV-1 System Interfaces SV-2 System Resource Flows SV-4 System Functionality SV-10b System State Transitions Event-Based Scenario Patterns of Dynamic Behavior OV-6c Event-Trace Description SvcV-10c Services Event-Trace Description SV-10c Systems Event-Trace Description AV-2 Integrated Dictionary- definitions of terms used throughout solution architectures Strategic Purpose Technical Positions PrinciplesPrinciples Patterns 15
    16. 16. Benefits  Authoritative source of architecture information within a problem space that guides and constrains architectures and solutions  Simplifies and standardizes solutions for complex problems by providing common repeatable patterns  Provides early, focused guidance at a sufficient level of abstraction and detail before concrete implementation decisions are known  A tool to ensure interoperable architectures and solutions based on common guidance 16
    17. 17. First Usage: EANCS Reference Architecture  Supports development of EANCS implementation guidance and solution architectures  “…focuses on that portion of the characteristic dealing with global authentication, authorization and access control to globally accessible resources. It is intended to guide the development of solution architectures and support the development of specific implementation guidance for achieving this capability.” DRAFT 1 2 Department of Defense3 4 Enterprise-wide Access to Network and5 Collaboration Services (EANCS)6 7 Reference Architecture8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Version 3.025 26 December 200927 28 Prepared by the Office of the DoD CIO29 17
    18. 18. Enterprise-wide Access to Networks and Collaboration Services (EANCS) Reference Architecture (RA) 18
    19. 19. EANCS RA Background  Operational Requirements – GIG 2.0 Operational Reference Architecture (ORA) describes requirement for “Global Authentication, Access Control, and Directory Services” – Vice Chairman Joint Chiefs of Staff (VCJCS) directed ability to “go anywhere [in DoD], login, and be productive”  EANCS RA to address these requirements by: – Providing basis for implementation guidance/roadmap for Enterprise Services Security Foundation (ESSF) – Describing Authentication and Authorization and Access Control to networks (NIPRNet and SIPRNet) and designated Enterprise Services (e.g., Enterprise Directory Service, Enterprise e-mail, DCO, Intelink) – Supporting implementation of an initial authentication and access control capability in 6 to 9 months for Enterprise User Initiative – Leveraging: • Common credentials for authentication (PKI/CAC for NIPR, PKI/hard-token for SIPR) • Authoritative identity attributes for authorization and access control (Attribute-Based Access Control) 19
    20. 20. EANCS RA Purpose and Scope  Purpose – Gain Department-wide consensus on requirements for authenticating users and authorizing user access to DoD Information Enterprise (IE) and, more specifically, to representative collaborative services, to include portals and enterprise e-mail – Describe architectural patterns to guide, standardize, and enable the most rapid and cost-effective implementations of an authentication and authorization capability in support of secure information sharing across DoD  Scope – “To − Be” Architectural Description – Document requirements, activities, and information for authentication and authorization and access control – Document “standard/common” authentication and authorization and access control processes 20
    21. 21. EANCS RA Development Approach  Architecture Owner organized Working Group (WG) – Composed of SMEs from ASD (NII)/CIO, Military Services, Joint Staff/J6, Defense Manpower Data Center (DMDC), Defense Information Systems Agency (DISA), and National Security Agency (NSA) – Team members represented their stakeholder organizations  Architecture Owner worked with ERAC to establish RA purpose, perspective, and scope  WG developed Concept of Operations (CONOPS) for context  WG provided necessary architecture data/information – Existing documents served as knowledge baseline – SME knowledge and experience provided rest of information  ERAC organized collected data into DoDAF-compliant RA description  WG approved RA content (Dec 2009)  Submitted to Architecture and Standards Review Group (ASRG) for approval and federation into DoD EA 21
    22. 22. EANCS RA Sources FederalFederal ICAMICAM ESSFESSF GIG 2.0GIG 2.0 ORAORA EANCSEANCS RARA EANCSEANCS CONOPSCONOPS USEUSE CASESCASES ESMESM IMPIMP PLANPLAN IMPIMP PLANPLANIMPIMP PLANPLAN Process & Function Operational Requirements - Patterns - Rules - Technical Positions - Operational Requirements - Implementation Considerations Provide Analysis - NIPRnet - SIPRnet - Deployed User - Unanticipated User - Maritime User - VPN - ??? Service Descriptions - 6 to 9 months - Longer Period - Impacts - Metrics - Guidance “What” To Do “How” To Do It 22 Legend •ESSF – Enterprise Security Services Framework •ESM – Enterprise Security Management •ICAM – Identity, Credential, and Access Management •ORA -Operational Reference Architecture
    23. 23. EANCS RA Architecture Artifacts 23 OV-1 (Concept – Consumer & Provider) OV-5a (Activity Decomposition) OV-6a (Operational Rules Model) OV-6c (Event-Trace Description) EANCSRADocument DRAFT 1 2 Department of Defense3 4 Enterprise-wide Access to Network and5 Collaboration Services (EANCS)6 7 Reference Architecture8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Version 3.025 26 December 200927 28 Prepared by the Office of the DoD CIO29 EANCS RA StdV-1 Standards Profile GROUP TYPE NAME DESCRIPTION OMB Policy M-04-04 This guidance requires agencies to review new and existing electronic transactions to ensure that authentication processes provide the appropriate level of assurance. It establishes and describes four levels of identity assurance for electronic transactions requiring authentication. Assurance levels also provide a basis for assessing Credential Service Providers (CSPs) on behalf of Federal agencies. This document will assist agencies in determining their e- government needs. Agency business-process owners bear the primary responsibility to identify assurance levels and strategies for providing them. This responsibility extends to electronic authentication systems. OMB Policy M-05-05 This memo requires the use of a shared service provider to mitigate the risk of commercial managed services for public key infrastructure (PKI) and electronic signatures. OMB Policy M-05-24 This memorandum provides implementing instructions for HSPD-12 and FIPS-201. OMB Policy M-06-18 This memorandum provides updated direction for the acquisition of products and services for the implementation of Homeland Security Presidential Directive-12 (HSPD-12) “Policy for a Common Identification Standard for Federal Employees and Contractors” and also provides status of implementation efforts. Presidential Directive Policy HSPD-12 HSPD-12 calls for a mandatory, government- wide standard for secure and reliable forms of ID issued by the federal government to its employees and employees of federal contractors for access to federally-controlled facilities and networks. NIST Guidance SP 800-87 This document provides the organizational codes for federal agencies to establish the Federal Agency Smart Credential Number (FASC-N) that is required to be included in the FIPS 201 Card Holder Unique Identifier. SP 800-87 is a companion document to FIPS 201. StdV-1 (Standards Profile)Provides Department- level guidance for implementation of common access control elements Architecture Federation Enterprise-wide Access to Network and Collaboration Services Reference Architecture Overview and Summary Information (AV-1) 1 Architecture Product Identification 1.1 Name: Enterprise-wide Access to Network and Collaboration Services (EANCS) 1.2 Lead Organization: Department of Defense Deputy Chief Information Officer. The Enterprise Services Review Group (ESRG), as the architecture owner, is responsible for architecture content and will provide overall coordination to ensure appropriate stakeholders and subject-matter experts are available; the Enterprise Reference Architecture Cell (ERAC), with oversight from the Architecture and Standards Review Group (ASRG), will support the development of appropriate architecture artifacts. 1.3 Approval Authority: DoD CIO Enterprise Guidance Board (EGB) 2 Purpose and Perspective 2.1 Purpose. A Reference Architecture (RA) abstracts and normalizes the institutional understanding of capabilities at the enterprise level, and provides a common set of principles, technical positions, and patterns for use within the DoD to guide development of Enterprise, Segment, or Solution architectures. AV-1 (Overview and Summary) Strategic Purpose Principles Patterns Technical Positions AV-2 (Integrated Dictionary) Vocabulary
    24. 24. Compliance with DoD IEA  Development of RA guided by Department’s Net-centric vision “to function as one unified DoD Enterprise, creating an information advantage” for DoD, its people, and its mission partners, as described in DoD IEA  Alignment with DoD IEA “built-in” during RA development IAW DoD IEA Appendix D  Compliance with DoD IEA documented in IAW DoD IEA Appendix E 24
    25. 25. DoD Information Enterprise Architecture (IEA) 25
    26. 26. Purpose  Unify the concepts embedded in the DoD’s net- centric strategies into a common vision  Drive common solutions and promote consistency  Describe the integrated Defense Information Enterprise and the rules for information assets and resources that enable it  Foster alignment of DoD architectures with the enterprise net-centric vision DoD Net-centric Vision To function as one unified DoD Enterprise, creating an information advantage for our people and mission partners by providing: A rich information sharing environment in which data and services are visible, accessible, understandable, and trusted across the enterprise. An available and protected network infrastructure (the GIG) that enables responsive information-centric operations using dynamic and interoperable communications and computing capabilities. 26
    27. 27. Background  Major Net-Centric Strategies  DoD IEA v1.0 (Approved 11 April 2008) – Established five priority areas for realizing net-centric goals – Provided key principles, rules, and activities for priority areas – Positioned as a tool to guide the net-centric transformation of the Information Enterprise (IE)  DoD IEA v1.1 (Approved 27 May 2009) – Describes a process for applying the DoD IEA content (App D) – Describes compliance areas and criteria (App E) – Provides activity mapping between the DoD IEA and the NCOW RM (App F) 27 • Data (9 May 2003) • Spectrum Management (3 Aug 2006) • Services (4 May 2007) • NetOps (February 2008) • Information Assurance (26 April 2006) • Communications/Transport • Computing Infrastructure (September 2007) • Information Sharing (4 May 2007)
    28. 28. Audience & Intended Use  IT Architects – Align architecture with the DoD IEA – Apply DoD IEA content (rules, activities, etc) to guide and constrain information enterprise solutions  Managers of IT Programs (PM, PEO, etc.) – Use the DoD IEA to support program design, development, and implementation – Through solution architectures properly aligned with the DoD IEA  IT Decision-Makers (CPM, IRB, CIO, etc.) – Use the DoD IEA to support investment decisions – Through enterprise and solution architectures properly aligned with the DoD IEA 28
    29. 29.  Adds DoD EA Compliance Requirements (Appendix G) – Compliance with DoD IEA – Compliance with Capability and Component EAs – Compliance with the DISR – Compliance with Mandatory Core and Shared Designated DoD Enterprise Services (ES) – Architecture Registration Requirements  Provides a table of Mandatory Core and Shared Designated DoD ES  Adds content to the Rules, App D, and App E to maintain consistency with App G DoD IEA v1.2 (Draft) 29
    30. 30. Applying the DoD IEA (Appendix D) 30
    31. 31. Applying the DoD IEA Establish Net Centric Context for EANCS RA 31 Consumer/ User Perspective  Identify DoD IE Perspective for Architecture  Develop Net-Centric Operational Concept Provider/ Producer Perspective  Understand Net-Centric Concepts  Align with Net-Centric Vision  Identify Net-Centric Assumptions  Align with JCA Taxonomy Net-Centric Assumptions  Portable identity credentials will be used to support user authentication  Authorization attributes have already been defined, collected, regularly updated, and made available through standard interfaces from reliable attribute sources Net-Centric Assumptions  Portable identity credentials will be used to support user authentication  Authorization attributes have already been defined, collected, regularly updated, and made available through standard interfaces from reliable attribute sources Relevant DoD IEA Priority Areas  Secured Availability (SA)  Data and Services Deployment (DSD) Relevant DoD IEA Priority Areas  Secured Availability (SA)  Data and Services Deployment (DSD) Relevant JCAs  Net-Centric/Enterprise Services/Core Enterprise Services/User Access Relevant JCAs  Net-Centric/Enterprise Services/Core Enterprise Services/User Access  OV-1 (Operational Concept Graphic)
    32. 32. Applying the DoD IEA Align EANCS RA Description with DoD IEA 32  Align Operational Activities and Processes with related DoD IEA Activities  Incorporate applicable DoD IEA Principles  Apply DoD IEA Rules  Use net-centric terminology in architecture description Guiding Principles and Rules for RA  Data assets, services, and applications on the GIG shall be visible, accessible, understandable, and trusted to authorized (including unanticipated) users. (DoD IEA, GP 03)  Global missions and globally dispersed users require global network reach. Information Assurance mechanisms and processes must be designed, implemented, and operated so as to enable a seamless Defense Information Enterprise. (DoD IEA, SAP 03)  Authoritative data assets, services, and applications shall be accessible to all authorized users in the Department of Defense, and accessible except where limited by law, policy, security classification, or operational necessity. (DoD IEA, DSDR 01)  All DoD information services and applications must uniquely and persistently digitally identify and authenticate users and devices. These services, applications, and networks shall enforce authorized access to information and other services or devices according to specified access control rules and quality of protection requirements for all individuals, organizations, COIs, automated services, and devices. (DoD IEA, SAR 07) Guiding Principles and Rules for RA  Data assets, services, and applications on the GIG shall be visible, accessible, understandable, and trusted to authorized (including unanticipated) users. (DoD IEA, GP 03)  Global missions and globally dispersed users require global network reach. Information Assurance mechanisms and processes must be designed, implemented, and operated so as to enable a seamless Defense Information Enterprise. (DoD IEA, SAP 03)  Authoritative data assets, services, and applications shall be accessible to all authorized users in the Department of Defense, and accessible except where limited by law, policy, security classification, or operational necessity. (DoD IEA, DSDR 01)  All DoD information services and applications must uniquely and persistently digitally identify and authenticate users and devices. These services, applications, and networks shall enforce authorized access to information and other services or devices according to specified access control rules and quality of protection requirements for all individuals, organizations, COIs, automated services, and devices. (DoD IEA, SAR 07) OV-6c (Event-Trace Description) Oversee Authentication Initiatives Manage Authentication Processes A2.8.4 A2.8.4.1 Oversee Privilege Mgmt Initiatives A2.8.5 Constrain DoD IEA Terminology  DoD Net-Centric Vision  DoD IE Perspective – User/Consumer – Producer/Provider  Priority Areas – Data and Services Deployment – Secured Availability DoD IEA Terminology  DoD Net-Centric Vision  DoD IE Perspective – User/Consumer – Producer/Provider  Priority Areas – Data and Services Deployment – Secured Availability
    33. 33. Compliance with the DoD IEA (Appendix E)  Compliance is about conveying the application of DoD IEA Principles, Rules, and Activities  Use the process described in App D and provided in App E, Tab A  Questions that expose the compliance process and application of DoD IEA content are captured in the Enhanced ISP tool  Assessment of compliance is based on: – Completed Compliance table – ISP and Architecture – EISP Report 33
    34. 34. Compliance w/the DoD IEA 34 Tab A to Appendix E: DoD IEA Compliance Assessment Table B. Align Architecture Description with the DoD IEA B1. Use Net- Centric Terminology 2.3.2.1.1 Use key terms contained in the DoD IEA Glossary across architecture descriptions. 2.1.1.2.1 Describe applicable DoD IEA key terms. Describe in the: - AV-2 Integrated Dictionary. - Related taxonomies. - ISP descriptions of the IE. Q12 - Identify key terminology from the DoD IEA used in your architecture/program documents. B2. Incorporate Applicable DoD IEA Principles 2.3.2.2.1 - Identify applicable DoD IEA Principles and use in architecture descriptions to place restrictions or limitations on operations. - Use applicable Principles… 2.1.1.2.2 Describe DoD IEA Principles. Describe in the: - OV-1 Operational Concept. - OV-5 Operational Activity Model. - Process Models Q13 - Which DoD IEA Principles apply to your Program? Q14 - How do the Principles apply to your Program? Q15 - How are the applicable Principles addressed in your architecture/program documents?
    35. 35. Compliance with the DoD IEA EANCS RA Example 35  Incorporated description of key alignment aspects into RA document – Added section describing RA alignment with JCAs and DoD IEA Priority Areas – Added text descriptions of how process patterns align with DoD IEA activities into pattern discussions  Filled out Tab A Compliance Matrix for RA  Developed eISP excerpt for RA – Used “Guidance for DoD Information Enterprise Architecture in EISP 2.0” to identify and locate DoD IEA questions to be answered – Incorporated information and text from RA document – Generated compliance matrix using Xml2PDF 2007 application and ISP_DoD_IEA_Compliance_Table style sheet
    36. 36. Initiatives and Projects  Reference Architecture Description – Comment Adjudication for ASRG Approval  DoD IEA – Comment Adjudication (v1.2) for DCIO Approval – Work on future versions of the DoD IEA  EANCS RA – Delivered to owner; now in FAC/ASRG approval process  Document Process for Developing RA – Describe the process used to develop the EANCS RA  FEA BRM Extension – Extend DoD LOBs for the FEA BRM – Recommended changes provided to OMB FEA for action 36
    37. 37. DoD IEA Site: http://cio-nii.defense.gov/sites/diea/ Questions? 37
    38. 38. BACKUP SLIDES 38
    39. 39. Information Enterprise Services and Infrastructure Architecture July 2, 2013
    40. 40. Human Computer Interaction WarfighterWarfighter Defense Intel Defense Intel NetOpsNetOps Mission Partners Mission Partners BusinessBusinessBusinessBusiness IA Infrastructure • Dynamic Policy Management • Assured Resource Allocation • Mgmt of IA Assets and Mechanisms NetOps Infrastructure • Enterprise Management • Content Management • Net Assurance Functional Capability Enterprise Services Mandatory Core & Shared Enterprise Services (ES) Computing & Communications Infrastructure Enterprise Services Security Foundation Information Sharing Messaging Portal Collaboration Mediation Content Delivery Enterprise Management Services Management Resource Management Content Handling IE Service/Infrastructure Context Diagram 40 Discovery People/Service Discovery Content Discovery Metadata Discovery Geospatial Visualization Mission & Business IT Enterprise Services & Infrastructure DRAFT Digital Identity Privilege Management Credentialing Authentication Authorization & Access Auditing & Reporting Cryptography Configuration Management Computer Network Defense COOP/CIP Force Application Portfolio Building Partnerships Portfolio Battlespace Awareness Portfolio Protection Portfolio Corporate Mgmt & Support Portfolio Force Support Portfolio Command & Control Portfolio Logistics Portfolio
    41. 41. Use Enterprise Services Framework to Organize and Focus ES Efforts Enterprise Services Security Foundation (ESSF) 41
    42. 42. Use ESSF Segment Architecture to Organize and Focus Security Efforts 42
    43. 43. Development Approach  Describe the components of the context diagram  Build use cases based on GIG 2.0 Attributes to establish relationships between its functional components (Mandatory Core & Shared Enterprise Services) – Global Authentication, Access Control, and Directory Services – Information and Services From The Edge – Joint Infrastructure – Common Policies and Standards – Unity of Command  Analyze use cases through identification, sequencing, and prioritization of functional components to develop key or foundational Services first  Apply analysis to prioritize and manage: – Reference Architecture Development (Principles, Technical Positions, Patterns) – Sequence and Monitor Initiatives, Projects, and Programs – Identify Issues, Gaps, and Shortfalls 43
    44. 44. Apply Enterprise Services & Infrastructure to GIG 2.0 Requirements through Use Cases 44 EnterpriseSecurity ServicesFoundation Computing & Communications Infrastructure
    45. 45. User 45 Local Access Request (Logon) End User Device (EUD) Authorization Decision Request ESSF Authentication ESSF Digital IdentityESSF Credentialing Credential Validation Response Identity Information Secondary Authentication (if required) ESSF Authorization & Access Control Mission Manager Environmental Data Response User Attribute Response Resource Access Policy Response Policy Management Portable Identity Credential Identity Updates + Authentication Factors Authentication Decision Response Resource Metadata Response Policy Constrained Access Printer Capability StoragStorag ee Office Automation Applications e-Mail Collaboration Document Sharing Portal Enterprise Directory Desktop/ Browser Indicates Dependency Collaboration ServicesCollaboration Services Use Case Example (EANCS)
    46. 46. Sample Use Case (Content Request) User Porta l Information Sharing Enterprise Services Security Framework Authenticatio n 1 2 Discovery Enterprise Management Content Discover y 3 Content Mgmt Mediation Content Delivery 4 Authorization & Access Control 5 6 7 8 9 10 Infrastructure 46
    47. 47. Human Computer Interaction WarfighterWarfighter Defense Intel Defense Intel NetOpsNetOps Mission Partners Mission Partners BusinessBusinessBusinessBusiness IA Infrastructure • Dynamic Policy Management • Assured Resource Allocation • Mgmt of IA Assets and Mechanisms NetOps Infrastructure • Enterprise Management • Content Management • Net Assurance Functional Capability Enterprise Services Mandatory Core & Shared Enterprise Services (ES) Computing & Communications Infrastructure Force Application Portfolio Building Partnerships Portfolio Battlespace Awareness Portfolio Protection Portfolio Corporate Mgmt & Support Portfolio Force Support Portfolio Command & Control Portfolio Logistics Portfolio Enterprise Services Security Foundation Information Sharing Messaging Portal Collaboration Mediation Content Delivery Enterprise Management Services Management Resource Management Content Handling IE Service/Infrastructure Context Diagram 47 Discovery People/Service Discovery Content Discovery Metadata Discovery Geospatial Visualization Mission & Business IT Enterprise Services & Infrastructure DRAFT Digital Identity Privilege Management Credentialing Authentication Authorization & Access Auditing & Reporting Cryptography Configuration Management Computer Network Defense COOP/CIP EANC S RA EU ITI Opt Arch AD Opt Arch SAR SA

    ×