A Systems Engineering Approach For Security System Design

A Systems Engineering Approach For Security System Design Ian Alston & Simon Campbell Selex Galileo Ltd [email protected], [email protected] Abstract The number of application areas where security of resources, whether this is people, information or physical property, is ever increasing as our world culture changes and the potential threats to individuals rises. The threats that security systems need to mitigate against are becoming both more complex and also asymmetric. In association with this the number of emerging technologies that can be applied to security systems is also increasing, and together with current & changing threats, is resulting in a more complex system with many interacting and possibly distributed elements. This paper describes how Systems Engineering provides a methodical design approach enabling a design engineer to understand all the contributing factors and analysing the cost/performance trade of alternative solutions. It shows that security elements should no longer be an afterthought once the main system has been designed – but security should be tightly integrated with other system functions as a set of requirements or design constraints. Once these requirements and constraints have been determined the most appropriate security approach for a given situation can be determined. The paper then describes how the methodical approach is used to elaborate the solution based on the constraints, make appropriate design decisions to architect a solution and finally implement a system, using an integrated engineering discipline approach, that is fit for purpose. 1. Introduction Systems involving some element of security are increasingly becoming more complex and critical where failure of the whole system or the security aspects of the system would result in significant losses or disruption to individuals, organisations or countries. Examples include: – The inter-bank money transfer system – The national/international telephone system – Airport security systems – Battlefield defences In general, security systems can be characterised in the following manner (but not limited to): – Physical security systems Those which protect a facility, resource or physical media (electronic or hard copy). – Information security systems Those which protect data from unauthorized access, use, disclosure, destruction, modification, or disruption to access. In both cases, the security system can be thought of as a set of processes and functions that protect a resource (physical or data) from access or malicious use. While there are many different types of security systems that can be used in many application areas, the fundamental problem is no different to developing any type of engineering solution i.e. develop a system that meets the customer requirements and functions as intended subject to internal and external constraints while being implemented with the most appropriate technologies. An essential element in today’s world of challenging budgets must be an analysis of the cost effectiveness of alternative designs. One may ask the question, what are the differences between designing for security systems and designing for any other type of system? From a purely design perspective, hardly any – it is the repercussions of having a system that doesn’t meet its intended use or having vulnerabilities within it that distinguish one from the other. If a hairdryer system fails to operate as expected, the outcome could simply be “a bad hair day”. If an airport security system fails to operate, thousands of lives and huge financial repercussions are at stake. Security Engineering is similar to other systems engineering activities in that its primary motivation is to support the delivery of engineering solutions that satisfy pre-defined functional and user requirements, but with the added dimension of preventing misuse and malicious behaviour – these are simply additional requirements in a purely systems engineering context. We also need to remember that security within a system is now a systemic and whole life-cycle issue from initial conception to decommissioning. Therefore the design engineers have a responsibility to design security into a system from the outset rather than adding it as an adjunct sub-system later in the design lifecycle. This is no longer a simple problem and requires a methodical design approach to take into account all elements of the system and those factors that affect its overall performance in an 2010 International Conference on Emerging Security Technologies 978-0-7695-4175-4/10 $26.00 © 2010 IEEE DOI 10.1109/EST.2010.27 107 integrated engineering process. Systems Engineering provides this methodical approach. The International Council on Systems Engineering (INCOSE) defines Systems Engineering as [1]: “an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: – operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.” This may seem overkill for many systems/applications as Systems Engineering requires some “up front” investment in time and resources with the aim of reducing risk in achieving a system solution that meets the needs. Arguing for a rigorous Systems Engineering approach has to take into account not only the enhanced likelihood of getting it right (which is at least desirable), but also the risk impact of getting it wrong (which may be critical). Having assessed the trade-offs we must tailor the Systems Engineering approach for the level of risk and benefit. In addition, unlike in traditional discipline-specific engineering (such as electrical or mechanical) or speciality-specific engineering (such as reliability or maintainability), Systems Engineering does not use a linear reductionist process to produce a viable product, system, or solution. It is a much more complicated iterative, re-entrant, and parallel activity that aims to achieve an acceptable degree of optimality taking into account a wide range of stakeholders. Those undertaking systems engineering must have appropriate levels of experience and expertise in many of the traditional discipline engineering fields and specialties that might come into play in a typical project. A robust Systems Engineering approach becomes increasingly essential as system complexity increases. How else can we keep track of the increasing complexity of interfaces, interactions, and emergent properties? Not only that but larger systems often form part of, or rely upon, existing infrastructures and capabilities. The customer may have a poor definition of these pre-existing assets, the original providers may have long since departed, and yet the cost of complete replacement is unacceptable. To address a so-called "brownfield" development situation Systems Engineering needs to take into account both the new aspects and also has to survey and define those pre-existing elements that influence and interact with the system. A typical lifecycle approach to Systems Engineering is the common V-model depicted in Figure 1. It demonstrates the elaboration of the solution/design into a set of implemented building blocks on the left hand side with the integration of these building blocks and corresponding verification that they meet their intended functionality on the right hand side of the V. This paper describes how this generic Systems Engineering approach can be applied to the design of a system in such a way that the security aspects are treated as just one of the overall system requirements/functions. Figure 1: Systems engineering V-model 2. Understanding the Problem A system is never operated in a vacuum. It is usually an assembly of sub-systems, people and processes working as one to provide an overall behaviour with associated performance that is not achievable by the individual elements. INCOSE [1] defines a system as: “A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systemslevel results. The results include system level qualities, properties, characteristics, functions, behaviour and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000).” It should also be remembered that a system always exists within a larger system and operates within an environment. As such it has a boundary and dependencies with other systems. So when thinking of a system we 108 must also define the boundaries of that system. Some typical examples of security systems and what they may or may not contain, i.e. their boundaries, are indicated below: • A tank regiment in the Army - is it simply the tanks and guns, or does it include the soldiers, the command and control systems, logistics, government policy, civilian support, etc. • A CCTV security system – is it cameras, video display, video or does it also include the alert processing, operating team, the data archiving system, guards, dogs, link to police, etc. • Prison boundary protection – a high fence around a set of buildings and associated lighting. But does it also include other surveillance means, the guards, information systems, etc Figure 2 shows a generic system scenario. Event or Input System SubSystem System Performance & Behaviour System Boundary Operational Environment Event or Input System SubSystem System Performance & Behaviour System Boundary Operational Environment Event or Input System SubSystem System Performance & Behaviour System Boundary Operational Environment Figure 2: System context To fully understand the problem at hand we need to consider the whole problem within its context in a holistic manner. We need to understand the system structure and dependences between elements of the system and we need to understand the system from the different perspectives of numerous stakeholders. Successful Systems Engineering requires an element of "systems thinking" (thinking about the bigger picture). This may involve developing a good working understanding of the operational environment or the sub-system components, in terms of system hierarchy, to the system in question. A broadening of the thought process can allow previously unspecified or unpredicted aspects to come to light which could have significant bearing on the viability of the design solution. But how can we achieve all this and reflect the different views whilst combining them into a comprehensive understanding of the overall system and without getting bogged down with implementation details? We use a variety of techniques such as: • Brainstorming o A group problem-solving technique in which members spontaneously share ideas and solutions. Usually used at the initial stages to begin to understand the problem space. • Diagrams: o Rich Pictures, Scenario, Spray, Multiple Cause, Fishbone, Affinity o All mechanisms for learning about complex or ill-defined problems by producing diagrammatic representations of the problem space. Ideal for presenting information about the problem space so that it can be expanded as knowledge and understanding grows and inter-dependencies are understood. Usually documents the initial concept solution. • Modelling & simulation o Creating an abstraction of reality using mathematical or process definitions which can then be executed to determine its behaviour under various operating conditions. For security systems an important activity is threat modelling - identify threats, attacks, vulnerabilities, and countermeasures that may be relevant to the system. Used throughout the design & development lifecycle but in this context is used to understand operational needs and predict initial performance parameters. Useful input to Trade Studies when selecting a solution from a list of viable solutions. • Virtual & Synthetic Environments o Computer simulated environments used to simulate real world scenarios, allowing users to be immersed in a visual experience of the simulated scenario and in some cases allowing interaction through input devices. Can be used throughout the design & development lifecycle but in this context used to inform capability needs or initial solution requirements based on user interaction. • Physical Models (e.g. real hardware & software) o Allow visualisation and/or instrumentation of a component to understand its behaviour. • Technology demonstrators / Prototypes o A representation of the real system built to demonstrate and/or investigate the intended behaviour when operating in its real operating environment. • Trade studies o Activity to identify the most balanced technical solutions among a set of proposed viable solutions when judged against a set of criteria covering both technical and business measures. All these techniques allow the engineering team to work collaboratively, analyse the emergent properties and 109 begin to partition the problem into manageable subproblems. No single technique is better than the other and in most situations a number are used together to understand the problem space. This stage is as much about understanding the need i.e. requirements, as it is in developing a solution. It allows us to look at all aspects of the system, including security, as a whole. They will allow the engineers to gain knowledge of the security objectives of the user or system which will feed into other stages of the lifecycle as requirements and/or constraints on the design. These techniques invariably produce many differing ideas to solving the problem with different emphasis/compromise on function & performance. The important idiom of “every idea is a good one until proven otherwise” is very prominent in this phase of the lifecycle. It is also important to note that in understanding the problem we need to consider through life considerations. Designing for manufacturability and supportability when in service, need to be key considerations in this early concept stage. These considerations will flow through the whole of the design & development lifecycle and should not be underestimated – any solution being a compromise between system function, and its performance, manufacturability and supportability. Thus the “Exploit, Sustain and Destroy” bubble of Figure 1 has a significant impact on the Capability Statement and requirements Specification of the system. Supportability is extremely important where a system will be in service for many years. 3. Developing a range of possible solutions Having developed our understanding of the problem and produced a range of ideas to solve it, the same techniques that were used to develop those ideas can be used to allow ideas to be grouped together, discarded as they don’t match the need (in terms of requirement and business proposition) or elaborated as being a possible candidate solution. This process is shown diagrammatically in Figure 3 depicting the use of two complementary types of diagrams aiding the divergent and convergent thinking. Situation or Problem Divergent Thinking Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Understanding or Solution Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Convergent Thinking Spray Diagrams Multiple Cause Diagrams Figure 3: Understanding the problem Having produced a number of candidate solutions to our problem, developing multiple views of the system assists the engineers in formalising their thoughts and ensuring that all constraints and requirements have been accounted for. In addition having a structured, consistent approach for describing and developing these systems i.e. looking at the architecture of the system, aids the partition of the problem into manageable elements. Architecting achieves benefits for customer collaboration (validating their needs and requirements), system development (concisely and comprehensively describing the system’s architecture to the development engineers), and technology transfer (reuse of domain architectural styles and patterns). Different architectural views can be considered together, e.g. enterprise, functional, data, security, physical, technology, ensuring that the solution has taken into account all aspects of the requirements. Indeed, for most information security systems the data and security aspects are unquestionably linked and must be considered as a single entity. There are a number of architectural frameworks that can be used to assist in the elaboration and interaction of the different architectural views including but not limited to: Zachman [2], TOGAF [3], MoDAF [4] & DoDAF [5]. If we architect our system correctly, the resulting system architecture: • defines all the elements of the system together with their budgets, performance and capacity; • details the interfaces between the elements placing these boundaries where the interactions are weakest i.e. less likely to fail due to interface failure or malicious intent, and where integration and test is achievable and easiest; • details the information flow into, through and out of the system and for security systems details the type of security coding/encryption required at each node to ensure that the security objectives are met and that the susceptibility of the information flows to malicious attack are fully understood; • takes into account the interaction of the user with the system through a defined human interface and human factors integration; • builds in fault tolerance - maintaining capability when components, sub-systems and especially people fail or where malicious attack is used to circumvent security design. 4. Producing a system level design Having produced an architectural description of our solution, we need to ensure the suitability and effectiveness of the initial solution design. Our key aim here is to reduce the risk of implementation and production by developing a design that is fit for purpose. This is achieved by developing executable models and 110 prototypes of the chosen solution enabling the performance of the system to be analysed. Sensitivity analysis around key design parameters ensures that the design margins are adequate. In many cases the initial design is modified based on the performance and sensitivity analysis and this is fed back to the architectural model to ensure consistency. While the system level design describes the functionality of the solution, it does not specify how each element that it consists of will either work internally or be implemented. Therefore key sub-system attributes and requirements are elaborated from the system requirements together with the partitioning of performance data to each sub-system. This is not a one way flow of requirements; as with the detailed system design there may be a need to revisit the system architecture because a sub-system cannot meet its requirements. Once the sub-system requirements and constraints are known they can be implemented. In many cases the subsystem will undergo a mini lifecycle of requirements analysis, architectural solutions and then detailed design as described in the previous sections in order to arrive at a specification with enough detail that it can be built and in some cases procured as a COTs item. With the advent of model driven engineering approaches and executable specification languages, many techniques exist today that allow models used in the system level specification to be elaborated to sub-system detailed designs. This permits performance analysis at sub-system level and in some cases automatic implementation of the sub-system design into hardware and/or software items. 5. Verifying the implementation Having produced the sub-system elements that make up the system, integration processes are performed to assemble the system according to the architectural design. This is a bottoms-up process with elements at the lowest levels of the system architecture being integrated first and verified that they meet their requirements and performance specifications. In terms of Figure 1, we are starting to traverse the right hand side of the V-model. This bottom-up approach also verifies that interfaces between the elements perform as intended reducing errors and mitigating the risk as the system is built up. Verification is the process of determining that the system “is built right” and can take the form of inspection, analysis, demonstration and testing. These basic verification activities are: • Inspection – examining compliance with requirements by observation (e.g., paint colour, weight, etc.). • Analysis – using analytical methods, data or simulations to show theoretical compliance. It is usually used where testing under realistic conditions can’t be performed (e.g. reliability, availability, etc) • Demonstration – a qualitative exhibition of functional performance i.e. the system response to input stimuli produces the required responses. • Test – the capability of an element is verified subject to controlled operating conditions, real or simulated. Verification and its associated processes require careful planning and preparation in order to ensure that all requirements are deemed satisfied. It should also be performed, where appropriate, as early as possible in the lifecycle using design data, models, simulations or prototypes. As part of the initial concept stage where the defined security objectives were set, the security testing strategy would have been detailed and this forms part of the overall verification strategy. Detailed security testing would be planned in the same way as system functional testing. Threat Modelling can be an invaluable asset in defining the tests to be performed and drawing up detailed test plans. In most cases a verification cross reference matrix (VCRM) is produced detailing how each requirement will be verified, the activities performed and their outcome. This is a vital input to the certification process i.e. assurance that the system has been developed and performs its intended functions in accordance with any applicable legal and industrial standards. Once the full system has been implemented and verified against its requirements, validation processes demonstrate that the system as built satisfies stakeholders’ needs. In other words “have we built the right thing”. While a system may meet all its requirements as originally specified it may not meet the end users needs when used in its intended operational environment. Validation usually involves end users and customer stakeholders and involves some form of acceptance tests. An important aspect of validation actually occurs in the requirements elicitation stage described in Section 2. During requirements elicitation it is vital that assurance from the users and customer stakeholders is sought that the requirements of the system are the correct requirements taking into account the systems intended use and operational environment. Requirements validation is a key element of the requirements analysis process. 6. Summary In this paper we have explored the nature of security systems and how different requirement priorities and risks may apply. Security Systems are similar in principle to any other type of system except that the emphasis on certain requirements may be different, there is the added dimension of preventing misuse and malicious behaviour by others and the impact of errors in the design may be catastrophic. 111 We have shown that Systems Engineering can provide a design approach which helps to ensure that a system solution addresses the real need, is viable, and that design errors are kept to a minimum. In adopting a Systems Engineering approach understanding the problem is a key aspect. Once the problem is defined and understood candidate system solutions can then be proposed and the most appropriate selected for further development. Having produced a viable system design, the solution can be implemented following which, by a process of integration and verification, the system can be shown to meet its specified requirements. It is then validated to ensure it meets the overall needs of the end users and stakeholders and can ultimately be accepted by them. Contributions to the development of best practice Systems Engineering approaches as described in this paper both in terms of work within its own organisation and in collaboration with bodies such as INCOSE as part the UK Advisory Board is seen as key to the future provision of successful systems by SELEX Galileo. In the business sector of integrated sensor solutions and through life capability management for defence systems and homeland security applications across air, land, sea and space SELEX Galileo has found it to be essential to develop and implement robust and effective Systems Engineering policies, processes and tool sets coupled with developing a workforce capability able to address the principal Systems Engineering activities of requirements engineering, functional analysis, design synthesis, analysis and modelling, integration, test, qualification, trials, validation, acceptance and certification of products and systems using the generic Systems Engineering lifecycle approaches presented in this paper as a core framework. 7. References [1] INCOSE, “INCOSE Systems Engineering Handbook“, INCOSE-TP-2003-002-03.2, January 2010. [2] Zachman, “John Zachman’s Concise Definition of the The Zachman Framework". Zachman International. 2008, http://www.zachmaninternational.com/concise definition. pdf. [3] “Welcome to TOGAF”, The Open Group Architecture Framework, http://www.opengroup.org/togaf/. [4] “MOD Architecture Framework (MODAF)”, MOD, http://www.mod.uk/DefenceInternet/AboutDefence/What WeDo/InformationManagement/MODAF/. [5] “DoD Architecture Framework”, http://cionii.defense.gov/sites/dodaf20/index.html. 112