A Ph.D Proposal By: Sarah Pramanik Computer Science Department University of Colorado, Colorado Springs Presented On: 06/17/2011

Presentation Outline Problem Background Related Research Approach Tasks Path Forward 2

3

What is a Security Architecture? According to NIST [84] a Security Architecture should: Acknowledge current security services, tools and expertise, outline forecasted business needs and requirements Clearly articulate an implementation plan Supplement with an integrated schedule of tasks, establish project timelines, provide estimates of resource requirements, and identify key project dependencies Focusing on protecting the confidentiality, integrity, and availability 4

Architecture Development Issues Scope of architecture, or size of program, may be different than currently available expertise Level of acceptable risk is subjective (no industry standard) Inclusion of security architecture as an embedded element 5

Why Security Architecture Working as a Security Architect Very large program, limited time and budget How do I know I have done my job? Currently assessing risk and architecture is subjective DoD Information Assurance Certification and Accreditation Plan (DIACAP) Real World Issue Severe consequences if security is not correct 6

A Comprehensive Security Architecture Why does there need to be a Security Architecture Methodology? What does the methodology need to encompass? How can a Security Architecture be evaluated? 7

Why a Security Architecture Methodology Security must satisfy a variety of laws, policies and regulations Security can get lost in complex systems Need to avoid bolting on at the end Need to mitigate program risk The Security Architecture is not just one document 8

Encompassing Methodology A methodology must step the architect through each aspect of securing the system Identification of elements to complete during each phase of the system engineering lifecycle Identification of cost effective and low risk system protections Continuous review of the system with a security architect’s mindset 9

Security Architecture Evaluation Quantifiable method for assessing a security architecture Method for evaluating risk to a system Based on the protections put in place and any residual vulnerabilities Automated way of looking at the architecture before the system is implemented 10

11

Information Assurance Cont. Information Assurance (IA) is the practice of managing risks related to information IA primarily deals with the Confidentiality, Integrity, and Availability of information Part of a Security Architecture is the application of layered IA defenses into a system 12

Information Assurance 13 Layers of Information Assurance [97]

IA Requirements DoD programs follow different sets of IA requirements, depending on the type of system DoDI , JAFAN 6/9, DCID 6/9 All are very similar, with only a few minute differences There is a move (in the Navy at least) to consolidate to the NIST SP This may also require a move from DIACAP to NIST SP

IA in System Engineering Lifecycle Information Assurance or Information System Security Engineering should not be isolated into one piece of the system Systems Engineering typically considers security to just be a specialization that it should be done in parallel with the systems lifecycle [5]. Security engineers must be incorporated into each IPT, knowing only system level information is not sufficient 15

System Engineering Lifecycle Systems engineers perform such tasks as requirements decomposition, interface definition and functional decomposition of the system[5] Each aspect of a task can potentially affect the overall security posture of the system 16

Existing Architecture Frameworks Zachman Framework [98] Department of Defense Architecture Framework (DoDAF) [96] Sherwood Applied Business Security Architecture (SABSA) [91] Information Assurance Technical Framework (IATF) [75] 17

Zachman Framework The Zachman framework is the predecessor to various frameworks used for system architectures. A formal and structured look at an enterprise and it is a taxonomy It is not a methodology 18

DoDAF Shows the system through the lens of specific stakeholder concerns It is organized into multiple views It is a requirement on most major DoD programs It provides a functional view of the system Useful in describing the operational view 19

SABSA 20

Existing Evaluation Methods “There is no common framework in any current evaluation scheme or criteria that directly supports measuring the combined security effectiveness of products.” [86], [95] The National Information Assurance Partnership (NIAP) and Common Criteria (CC) both provide evaluations on specific products 21

22

Theory vs. Real World This research is being applied in real-time Initially followed SABSA to integrate into a DoDAF model DoDAF was too high-level Needed a systematic approach to: Explain what needs to occur to the IPTs and security team Identify risks, cost and schedule issues due to security 23

Continued Application Trial and error Organization is key to success Requirements decomposition Different interpretations Evaluation Subjective and unquantifiable 24

A Systematic Approach Inclusion in overall system life-cycle Systematic Methodology A road map for the IPTs Assurance of completeness Security Architecture Evaluation Quantifiable Programmatic Risk Reduction 25

26

Task #1 Integration of Security into System Engineering Lifecycle Follow the formalized Systems Engineering Methodology as presented in[5] and show how security should be integrated Compare with how it is currently done on most large programs 27

Task #2 Creation of Security Architecture Methodology Create a methodology that encompasses many of the attributes focused on in the frameworks, but gives an architect a step-by-step process to follow The architect will be able to adequately gauge where they are in the process, which will allow for more effective budget and schedule management 28

Task #3 Creation of Automated Architecture Evaluation Tool Create a program that brings in the most critical aspects of a system design to provide an assessment of the security posture before the system is built This will allow for changes in the design early on, which reduces risk 29

Task #4 Coding Standards Complete a secure coding standard and software assurance plan that provide developers an understanding of how they contribute to the overall security posture Currently in the process of being implemented as a sector standard, and being used for other programs 30

Task #5 Program Effects As part of the look at the Systems Engineering Methodology, review any known statistics of incorporating IA, and provide an estimate, based on time and schedule reduction of risk reduction, and potential cost savings 31

32

Timeline 33

Evaluation Plan Application of security architecture methodology on current program and on a mock system Application of enhanced system engineering methodology on a mock system Comparison of systematic security architecture methodology to methods used on other programs 34

Success Criteria Demonstrate a program that can help assess the security architecture for vulnerabilities Provide a system security architecture methodology, that covers all aspects of creating a useful security architecture, and show that it can be used in other programs and on a variety of complex systems Provide a process and method for incorporating security into the overall systems engineering methodology and show that it can be used in other programs and on a variety of complex systems 35

Potential Contributions New methodology for the creation of security architectures on large complex systems New methodology for the incorporation of security into the overall systems engineering lifecycle New tool to assess the vulnerabilities in a system, based on a model before a system is built 36

Questions/ Comments? 37

References [5] Alexander Kossiakoff and William N. Sweet, Systems Engineering Principles and Practice, 2003 © John Wiley and Sons Inc. [8] Birgit Pfitzmann,” Multi-layer Audit of Access Rights,” W. Jonker and M. Petkovi´c (Eds.): SDM 2007, LNCS 4721, pp. 18–32, [13] Committee on National Security Systems Instruction No. 1253, 2009 October“Security Categorization and Control Selection for National Security Systems, Version 1,” Committee on National Security Systems. [20] Department of the Navy (DoN), “Security Control Mapping,” SECNAV DON CIO, 1000 Navy Pentagon, Washington, DC. 38

References [34] Heru Susanto, Fahad bin Muhaya, “Multimedia Information Security Architecture Framework,” 2010 © IEEE. [40] Karen Goertzel, “Software Security Assurance: A State of the Art Report,” IATAC, Defense Technical Information Center. [71] National Institute of Standards and Technology Special Publication Revision 3, 2009 August 2009, includes updates as of ” Recommended Security Controls for Federal Information Systems and Organizations,” NIST, Gaithersburg, MD. [75] National Security Agency Information Assurance Solutions Technical Directors, “Information Assurance Technical Framework,” Release 3.0, September

References [80] North American Electric Reliability Council, 2004, “NERC Cyber Security Activities,” Available: [85] Richard Kissel et al, National Institute of Standards and Technology Special Publication , Revision 2, 2008 October, “Security Considerations in the System Development Life Cycle,” NIST, Gaithersburg, MD. [87] Richard S. Hall, 2005 May 13, “Oscar Security” Release version: Available: [92] SABSA Ltd ©SABSA, “The SABSA Method,” Available: 40

References [97] Wikipedia 2010 December 14, “Department of Defense Architecture Framework,” Available: _Architecture_Framework [98] Wikipedia 2010 December 10, “Information Assurance,” Available: [99] Wikipedia 2010 December 10, “Zachman Framework,” Available: 41

42

Publication/Conference Northrop Grumman Software Symposium Presented a talk on “Software Security Architectures: Principles in Application,” Baltimore MD, Northrop Grumman Software Center Of Excellence “Spotlight on Information Assurance in the Real World,” Issue 3, June