Delivering Effective Information Assurance: Suggestions from a Certification Authority

1. Current status as of 31 Dec 04Current status as of 31 Dec 04

2. Quick Outline My Role in Army IA Common Issues in IA Technical Organizational Educational Recommendations for Increasing Security Think Globally, Secure Locally Build and Operate Systems with IA that meets the needs of all elements involved in the IA cycle Put Security back in IA

3. My Role in Army IA Director, Information Assurance and Security Engineering Directorate, US Army Information Systems Engineering Command Mission: To provide full spectrum IA support to the Army: Security Engineering, Certification, PKI Support 42 DA Civilians and Military 30-40 Contractors Providing IA Support Security Engineering Certification Support PKI design and enterprise consideration Certification Authority On well over 30 major Army Systems or Networks All in all, so far this FY we have provided Security Engineering or Certification support to over 70 projects in SWA, PAC, CONUS and Europe What have I learned from all that: Fundamental IA issues are common across MACOM, Acq Programs/DOIMs, Theaters

4. Common Issues #1 The single most common fundamental misconception about IA: IA = DITSCAP DITSCAP = SSAA Therefore: IA = SSAA Thus: IA is just a matter of getting the paperwork right

5. Consequences #1 This misconception leads to: No Security When we moved from Information Security to Information Assurance, we misplaced our priorities: Security vs Assurance Delaying addressing IA till just before operation After all, it�s just a matter of getting the paperwork right (not!) Failure to consider operational impacts of security sustainment (and associated budgeting for lifecycle IA costs) A crop of commercial tools, aggressive marketers, and pseudo IA professionals all of which that promise cheap accreditations (IA is cheap when you skip security) Delayed operation when confronted with a Certification Authority that expects reasonable security Blaming IA for delaying their program

6. Common Issues #2 Failure to treat Security Engineering as a subset of the Systems Engineering Process The DITSCAP does not address Security Engineering, so Information Systems Security Engineering is often neglected To be effective, IA has to be integrated with all facets of the system, from design to development and operation Consideration has to be given for sustainment and total lifecycle cost The Systems Engineering process is the perfect process for IA, you just focus on the security requirements IA cannot be �bolted on� at the end, it must be integrated with the TTPs of the system, the people operating the system, the facilities hosting the system, etc.

7. Common Issues #3 Failure to consider the holistic requirements of IA, this manifests itself in two ways: Concentration on the �system� with insufficient regard to the enterprise and the systems impacts/risks to the enterprise System developers, be they PMs or Army Organizations, are not judged on their ability to enhance the security of the enterprise The needs of the operational commands, the TNOSCs, RCERTs, and 1st IO Command are not identified and integrated into the systems development If systems aren�t built to ensure that security can be sustained, enhanced, and provide sufficient forensic information to investigators, then it generally doesn�t get done. The result is less than optimal utilization of available resources to meet the needs of the enterprise

8. Common Issues #4 Decentralized Designated Approving Authorities and Certification Authorities lead to: Inconsistent risk identification and acceptance �Good enough� is subjective, and influenced by: Knowledge and experience of Certification Agents and the CA The depth and breadth of knowledge of the CA Operational necessity of the system Little centralized knowledge of accepted risks and potential impact of system vulnerabilities when combined with systems from different DAA�s and CA�s Few (if any) understand the total state of IA in the Army Systems of Systems risk is not being fully analyzed, documented, modeled, and appropriately accepted or rejected

9. Common Issues #5 Common technical concerns: Use of insecure protocols Telnet, FTP still in common use Failure to take advantage of DISA STIGs Flipside of that, failure to consider IA issues not covered by STIGs Poor Configuration Management Insufficient consideration for Disaster Recovery/COOP Use of commercial NOSCs not up to Army/DOD IA standards Insufficient understanding and documentation of: System Interface requirements and methods Security provided by/expected of the enclave Fiscal challenges and technical limitations of service providers Unenforceable IA provisions in development/service contracts

10. So, in my humble opinion,what should we do to increase our success Re-educate the Army about IA Information Assurance is a process, not a discrete event At the project development level the IA Process has two components: Security Engineering Process That sub-discipline of Systems Engineering responsible for the identification and integration of security requirements and satisfaction of those requirements in an interdisciplinary manner throughout the lifecycle of an information system (>75% of your IA resources) Certification and Accreditation Process The validation and verification of IA requirements, the resultant risk identification to the system and the enterprise, and the acceptance or rejection of that risk (<25%) Security is the priority and the goal, assurance follows security Security without assurance is immeasurably better than assurance without security

11. Suggestion #2 Formally integrate Security Engineering into the Systems Engineering Process The systems engineering process is a time proven method that ensures that: All requirements are identified, validated, and tracked Solutions to meet the requirements are offered (technical, procedural, policy) Approved solutions are tracked back to the requirements and integrated/implemented properly Change is managed, Solutions are verified, and the Documentation is correct Security is sustainable through the lifecycle Security Engineering is a unique subset because the requirements are many, the technologies endless, and dedicated specialists are required. DODD 8500.1, DODI 8500.2 are great first steps in recognizing Information Systems Security Engineers

12. Suggestion #3 Recognize that systems operate in an organization/enclave with other systems and become a part of the enterprise Consider the needs/existing management tools and skill sets of the operating organization Identify the needs for enterprise awareness, identify what the RCERTs and 1st IO Command need for forensics and then build them in. The Army is working on doing a better job identifying the IA Architectures, e.g., what services are required, where are they performed, what can you expect where you expect to connect, and what IA role should systems be prepared to fulfill that go beyond individual system requirements CIO/G6 has an on-going IA Architecture effort on-going now, in concert with the GIG IA Architecture. But it will take time. Make better use of our existing IA dollars to maximize the needs they meet

13. Suggestion #4 Develop Enterprise Situational Awareness: Achieve enterprise awareness of Systems, Networks, and Risk Achieve standardization of vulnerability identification and risk determination DAA role should remain decentralized IA is a command responsibility But, we need to raise the decision authority to the GO/SES level because of the potential for local decisions to have great impact across the enterprise The Certification Authority needs to be centralized A single Army CA will: Be able to view all vulnerabilities as they relate to enterprise risk Ensure consistent advice and recommendations to all DAA�s Perform the Department�s FISMA mission Set standards for the work and appointment of decentralized Agents of the Certification Authority Single coordinator for systems that span multiple departments/agencies

14. Suggestion #5 Ensure that you are are using IA Professionals A Lead Security Engineer will know the IA Process and help guide your system through them The Lead Security Engineer will understand the potential sources of requirements and be able to negotiate those that must be met, and those may be N/A in your situation The Security Engineer will offer alternative solutions depending upon your unique factors, and coordinate with the certifiers to facilitate success Involve IA early Early decisions involving people, facilities, equipment, software, etc. should include IA considerations Bring the Certifiers in early to validate your efforts and identify potential conflicts/show stoppers early Security involves hard work It can�t be done if you wait till just before operation thinking it�s just a matter of paperwork

15. Conclusion We must put Information Security back into Information Assurance Use professional Security Engineers as part of your total Systems Engineering efforts Involve certifiers early to avoid showstoppers later Upfront and Early will significantly increase your chances of success, which ought to be the security of your system and that of the enterprise Think globally as you secure locally You can�t control what you don�t own, but you can have a dramatic impact on others if you don�t consider their needs Assuring the availability, integrity and security of our information is a fundamental requirement to achieve NetCentric Warfare success