UNCLASSIFIED UNCLASSIFIED Horizontal Fusion Security Architecture


Published on

  • 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

No notes for slide
  • User calls up browser, which presents User’s certificate to the portal (soft, CAC, or otherwise) Portal calls Certificate Validation Service, comparing the cert to the Certificate Revocation List downloaded for that day. Assuming it passes, it makes a call to the GDS to obtain the information it will place in the SAML assertion—dn (distinguished name), role, clearance. The client handler creates a SOAP message that contains the SAML assertion, the request, and signs/encrypts it with the portal’s digital cert. Service Provider A’s server handler calls the CVS and validates the portal’s signature (first checking the local cache to see if it has validated this cert recently—v0.4 optimization. Service Provider makes a tagged/labelled call (signed/encrypted by its server certificate) to the Policy Decision Service (which first checks local cache to see it has recently queried policy—Optimization in v0.4) to determine if user can access the service. PDS decrypts/validates signature looks up access in its XACML store, and provides a tagged/signed/encrypted response. Service A decrypts/validates the PDS’ signature, and allows/denies access to the service. The webservice, assuming appropriate permissions, returns the data requested. If the service requested was a post request, and it was validated, the portal will digitally sign and encrypt the file, and the backend service will accept it and store the data accordingly. If another call to yet another service provider’s service is required, service provider A will take the original user info from the SAML assertion, digitally sign it, and pass it on to another service. In all cases, at each step, the following will be audited: Service access and time (Success, Failure), {which maps to original DCID requirements of Login (Success, Failure), Logout (Success)}, Use of Privileged Commands (Failure), Application and Session Initiation (Failure), Use of Print Command (Success), DAC Permission Modification (Success, Failure), Export to Media (success), Unauthorized Access attempts to Files (Failure), System startup/Shutdown (Success and Failure)
  • UNCLASSIFIED UNCLASSIFIED Horizontal Fusion Security Architecture

    1. 1. Horizontal Fusion Security Architecture Les Owens HF Management Team
    2. 2. Outline <ul><li>Underlying Security Philosophy </li></ul><ul><li>Driving Security Policies </li></ul><ul><li>Key Security Technologies </li></ul><ul><li>Technical and Security Standards </li></ul><ul><li>Conceptual Security Architecture </li></ul><ul><li>FY05 and Beyond </li></ul>
    3. 3. Security Philosophy <ul><li>Build upon Service-Oriented Architecture (SOA) </li></ul><ul><li>Extend and adapt commercial best practices to the government Net-centric environment </li></ul><ul><li>Use decentralized security to all components of the architecture and move security closer to the edge </li></ul><ul><li>Employ security Defense-in-Depth approach </li></ul><ul><li>Move away from “the way its always been done” </li></ul><ul><li>Prudently apply security policy in a Net-centric environment </li></ul>Risk Management not Risk Avoidance
    4. 4. Major Security Policies Embraced by HF DCID 6/3 DoDD 8100.2 DoDI 8540.aa DoDI 8500.2 DoDD 8500.1 FIPS140-2 Driving Security Policies
    5. 5. Security Roles & Responsibilities <ul><li>These security policies identify the Information Assurance/security requirements that must be addressed by: </li></ul><ul><li>Collateral Space </li></ul><ul><li>Core Enterprise Services </li></ul><ul><li>Horizontal Fusion Initiatives/Capabilities </li></ul><ul><li>SIPRNET Backbone </li></ul><ul><li>DoD/IC Facilities/Sites </li></ul>
    6. 6. Targeted Security Requirements <ul><li>Based on DCID 6/3 and DoDI 8500.2 </li></ul><ul><li>For DCID 6/3 goal is to meet Protection Level 5 (PL5) requirements </li></ul><ul><li>For DoDI 8500.2 goal is to meet Mission Assurance Category II and Confidentiality Level High requirements </li></ul><ul><li>For FY04 we will achieve PL3 with some PL4 and PL5 compliance within some areas </li></ul>Confidentiality Availability Integrity
    7. 7. Confidentiality Controls (1) <ul><li>Provide Access Control through: </li></ul><ul><ul><li>Metadata tag (with Classification Attribute) is applied to all objects </li></ul></ul><ul><ul><li>Digital signature is applied to object and tag </li></ul></ul><ul><ul><li>Changes to the Metadata tag are audited </li></ul></ul><ul><ul><li>The NCES Policy Decision Server and GDS/Extended LDAP will contain a Trusted Source of Clearance Information </li></ul></ul><ul><ul><li>Objects will use the classification attribute as an access control through the Role Base Access Control (RBAC) Filter </li></ul></ul><ul><li>Audits significant events and use audit analysis tools </li></ul><ul><li>Uses DoD PKI for strong Identification and Authentication </li></ul><ul><li>All data is labeled with classification and accesses using DDMS/IC Meta Data tagging </li></ul><ul><li>Firewalls and IDS systems will be used for boundary defense </li></ul>
    8. 8. <ul><li>Will use encryption (Type I certified and FIPS 140-2 validated) as needed to tunnel data through communications lines of lower or different classification levels or enclaves, (i.e., will tunnel Secret through NIPRnet to SIPRnet) </li></ul><ul><li>System Assurance: </li></ul><ul><ul><li>Will use system vulnerability tools (i.e., ISS, APPscan) to assure the continued integrity of security support structure </li></ul></ul><ul><ul><li>Will perform malicious code checking and mobile code verification </li></ul></ul><ul><ul><li>System Security Authorization Agreement (SSAA) includes: Security Requirements Traceability Matrices, Test plans, Test result reports, and System Documentation (e.g., User Manuals, CONOPS, System Administration Manuals) </li></ul></ul><ul><ul><li>Certification Testing will be conducted at SPAWAR Systems Center - Charleston </li></ul></ul><ul><ul><li>Test results will be reported to the DAA </li></ul></ul><ul><li>DoD CIO appointed DIA as the HF enterprise level DAA </li></ul>Confidentiality Controls (2)
    9. 9. Integrity Controls (1) <ul><li>Will do Systems and Data Backups </li></ul><ul><li>Will have a CM plan </li></ul><ul><li>Malicious code checking at data source </li></ul><ul><li>Uses digital signatures to ensure data integrity </li></ul><ul><li>System design includes best security practices (e.g., PK enabling of initiatives) </li></ul><ul><li>Used applicable Security guidance documents </li></ul><ul><li>Have a functional architecture for HF that defines external interfaces, protection mechanisms, user roles </li></ul><ul><li>System will be accredited prior to implementation </li></ul>
    10. 10. Integrity Controls (2) <ul><li>DoD PKI is used for digital signatures </li></ul><ul><li>Use of Mobile code will be controlled </li></ul><ul><li>DoD PKI used for Identification and Authentication </li></ul><ul><li>Host Based IDS systems are used </li></ul><ul><li>Role Based Access Control is used to control privileged accounts </li></ul><ul><li>Use transmission integrity controls such as parity checks, labels, and encryption to prevent data corruption in transit </li></ul><ul><li>Audit data is protected </li></ul>
    11. 11. Availability Controls <ul><li>Backups will be positioned to allow rapid recovery of the system </li></ul><ul><li>Functional and compliance testing performed prior to deployments </li></ul><ul><li>Hardware baseline is documented in the SSAA </li></ul><ul><li>Public Domain software use is controlled </li></ul><ul><li>DAA and other IA roles assigned </li></ul><ul><li>Virus checking implemented on hardware </li></ul><ul><li>Wireless computing is implemented in accordance with applicable Wireless policy DoDD8100.2 </li></ul><ul><li>Use vulnerability assessment tools to manage vulnerabilities </li></ul>
    12. 12. Key Security Technologies: A Diverse Set of Tools <ul><li>Core Enterprise Security Services </li></ul><ul><li>DDMS / IC Meta Data Tags </li></ul><ul><li>GDS / Extended LDAP Directory </li></ul><ul><li>SAML / XACML </li></ul><ul><li>Role Based Access Control (RBAC) </li></ul><ul><li>DoD PKI and Public Key Certificates </li></ul><ul><li>AES and FIPS140-2 Cryptography </li></ul>Wireless AES-based IPSec VPN Tunnel PKE/PKI Network Security Perimeter Defense Risk Management Policy Networking Crypto
    13. 13. Standard Specifications as Guidance in the Development <ul><li>Middleware and Data Layers </li></ul><ul><li>XML & XML Schema v1.0 </li></ul><ul><li>Semantic Web Markup Languages (DAML, OWL) </li></ul><ul><li>Registry standards (RDF/UDDI v2, JAXR) </li></ul><ul><li>Web Services (WSDL v1.1, SOAP v 1.1), and JSR170 </li></ul><ul><li>J2EE (EJB, JAX Pack, JNDI, JMS) </li></ul><ul><li>ODBC/JDBC </li></ul><ul><li>SAML, XACML </li></ul><ul><li>SQL database engines </li></ul><ul><li>Syndication (RSS v1.0) </li></ul><ul><li>XMPP </li></ul><ul><li>JDK 1.4.2 </li></ul><ul><li>DDMS and IC Metadata Framework </li></ul><ul><ul><li>Domain Namespaces </li></ul></ul><ul><ul><li>Content tagging </li></ul></ul><ul><ul><li>Taxonomies (categories) </li></ul></ul><ul><ul><li>Ontologies (relationships) </li></ul></ul><ul><li>User/Admin Interfaces </li></ul><ul><li>Cross-platform/browser (HTML 3.2/4.0; DHTML; CSS 1.0) </li></ul><ul><li>JSR 168 Portlet/JSR 170 Specification </li></ul><ul><li>JDK 1.4.2 </li></ul><ul><li>Limited JavaScript </li></ul><ul><li>Web Services for Remote Portal (WSRP) </li></ul><ul><li>Accepts XML/XSLT </li></ul><ul><ul><li>Automatic rendering in portlet </li></ul></ul><ul><li>SAML/XML Signature/Encryption </li></ul><ul><li>PKI and Directory Services </li></ul><ul><li>Syndication (RSS v1.0) </li></ul><ul><li>DDMS and IC Metadata Framework </li></ul>
    14. 14. Conceptual Security Architecture Admin Console Security CES End User GDS + Extensions Authorization Store (RDBMS) <ul><li>Roles </li></ul><ul><li>Credentials </li></ul><ul><li>Policy </li></ul>3. Portal calls GDS to obtain User Role, Clearance, dn, etc based on PKI cert 2. Portal Validates Certificate 5. Service A’s Server Handler validates signature 8. Service A validates PDS signature, allows or denies access to the web service 11. 7. 9. 4. 1. 6. 10. Audit DB Audit DB Audit DB Policy Decision Service Policy Admin Service Policy Retrieval Service Portal WS Client Security Handler CES SDK Portlets Service Provider A Web Service Security Handler (inbound) Security Handler (outbound) CES SDK Principal Attribute Service Certificate Validation Service CA DoD SIPRNet Certs Webservice Request PDS Webservice Request Data returned By PDS Chained Service Request Data returned By Service Posting Data
    15. 15. Secure Wireless <ul><li>Mobile and wireless technologies – are burgeoning in the private sector. Wi-Fi, MANETS, 802.16, 3G, PDAs, and SDR are only a few. </li></ul><ul><li>These technologies could bring enormous benefits to today’s warfighter </li></ul><ul><li>These “constrained” technologies are often space, power, CPU and bandwidth limited </li></ul><ul><li>Moreover, due to the broadcast nature of the radio technology, the smaller size, and the mobility – challenging security issues exist </li></ul><ul><li>Horizontal Fusion must leverage secure wireless nevertheless </li></ul>
    16. 16. Cross-Domain Information Exchange <ul><li>Crossing multiple security domains is vital to our efforts </li></ul><ul><li>Getting valuable information between the Collateral Space and the warfighter at the “pointy edge of the spear” is critical </li></ul><ul><li>Bidirectional communication with Coalition Forces is essential </li></ul><ul><li>Historical methods – using antiquated solutions are no longer acceptable in the emerging NetCentric DoD </li></ul><ul><li>Service Oriented Architecture with built-in security features provides the foundation </li></ul>JWICS SIPRNET Coalition Unclassified CDIX CDIX CDIX RBAC DoD PKI / PK Enabling Digital Signatures Intelligent Boundary Devices (perimeter defense) Meta data tagging / Labeling Secret
    17. 17. FY05 and Beyond SIPRNET Domain 2 Single Net Enhanced security and intelligent boundary devices Domain 1 Full complement of SOAP/XML services and security features Robust, interoperable PKI and ubiquitous certificates Tagged Data DoDPKI
    18. 18. Summary <ul><li>Horizontal Fusion is truly a Catalyst for Net-centricity for the DoD </li></ul><ul><li>Uses current standards adapted to a Net-centric environment </li></ul><ul><li>Security features are diversified and embedded throughout the architecture </li></ul><ul><li>Architecture and IA will continuously evolve with constant improvement </li></ul><ul><li>Information Assurance implementation lessons-learned will be shared widely </li></ul>