Increasing Security for DoD Systems, Through Specific Security Applications
Sarah Pramanik
Advisor: Edward Chow
A Ph.D. dissertation proposal submitted for Security Engineering, University of Colorado at Colorado Springs
June 17, 2011
Abstract
There are three facets of security that are crucial building blocks to ensuring that security is easily and completely integrated into a system. The first facet is the Systems Engineering Lifecycle. It is crucial that security is included in all phases of the lifecycle. The second facet is System Security Architecting, which should be integral to the Systems Engineering Lifecycle, and not a peripheral “specialty engineering” concept. The third facet is programmatic effects involved with applying security measures, including: cost, schedule and risk. These three pieces are all critical to the development of Department of Defense (DoD) Systems and applicable to many commercial ventures as well.
Information Assurance is the art of protecting the information in a system, and must be built into overall system security. Systems engineering should incorporate these principles into the system in the form of a Security Architecture and throughout the development of the system.
There are serious programmatic effects if security is applied incorrectly or too late. These range from extra cost and schedule slips to higher risks. It can also lead to additional vulnerabilities in the system. The proposed research looks at how to efficiently add in security to a system to prevent some of the negative programmatic effects through changes to systems engineering and by creating a system security architecture methodology.
Table of Contents
I.Introduction
II.Information Assurance
III.System Engineering Lifecycle Overview
Requirements Analysis
STIGs
Functional Definition
Physical Definition
Design Validation
Stage 1: Concept Development
Stage 2: Engineering Development
Stage 3: Post Development
IV.System Security Architecting Methodology Overview
Architecture Program
Software Security
Other Considerations of the Architecture
V.Program Effects
VI.Summary of Path to Dissertation Defense
Proposed Research Approach
Plan and potential risks
Evaluation Plan
Success Criteria
Potential contributions
References
Table of Figures
Figure 1: Layers of Information Assurance [98]
Figure 2: SABSA Matrix
Figure 3: System Decomposition [5]
Figure 4. ISSAP Architecture Method [4]
Figure 5: Research Timeline
- Introduction
There is no perfectly secure system. Threats are evolving and vulnerabilities are continually being exposed. The goal of system security is to reduce the risk to an acceptable level. Security is changing with technology. For every new application or system, new threats, vulnerabilities and risks arise. When there is a threat to a system, it can affect the system if a vulnerability exists. Residual risk is the leftover threats to the system when vulnerabilities can’t be mitigated. When there are vulnerabilities in a system, they must be mitigated to the extent possible. The application of security into a system can be seen through the layered views of information assurance.
In the commercial world there are certain information assurance laws and standards, such as Sarbanes-Oxley that govern the security requirements that must be applied to a system [8, 80]. In the Department of Defense one of the documents for security is the DoD Instruction 8500.2 [40]. There are multiple other security documents that are used, but the framework from the DoDI 8500.2 is fundamental. There is currently a move [20, 13] from the DoDI 8500.2 to the NIST SP 800-53 [71]. The supplemental guidance provided in [71] is very helpful to the system security engineer. The documentation, rules and requirements that must be followed are as ever changing as technology. In some respect the system security engineer must think like a lawyer in understanding the requirements, laws, regulations and their application to the system. In DoD systems, the contractor providing the system is on contract to meet a certain set of requirements. Proper application of security is not as simple as applying a few security products, but involves a paper trail of documentation and analysis.
The first part of this paper will present what Information Assurance is and its relationship within the overall security discipline. With the understanding of what needs to be accomplished, the research will focus on the systems engineering lifecycle methodology and where security can be better integrated so that there is a reduction to the overall lifecycle cost of security. The goal of this will also address the problems that security engineers face in the different stages of the systems engineering lifecycle. The second part of this researchwill be focused on the area of security architecture. Although there are common frameworks, there is not a solidified methodology to help ensure that the security architect has not left anything out. This leads into the need for a tool to help address vulnerability and risk assessments for large, complex systems. The goal of the proposed research will be to provide a tool to help in the creation and maintenance of a security architecture and to allow for a vulnerability and risk assessment to be done against the architecture. A security architecture must be completed as part of the work done for the systems engineering lifecycle, when security is correctly implemented. The last part of the proposed research will show how the use of this tool in conjunction with changes to the overall systems engineering life-cycle will reduce risk, cost and schedule slips due to unforeseen security issues. This part of the research will also outline the areas of concern and possible risk items that a security engineer needs to address as early in the lifecycle of a program as possible. This research will draw on lessons learned from past experience in working on large DoD programs, as well as current issues that are surfacing in the DoD realm. The conclusion of this research will result in a primer for those wanting to embark on becoming system security engineers or security architects in the DoD world, and new ways to look at security for those who have been in the field for a while. Many of the concepts will apply to the commercial world as well.
- Information Assurance
Information Assurance (IA) is the practice of managing risks related to information. IA primarily deals with the Confidentiality, Integrity, and Availability of information in order to ensure proper business or mission execution. In the commercial world, business execution is critical. In the DoD world, mission execution is paramount. Application of IA in a manner consistent with defense in depth is part of system security.
Confidentiality limits the access of information to authorized personnel. Integrity ensures data is not changed without proper authorization. Availability guarantees the accessibility of information to approved personnel [34]. IA also is concerned with authentication and non-repudiation. Authentication requires that correct identification occurs before an entity is given access to a system. Non-repudiation guarantees that the identification of the sender and recipient is known and cannot be faked, nor can the sender or recipient deny involvement.
Information assurance can be defined as measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities [76].
Including the elements of IA into a system throughout the life cycle is the primary purpose of the system security engineer. The protection of the innermost layers, such as software starts with an understanding that the systems cannot be physically manipulated.
Figure 1: Layers of Information Assurance [98]
Physical security provides this assurance. Physical Security as required by the 8500.2 [19]and in the newer SP 800-53 [71] should include automatic fire suppression system, automated fire alarms connected to the dispatching emergency response center, voltage controls, physical barriers, emergency lighting, humidity controls, a master power switch, temperature controls (for both equipment and humans), plan for uninterrupted power supply, disaster recovery procedures, as well as the requirement for personnel to be inspected (through badge inspection) and a second form of identification before allowed access.
Next the boundary of the systems from a cyber security purview must be assessed. Boundary Defense is a crucial aspect of the security posture. This is the first line of protection for the cyber aspects of a system. Without identifying and protecting the boundary, unnecessary chinks in the armor will appear.
Once boundary defenses are established, IA must dive into the system to protect data in transit. Data that flows within the system and to and from the enclave must be available and the confidentiality and integrity must be protected.
Data in Transit is one of the largest concerns in Information Assurance. It involves confidentiality, availability, integrity, and non-repudiation. Ensuring that data is safely moved from point A to B and that data integrity remains is one of the priorities.
A potential problem for data in transit is a breach of confidentiality. If the enemy can hijack the information it must be un-useable (although it is best if a prevention of the hijacking can be done). Another area of concern is availability. There is a need to prevent bottlenecks or single point of failures within the system.
Each of the aspects of IA must be applied to a system in order to provide a correct security posture. The question then remains, what is the best way to apply these requirements to a system in such a way as to explain them to those that must implement them. It is one thing for a system security engineer to understand the requirements. It is something entirely different to make these requirements accessible to the developers of the system.
One of the goals of this research is to find an effective manner of applying these principles to a system within the system engineering lifecycle, efficiently and as cost effectively as possible.
- System Engineering Lifecycle Overview
In today’s environment of security, it is necessary for the system security engineer to understand all aspects of systems engineering. In the realm of systems engineering, security engineering is considered a specialty that can be added into the design phase, if concurrent engineering is being employed, but is too often an after-thought. Something that is expensive and to most, it seems unnecessary. Although the perception about its necessity is changing, the engagement of security engineering hasn’t moved far enough along.
Many security engineers understand the security issues of a system, but do not recognize how they fit into the systems engineering development lifecycle. In most cases the systems security engineer shouldn’t be considered a specialist, but a core member of the systems engineering team. Every interface in a system whether a functional flow or a physical flow should be examined by the system security engineer for vulnerabilities.
Information assurance or Information System Security Engineering should not be cornered 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. This doesn’t truly cover the magnitude of effects that security has on a system, especially in the DoD realm. The mindset of security being just an add-on to the system as part of “specialization” can increase risk to the overall project. The idea that security is “specialty engineering” is brought to light in [5] in the author’s explanation of concurrent engineering. This view of security needs to be re-examined, as the vulnerabilities and risks to systems increase. The National Institute of Standards and Technology (NIST) have developed some insights into this, in [85], but this does not cover overall system implementation and development
This author of [86] would agree that security engineers should be system engineers, or at least have an understanding of system engineering. The other issue exposed in [87] and [96] is that “there is no common framework in any current evaluation scheme or criteria that directly supports measuring the combined security effectiveness of products.” This needs to be rectified. There are multiple frameworks that are useful for Systems Engineering and some have put together frameworks for security engineering, but these are not enough to fully integrate security into a large DoD program [37, 75, 91, 92, 97, 99].
One of the security architecture frameworks is the Sherwood Applied Business Security Architecture [91] which provides a matrix of questions that the security engineer should be able to answer about the system, as seen in Figure 2. This is a useful tool, but it can still be difficult for the security engineer to ensure that every aspect has been covered at the granular level.
Figure 2: SABSA Matrix
This portion of the research looks to address this issue: How can security be effectively combined in the systems engineering lifecycle? The outcome of this research will be a proposed method for including security into each aspect of the Systems Engineering Lifecycle Methodology, such that it looks at the overall system implementation.
There is a great difference between functional models of a system and physical models of a system. In understanding the system’s engineering lifecycle model at each step, the system security engineer should be involved. It is necessary that the system security engineer have a full understanding of a systems functional and physical architecture. Without being fully integrated into the systems engineering team, as well as in the integrated product teams (IPTs), it will be virtually impossible for information assurance to be baked in.
The term “baked in IA”, attributed to Dan Wolf, is easily said, but difficult to accomplish. There is a critical balance in employing security mitigations. Enough of the system must be understood to see where the vulnerabilities are, and what type of mitigations should be employed, yet it can’t be so far along that the design is in stone and there is no way to add in the correct mitigations. This balance seems to be the most difficult part of a system security engineer’s job. System security engineers tend to be zealous to protect the system, without understanding the underlying cost and schedule issues associated with certain types of mitigations. An example of this is the use of a cross domain solution.
A cross domain solution is employed when there is a need to bring unclassified data out of a classified environment. A cross domain solution is only one of several mitigations that can be used to separate data, but there is a cost associated with this. It can take a couple of years to certify and the type of data allowed through is limited. Depending on the type of data, the rule sets employed to allow for the transaction can greatly increase the cost of such a product. The system’s engineering perspective would be to look at the cost and schedule impacts of using such a device. The security engineer’s perspective typically looks at how well the device provides protection. It is necessary that the two mindsets be united in order to find the best approach.
In following the traditional systems engineering model, the security engineers would provide the technical data to the systems engineers, who would perform a trade study on the types of devices or products that can be used to accomplish a certain task. It is then typically the systems engineer that makes the final decision as to which product should be used, based on cost and schedule as well as on technical merit. There are three concerns that the systems engineer will look at in these trades: Advancing technology, specialization, and competition.
Advancing technology can increase capabilities but adds developmental risk. It leads to more innovation and comes in the form of new materials, new devices or new processes. The use of new technology can allow a company to match competitor’s performance. It can also aid a company in keeping their designs from using obsolescent pieces. Advance technology is one of the reasons to upgrade or implement a new system, but it is one of the biggest risks a program takes on. If advanced technology isn’t implemented, then a company risks being behind the competition, or may not be able to meet all the needed capabilities. This requires risk management, one of the primary responsibilities of the system engineer. The use of advanced technology should be carefully considered by the security engineer. New products may have a plethora of vulnerabilities that are unknown. New materials may inhibit emanations security and new process may not include necessary steps to ensure security.
Specialization can be broken down into different types according to the Systems engineering lifecycle methodology [5]. The types of specialization are:
engineering specialization (safety and security), hardware and software, tools, manufacturing processes, and systems integration. The systems integration specialization has given rise to two relatively new fields: interfaces (physical fit at component boundaries) and interactions (functional compatibility of components). The system engineer must partition the system and manage their interfaces and interactions. Although security is thought of as an engineering specialization, it cannot be put into such a neat little box, as it affects every aspect of system development, or should if it is implemented correctly.
The third concern is competition. Competition is broken into two pieces: system level trade-off analysis to choose the best solution, and external competition. During development the system engineer must determine which solution is best. External competition can be anything from trying to get the product out to market faster, to continuing to try and win bids based on cost and the ability to meet schedule. External competition between countries is also a consideration for the DoD and for some commercial projects.
Trade off analysis is the systems engineer’s tool to decide between competing factors in solutions. Without a proper trade off analysis, the program risks spending extra money, choosing the wrong design, and not meeting schedule. In some cases, the security aspects are lost in the trade. Although cost and schedule are critical, it is also important that the security engineer be involved in the trade to ensure that the protection level is adequate.
In the Department of Defense, approved products such as those tested by the Common Criteria/ NIAP or NIST labs are required for use in National Security Systems. Although the products are evaluated against a certain protection profile and provide great security, they may not be a good fit for the system at hand. This becomes a problem for the system security engineer. The security engineers will come to the IPTs and tell them that if a product is being used to protect the system, it must meet a certain Evaluation Assurance Level (EAL). If the product is being used to interface between segments, then not only must it meet the technical needs of the IPT but the systems engineers must ensure that it will work across the segments. In some cases, a specific device from an approved list will work, but what happens when the list doesn’t contain a product that can be used? The security engineer must find the solution. This is why it is critical that the security engineer must be a systems engineer. It is the systems engineer responsibility to ensure that the interfaces between segments are correct and that the flow of data will meet the operational need. It is the security engineer’s responsibility to protect the data in each of the segments, as well as in the flows from segment to segment, and especially those flows that breach the boundary of the system.