Information System Security Engineering and Management INFORMATION SECURITY IN THE SYSTEM ENGINEERING PROCESS Dr. William Hery hery@isis.poly.edu

Overview of Systems Engineering Talk Outline Overview of Systems Engineering Overview of Systems Security Engineering Application to POSA example

Systems Engineering Science Component Engineering Systems Engineering Determines what Is Component Engineering Determines what Can Be Systems Engineering Determines what Should Be

Systems Engineering--One View Definition of Systems Engineering (NASA SE Handbook) Systems Engineering is a robust approach to the design, creation, and operation of systems. Systems Engineering consists of Identification and quantification of system goals Creation of alternative system design concepts Performance of design trades Selection and implementation of the best design (balanced and robust) Verification that the design is actually built and properly integrated in accordance with specifications Assessment of how well the system meets the goals

Definition of Systems Security Engineering “The Art and Science of discovering user’s security needs and designing and making, with economy and elegance, (information) systems so that they can safely resist the forces to which they may be subjected” --IATF (Information Assurance Technical Forum)

What is a System? There is no standard definition. My vague definition from the systems engineer’s perspective: A system is a combination of interacting components operating within an external logical and physical environment. Each component has attributes that describe what it does and how it does it. Components have relationships with other components which describe how the components interact to form a system. A system also interacts with other elements in its environment For the Systems Engineer (SE), a system is the part the SE has some control over; the environment is what you have to take “as is.” A system has relationships with external components in its environment. These are critical in the SE process

IT Systems Components may include hardware (processors, memory, data links, I/O devices, etc.), software (OS, application, network OS, etc.), firmware, users, and administrators Relationships include messages between software components, OS/HW interface, network/CPU interfaces, user interfaces, etc. The system/environment boundary depends on the system you are designing. For example: If you are developing a database application system on top of an existing database system, the database and OS are part of the environment. It your are developing everything from scratch, or are doing a complete system re-design, then the OS & DBMS, platforms, etc. are part of your system If user and administrator processes and actions are part of what you are designing, they are part of the system, otherwise they are part of the environment. Understand the boundary of your system when you start

The “Vee” Model of System Development User Requirements & Concept of Operations System Demonstration & Validation Systems Engineering Domain System Requirements & Architecture System Integration & Test Component Design Component Integration & Test Component Engineering Domain Procure, Fabricate, & Assemble Parts

What is Systems Engineering? Many different definitions All define a process of developing goals and requirements, designing the system and development, verifying the requirements are met at each step. All include successive refinements and iteration on the above steps. In this talk, we will just use a generic systems engineering philosophy (based on IATF), not a specific, detailed process--other versions will look a bit different. This is a systems engineering process, not the systems engineering process The important thing is that security analysis be integrated into whatever systems engineering process you use.

Systems Engineering Iterative Loop Requirements Synthesis Assessment Next Phase (Requirements Synthesis Assessment)

Information System Security Engineering (ISSE) Part of overall systems engineering process In a simple sense, security is just another source of requirements Iterates security requirements, architecture design, and assessment through multiple levels of detail as part of the systems engineering process We suggest where risk analysis, threat analysis, vulnerability analysis, and policies fit into this process

Information System Security Engineering (ISSE) Includes architecture, design, development, deployment System Architecture: where are the security functions performed? Where are new external interfaces required to support security? System design includes selection of commercial products: platforms, operating systems, DBMS, networks, etc., as well as design of custom HW and SW Security requirements should be a part of all product selection criteria (not just selection of security specific components such as firewalls and crypto) Security design includes designing the management processes and procedures for individuals that are required to maintain a secure system throughout its life cycle For example, if a firewall is part of the system design, management procedures for firewall configuration, updating (products and configuration) to respond to new threats, firewall log reviews, exception response, etc. should be designed as part of the system design

Information System Security Engineering (continued) Risk analysis is a key part of the requirements prioritization--it lets you know what you might be losing if you relax a security requirement Security should be an integral element from the start

The Frameworks Quagmire

One Common SE Model: Waterfall Model Concepts Requirements Design Implementation Test Installation and Checkout Operation Maintenance Retirement

Another View: IATF Systems (Security) Engineering Process

Primary SE and ISSE Phases in IATF Model Discover Needs Discover Information Protection Needs Define System Requirements Define System Security Requirements Design System Architecture Design System Security Architecture Develop Detailed Design Develop Detailed Security Design Implement Systems Implement Systems Security Assess Effectiveness Assess Information Protection Effectiveness

SE: Discover Needs The first step is to get the “customer’s” view of what is needed and how it will be used The customer is whoever is paying for the system design and development, not necessarily the ultimate user of the system. The need is based on an interaction between customer and design/development organization The output should be clearly and succinctly documented and signed off on by both parties. (Called the Mission Needs Statement in IATF)

ISSE: Discover Needs At this phase, the primary task is to understand the major classes of potentially sensitive data and functions used in the system. These are the IT Assets that will be the starting point for the risk analysis.

POSA Mission Needs (System Concept) Mission Need: Put a device at each cash register to allow a customer to swipe a credit or debit card, and enter the PIN for a debit card. The information will be sent to the Central Facility for credit approval, with the response sent to the register. Potentially sensitive data and functions: Credit/debit card information (confidentiality) Approval function (integrity and availability)

SE: Define System Requirements “It’s the requirements, stupid” (for those of you who remember the 1992 presidential election) For any system, there are too many conflicting requirements, including Functionality: exactly what the system is supposed to do Non-functional requirements : reliability, security, maintainability, etc. They may be invisible to users until something goes wrong Usability: The user’s ability to use the system efficiently and correctly Cost: Full life cycle cost, including design, implementation, unit costs for components, annual maintenance costs, etc. Time to market Requirements are not the mechanism used to satisfy them. Selecting the mechanism is part of the design process e. g., not allowing file transfers initiated outside the corporate intranet may be a derived requirement, but using a firewall is a design decision

Requirements (continued) Requirements are part of every iteration through detailed design, not just the requirements phase At each iteration of the SE process loop, requirements are allocated to elements of the architecture, design, etc. e. g., a confidentiality requirement may be allocated to a network carrying the information to be kept confidential At each iteration, more specific requirements are derived from the allocated requirements for an element based on the design of that element e. g., an allocated confidentiality requirement on a network may lead to a derived requirement for encryption

Requirements (continued) Requirements should be documented at every step, including the allocation of requirements to system elements and where derived requirements came from. This is critical for later phases of a project, requirements compliance table, requirements traceback (more later), and as a starting point for system modification in the future Major software packages (e. g., RDD-100) are used for requirements capture, allocation, derivation, linking to architectures, etc.

Requirements (continued) At the heart of the design process are the trade studies that help prioritize requirements (what is the difference between a requirements list and a set of goals???) so that changes in requirements are made knowingly and rationally Many SE processes assume all requirements are known before you start the system architecture. In practice, requirements often change as you understand a system. Some initial high level requirements should not be removed (e. g., confidentiality for some classes of information) New requirements may be added even after a system id fielded (e. g., new security requirements in response to new threats) Initial requirements and changes in them must be agreed to by the customer in writing.

CONOPS At the requirements stage, a high level view from the user’s perspective of how the system will operate is also generated. This view is documented in the Preliminary Concept of Operations (Preliminary CONOPS). This is used as a guide to how the system will work to use as a basis for developing the high level requirements. A very simple preliminary CONOPS for the POSA system is: A customer goes to the register with their purchases, which are rung up by the clerk. The total is displayed on the POSA, and the customer presents a credit/debit card swipes their own card, enters the PIN (if it’s a debit card), and the information is sent to the CFAC for approval or denial of credit. The initial POSA diagram is also essentially a statement of the CONOPS

Security CONOPS Primarily about the system interfaces, since the architecture is not yet known From the user view, not about technology Address inherent risks of running the system at all

ISSE: Security Requirements Definition Primarily about the critical data entering and leaving the system, since system internals are not yet known. The primary source for security requirements is the Risk Analysis In the initial requirements phase, the IT assets at risk are inventoried and valued, categorized, or prioritized Threats can are also identified at this stage Vulnerabilities in the system are typically not know at this point, since there is not yet even a system architecture Some vulnerabilities through required external interfaces may be identified

Other sources of initial requirements Legal requirements (a later topic) Broad government or corporate policies; these may be derived from other risk analyses; e. g., the PA security policy cited in the risks lecture provides a requirement to any application system developed for the State. Image preservation, avoiding embarrassment, etc. (really a form of subjective risk analysis) FUD (Fear, Uncertainty, and Doubt) by management--this is an ill informed version of risk aversion that should be replaced by a risk analysis

Sample POSA Security Requirements Confidentiality of credit/debit card information Integrity of approval function Availability of approval function …

SE: Design System Architecture This is a high level view of the major functional components of the system--what they do, but not how they do it in detail Interactions between functions are a key part of the architecture Specific technologies are usually not yet included Essentially breaking the overall system function into sub-functions and showing how to tie then together. Functional block diagrams are used Designing the architecture is an art, evaluating it is a science

System Requirements vs. System Architecture What the system has to do How components fit together to do it

Design System Architecture Decompose higher-level functions identified in requirements Requirements associated with the higher level are allocated to lower level functions. Includes analysis of candidate system architectures, function and process, interfaces (internal and external), components, etc.

ISSE: Design System Architecture Allocation of security functions to system components May result in new system components (e. g. a firewall) External interfaces are critical Many threats attack through external interfaces New external interfaces may be required, e.g., access to an existing PKI Potential vulnerabilities are now added to the risk analysis, e.g., networks sniffing once a network is added to the architecture

POSA Architecture CFAC POSA Register USER Store Network POSA Register link Register User Interface USER Note: this is simpler than usual, since we have identified no internal POSA node functions--usually that is a major part of the architecture

POSA Security Requirements Allocation Confidentiality of credit/debit card information: Store network POSA Register link Integrity of approval process: Clerk (assuming we include clerk’s actions in the system) Availability of approval process: Note: all get the same allocation because this system is so simple

SE: Develop Detailed Design Analyze trade-offs/design constraints The trade studies are at heart of the design process Trade studies should reflect all applicable requirements, functional and non-functional Performance models, reliability models, etc. are used to ensure requirements are met Detailed component and interface specifications Process may be iterated several times adding greater detail Identify candidate commercial off-the-shelf (COTS)/government off-the-shelf (GOTS) products for buy vs. build trade-offs Consider life-cycle support Map all requirements to system elements (Compliance Matrix) Map all system elements back to requirements (Requirements Traceback)

ISSE: Develop Detailed Security Design ISSE and SE teams iterate designs ISSE team allocates security requirements to system elements or new security specific elements ISSE determines new external interfaces for security (e. g., interface to PKI or automated security update system) ISSE develops vulnerability analysis for overall design (you need to know something about the to assess vulnerabilities Use asset and threat models to get risk profile Identify countermeasures Provide risk reduction and countermeasure cost information to overall trade studies Evaluations are relative to risk requirements

Sample POSA Trade Study: Store Network Internal Ethernet WiFi Power Line Net Install. Cost High Low HW/SW/config. Maint. cost Moderate Performance Meets rqmts with room for growth Meets rqmts with no room for growth Security Future support Development Schedule risk Minimal …

Security in the System Engineering Process (Generic) Mission Need CONOPS Assets at Risk Threat Analysis Functional Rqmts Prelim. Risk Analysis Legal Rqmnts Primary Sec Rqmts System Arch. Assess Corp/Org Policy Security Arch Other Rqmts Derived Sec Rqmts System Design Risk Analysis Vulner. Analysis Assess Security Design

Other “Anti-SE” Design Models and Security Design philosophies, such as rapid prototyping, agile programming, and extreme programming do not fit into the SE model at all. Although these are somewhat different methods, they do not start with detailed requirements, but instead build and use pieces out from a small core, adding capabilities, defining interfaces,etc. based on experience gained by using the system, essentially getting requirements and designing from the inside out, not top down. They focus on functionality, not other non-functional requirements

How do these relate to the ISSE model Since the ISSE model presented is based on the requirements driven analysis methods of SE, there is no direct mapping But, these techniques are usually applied to application level software, not more complete systems They are often applied to applications running in an established infrastructure (OS, DBMS, networks, etc.) which may have been developed more formally

What Might We do? Many security requirements are based on the sensitive information already used by the infrastructure (have ISSE methods been used there???) When the new applications use any of the sensitive data classes, the existing risk analysis should be applied to derive security requirements for the new application If new sensitive data classes are being used in the new application, a new risk analysis needs to be performed, and new security requirements developed The new security requirements are then allocated to elements of the system, and the design and implementation completed. How do we ensure that the new application does not introduce new system level vulnerabilities? This is an interesting area to explore…