Mike Davis SD ISSA / SPAWAR 5.1.8 Michael.h.davis@navy.mil (858) 537-8778

1. CyberSecurity Collaboration SummitGeneral Results Overview AFCEA - C4ISR Symposium 20 November, 2008 San Diego CA Mike Davis SD ISSA / SPAWAR 5.1.8 Michael.h.davis@navy.mil (858) 537-8778 Michael Jones The Security Network mbjones@thesecuritynetwork.org 619-450-4600 ext. 141 “EASY” button

2. Agenda / Topics

3. TOP TEN IA ISSUES • Overall IA Master Plan / vision, and architecture, requirements, goals/objectives therein • Improve speed to capability – affordably! (it’s not all about just technology either) • IA/security Governance / consistent policies integrated at all levels • Workforce training, qualification and certification at all levels, integrated and enforced • Provide Enterprise Wide CM Capability down to the major security component level (that is an enforceable process) • Maintain and sustain the IA/security posture that you have • Follow ONE IA Enterprise Architecture (EA) and selectively prescribed, directed standards (and extensions therein) • Better IA/security network awareness (dashboard) AND integrated with enterprise management • IA metrics that matter wrt outcomes – impacts to users / data (DLP) • Establish a data/information centric security approach – implementing effective IA metadata is harder than you think

4. Issues SummaryActions to collaborate / facilitate What’s our end- state / vision (“start with the end in mind!”) (then define requirements and determine gaps) Who’s in charge anyway? Enforcement? (aka - Governance) Prescriptive implementation guidance required (EA, stds, trust model, CM, etc) What’s “good enough” IA/Security? Outcome metrics that matter, support the business success factors, risk management. Complexity is rising versus falling (we can’t begin to do V&V on SoS – how do we do T&E to prove IA is effective?!) “IA” is all encompassing, we can’t “win” if we don’t know where we are collectively going or narrow the playing field 4

5. IA VISION (s) • Dynamic Information Assurance for the Business (or GIG) • Highly secure, reliable and manageable enterprise network environment • Assured ubiquitous information dominance empowering the business drivers (or commander’s intent) • Affordable IA that automatically keeps up with new threats and is invisible to the users, while providing “good enough security” protecting people, assets and data. Mission: the right access, to the right folks, at the right time, anywhere, anytime, with the appropriate level of assured availability and data quality of protection, while also minimizing data loss - all affordably; that is - a best value in IA measured against effective enterprise risk management. Is it even possible to have ONE vision, as “IA” is the same, right?

6. IA Strategy / Requirements Transactional Information Protection Granular end-to-end security controls to enable protected information exchange within the variable trust net-centric environment •Digital-Policy Enabled Enterprise Dynamic response to changing mission needs, attacks, and systems degradations through highly automated and coordinated distribution and enforcement of digital policies •Defense Against an Adversary From Within Persistently monitor, track, search for, and respond to insider activity and misuse within the enterprise •Integrated Security Management Dynamic and automated net-centric security management seamlessly integrated with operations management •Enhanced Integrity and Trust of Net-Centric Systems Robust information assurance embedded within enterprise components and maintained over their life-cycle

7. IA Vision Protection Agility Minimal Cost Getting the right information to the right place at the right time……and to only the right user Overall Effectiveness Effectively AND affordably Find the right balance between competing priorities

8. IA Vision SummaryActions to collaborate / facilitate What are the main future requirements? Who says so? What is OUR IA business basis / ROI? (metrics therein?) How automated can/should we make IA (thus complex?) What is the risk environment for the future? Continue to bet on technology? Use threats or consequences or both? What are the real gaps / barriers WE need to address to get “there?” Is there a “unified theory” for IA that is “KISS”? IA VISION proposal: Ubiquitous, dynamic information assurance dominance empowering commander’s intent, enhancing critical business drivers! 8

9. Gap Fillers / Disruptive Technologies(major companies / sponsors perspectives)Issues/Actions Needed Info-centric vice Network Centric Poor MLS/CDS requirements definition Automate DIACAP to reduce cost, decrease time Factor the 4th dimension of time in security- Is SSL good-enough Virtualization- will be key technology in a downsizing/DOD consolidation market SLAs for IA Remove as much subjective decisions out of C&A process We over-encrypt our networks which will cause social unrest with our users (USB Ports and Facebook) Mobility/PortablityWhen is Navy supporting iPhone and MacBook? Just live on SIPRNET?

10. Gap Fillers / Disruptive Technologies(major companies / sponsors perspectives)Summary / recap Definitive authorization – (minimize ambient authority issues) Build in, with a Pgm Mgmt focus, Compliance, versus add on Training at al levels… user, developers, etc More granularity in access / auditing Visibility for security as a SoS approach at all levels (need implementation level guidance) Clear governance throughout, supported by technology And Applications security, Applications security, Apps sec…

11. Estonian Lessons Learned(overview) Coordination ahead of time… folks knew each other Common, established network security – preplaced ahead of time Information sharing and media coverage Best practices: --- internal cooperation – agency to agency and support companies --- International cooperation - politics, technical, LEGAL… Added perspectives… Understand and design for the “mindset of attacks” as well NATO focus / support – share training comms/processes/ideas

12. SOA IA CONCERNS If systems and communities are going to intersect we need effective Governance from ALL perspectives There is not deployable guidance or standards for establishing trust between systems across organizations in the enterprise Approaches to IA and EA implementation and certification are not interoperable between programs and systems Trusted enforcement devices and implementation standards do not exist for establishing and enforcing policy “SOA” is antithetical to existing vetting, certification and accreditation (C&A) processes – no common V&V / T&E methods exist! SOA IA concepts require common ontology, semantics and meaning Digital policy standardization across the DoD is, at best, immature NO accepted CONOPS for federal, coalition, and first-responder collaboration and information sharing Top Down Strategy does not extend to implementation details - especially for “last mile” or “DIL” environments SOA security requirements not common in the enterprise nor linked to clear operational business requirements, impacts or value Without an overall C&A framework - “re-useable and shareable” SOA applications cannot be installed in DOD environments!!!

13. SOA IA SummaryActions to collaborate / facilitate DOD CONOPS / governance approach needed Requirements, requirements, requirements Need a flexible enterprise DOD IA Design “implementation” level strategy / approach, including trust model, access control schema, that can adjust the level of protection to the requirements Standard architectures / standards / approaches which all must synchronize, interoperate, including a dynamic digital policy execution schema and ontology to normalize effect T&E / V&V approach to measure results / residual risks SOA makes great business sense, but WE must have a comprehensive trust model, C&A game plan to make it work! 13

14. First Responder Needs(overview) DHS - Make intrusions difficult but not impossible collaboration, sharing, leverage what exists STTAC (State Terrorism Threat Assessment Center) (CA) - capability development training… SCADA, total mobile security, Medical perspective (CalPSAB member) - Standards based – implementable specifications (& ZBAC) KNOW who the requestor is wrt ID… and what is authorized Local Police Chief – What protection level is REALLY needed at each level? (content management)… get right info to only right person asap… low SWAP… (weight / power) Regional 3Cs program – affordable, as they do without it if too costly… minimize sustainment costs, front load $$$ Commonality… foster local / regional relationships

15. Leadership Summary / Recap(first draft - what do we want to tell our bosses WE ALL need to do?) • Common vision / end state / master plan – where are we going? • Governance & more governance – coordinate ALL those in charge? • Specified requirements and then some – top down, detailed needs • Prescriptive implementation guidance required – fidelity in the “what” • What’s “good enough” IA/Security? Must have a common threshold • Pedigree approach – simplify verification and compliance (build in) • What is the IA business basis / ROI? (AND success metrics therein?) • What is the future risk environment? Threats, consequences, etc? • Training at all levels, especially user and SW development • Standard architectures / standards / profiles (and a Trust Model!!!) • SOA security is vague - at best (No T&E / C&A Plans at all!), but… • Application security and web security, or lack there, is huge too WE must collectively quantify & prioritize these for leadership actions

16. The IBM Security FrameworkIA Vision - THEN SOA: IBM Cyber Security 16

17. SOA Security - To Get A Better AnswerAsk A Better Question • No battle plan survives contact with the • Enemy • IT Dept. • The Alluring Illusion of the Wise God • Engineering: breaking an impossible problem into parts so small, each can be solved by mere mortals • Real Question: How do we distribute the power to stitch together the network we need? • Real answer: Need To Know/Do based Sharing • Dynamic - Cross-Domain • Attenuated - Chained • Composable - Accountable • ZBAC: the only known enabler

18. What’s an end-state look like? Need to factor that in with SOA NuParadigm

19. How to close the SOA IA loop? • Part of the solutions picture:model-driven security www.secure-soa.info www.modeldrivensecurity.org www.openpmf.com info@objectsecurity.com www.objectsecurity.com • How do we know the IT does the IA we intend? • How do we do application & process layer monitoring & reporting? • Network layer IDS not enough • How can we achieve “good enough C&A” for SOA? • Complex: IA is distributed, cross-layer, externalized… • “System of systems” potentially unknown at C&A time • Verification of IA properties difficult/infeasible • How do we say what IA we want? And how make it happen? • Where does the policy come from? • Usually focus on mechanisms • Authorization management hardest • Difficult in agile systems • How to align business IA requirements and IT IA enforcement? • Usually a huge disconnect © 2008 ObjectSecurity – all rights reserved

20. Security and SOASO what’s still potentially missing? • SOA (& web services overall), is generally thought of as service producer-to-consumer, not system-to-user. But security has to be user-focused AND data centric as well, for example: • What metadata is discoverable? what is the schema for crypto-binding data • Data aggregation, dynamic “re”classification authority, overall data schema • The ROI for SOA is based on applications, NOT security • Unclear measures/metrics/SLAs wrt data-based assessments & decisions • Security must be institutionalized enterprise-wide — beyond single applications – e.g., enforcing an EA and select “specified” standards • Which versions and extensions? We must agree or “global” SOA can’t work! • Fine grained “IA” (C-I-A) access control – supporting the “need to share” • IA&A beyond the first application; supporting automation and “NPEs” • Current “JEDS” 13+2 attributes not adequate for specific services / NPE use.. • Will PKI scale to what is needed – IS it even needed? What is plan “B” – IBE? • An enterprise-wide policy statement, schema and enforcement needed • No federally proposed schema socialized, let alone implemented digitally • Residual major design items to consider, accommodate • Re: “NO” Enterprise Trust model / federation, loosely coupled Identity Management (IdM), Autonomy central to Navy SOA strategy, PKI-centricity, etc…

21. SOA IA Questions to clarify • E2E access control implementations can create security risks • Enterprise E2E IA/security strategy still needed – many options • IA Security SLAs / E2E audit processes - weak / unclear • “Standard” Standards needed (and versions and extensions, options therein) • IV&V / operational security T&E processes unclear • new NNWC C&A Process pushes “ST&E” to user environment • Unclear E2E security CONOPS and IA requirements traceability • IA / security / IA&A taxonomy, lexicon, definitions differences • No recognized state, local, allied, and coalition PKI / token • Numerous “common” implementation resolutions/details needed There are some plans to address most, but nothing found enterprise wide

22. SOA IA Questions to clarify • Verbose protocols problematic wrt IA overhead at the tactical edge • Digital policy standardization, collaboration and implementation is an immature capability DoD wide, which affects the ability of PDPs in mixed domains • GIG designs are going to require a different approach to difficult last mile bandwidth constraints. This creates asymmetric IA patterns and integration patterns which can create significant emergent behavior issues. • C&A for Programs should be developed in parallel to the system functions as it will be a complex, coordination and governance task • IA validation testing is impacted by the maturity of STIGs for web services/SOA where testing is already complex – and now must include inheritance aspects! • Scalability can also be an issue with disadvantaged low bandwidth environments and the increase in numbers of users / NPE. There are some plans to address most, but nothing found enterprise wide

23. Authorization / access control deltas(from the OSD / NSA/GIAP / DISA / IC “SIE” Panel – Sep 08) • Establish / codify digital authorization policy model, schema and adjudication process • Establish attribute governance process • Trust Model / details (& Supply chain issues) • Define / Identify Authoritative attribute sources • Identity management foundation • Measure and respond to authentication assurance level; measure confidence • Authorization schema / guidance needed Still much to quantify and agree on in the whole E2E IA&A process

24. Auth & AC SIE Panel Conclusions (from the OSD / NSA/GIAP / DISA / IC “SIE” Panel - Sep 08) • Understand and define trust models that align with the enterprise (e.g., DoD, IC, DHS, coalition, industry) • Create robust authentication technologies • Create smarter PDPs and PEPs • Define/identify/collect better attributes (e.g., location, situation) • Accommodate the “IA metadata” issues(slides follow) • Long term goal is to move toward RAdAC AKA – We still do not know how to fully build SOA IA yet, let alone C&A

25. IA Metadata General Issues 1 of 3 (from the OSD / NSA/GIAP / DISA / IC “SIE” Panel - Sep 08) • Need to refine the definition of IA metadata • Need to justify IA metadata by use case (operational, research, theoretical) • What is the scope of metadata? E.g., consumer organizational affiliation might be used as an attribute in an ABAC solution • Need a common lexicon for IA metadata terms in general • Need to separate the technology transition issues from the basic research issues • Lack of trust model – need policy, procedures, and systems that support the model. Compounded by requirements to operated in a federated environment. • Statutory and regulatory requirements must drive what must be marked for interoperability. Need to identify current requirements and develop/recommend additional guidance that meets the needs to protect and use IA metadata for information sharing in a net-centric environment.

26. IA Metadata General Issues 2 of 3 (from the OSD / NSA/GIAP / DISA / IC “SIE” Panel - Sep 08) • Impractical to maintain metadata on all data assets at all times. • Dependent on key management. E.g., what are key management requirements for the range of security environments? • Overhead (bandwidth, processing, storage, etc) imposed by IA metadata • Overhead required by binding (cost, performance, infrastructure requirements) • Policy for changing historical metadata

27. IA Metadata General Issues # of 3 (from the OSD / NSA/GIAP / DISA / IC “SIE” Panel - Sep 08) • Need to develop and provide implementation guidance on how to use IA metadata • Maintaining linkage between and among the data asset, binding metadata, multiple metadata records describing the same data asset • e.g., Navy best practice to maintain data asset and metadata on the same LAN • Usage patterns are not fully understood, therefore requirements for scope of IA metadata and management are incomplete • When establishing a COI, institutional or dynamic, there are requirements for developing vocabulary and other metadata artifacts . This vocabulary must be consistent with IA metadata related standards • Ability to generate and utilize digital policy based on standards compliant IA metadata • Reliability and currency of embedded metadata • Need for an implementable IA metadata auditing policy • As applied to the metadata infrastructure • Link to provenance