Project Management and Security Requirements Engineering

7032CEM Project Management and Security Requirements Engineering Agenda - Management of Security Projects - Requirement Engineering, Threat Modelling and Risk Management - Organisational Issues - Project Methodology - Top–down or iterative approach - Hazard analysis - Security Requireme...

7032CEM Project Management and Security Requirements Engineering Agenda - Management of Security Projects - Requirement Engineering, Threat Modelling and Risk Management - Organisational Issues - Project Methodology - Top–down or iterative approach - Hazard analysis - Security Requirements Engineering - Managing Security Requirements - Parallelising the process - Team Management 2 Learning Objectives Upon completion of this session, you should be able to: Explain how a proper project management can improve system security Understand the core security requirements involved in the project management 3 Management of Secure Systems Development Introduction So far, we have explored several different security concerns and techniques, such as encryption, access control, authentication and others. In general, to build a secure system, a systematic way to select protection aims and mechanisms should be followed. This systematic approach usually involves topics like the system engineering, risk analysis and team management. 5 Managing a Security Project The hardest part of the project management is usually to identify the system assets that need to be protected and also to propose mechanisms and techniques that could give effective solutions to this problem. Performing requirement engineering, threat modelling, and risk management is often an efficient approach that could improve the security of a system. 6 Requirement Engineering Requirement engineering (aka requirement analysis) is the process of defining the user’s expectations for the system to be developed. In more detail, the determined requirements indicate the functional specification of the system including its operations and features. This process is an important aspect of the project management as it is a team effort that demands a combination of hardware, software and human factors engineering expertise as well as skills in dealing with people. 7 Threat Modelling Threat Modelling is the process of identifying potential threats and vulnerabilities of the system to be developed. As part of the threat analysis process, the engineers need to suggest security countermeasures that could effectively mitigate the impact of these threats to the system assets. Threat modelling is an iterative process that includes the following: Definition of system assets, Identification of what each security/system application does with respect to these assets, Development of a security profile for each application, Identification and prioritisation of potential threats, Documentation of potential undesirable events and the actions taken in each case. 8 Risk Management Risk management is the process of identifying, assessing and controlling threats to an organization’s assets (i.e. capital and earnings). A typical risk management process includes the following steps: Risk identification: The company identifies and defines potential risks that may negatively influence a specific company process or project. Risk analysis: Once specific types of risk are identified, the company then determines the odds of it occurring, as well as its consequences. The goal of the analysis is to further understand each specific instance of risk, and how it could influence the company's projects and objectives. Risk assessment and evaluation: The risk is then further evaluated after determining the risk's overall likelihood of occurrence combined with its overall consequence. The company can then make decisions on whether the risk is acceptable and whether the company is willing to take it on based on its risk appetite. Risk mitigation: During this step, companies assess their highest-ranked risks and develop a plan to alleviate them using specific risk controls. Risk monitoring: Part of the mitigation plan includes following up on both the risks and the overall plan to continuously monitor and track new and existing risks. 9 Organisational Issues Further to the aforementioned issues, security projects require the proper management of issues related to the organisation. Usually these issues refer to: Staff complacency Quality of Product Development Identification of the correct problem Inexperienced Security Staff and Managers Staff satisfaction or Moral hazard 10 Project Methodology Project Methodology – An introduction System engineering is about managing complexity, which can be of two type, the incidental and intrinsic complexity respectively. Incidental complexity could involve difficulties in programming as inappropriate languages or tools are used making the process impossibly tedious and error- prone. On the contrary, intrinsic complexity is related to the development of large and complex systems. Intrinsic complexity usually requires a methodological approach will break the original complexity problem into manageable sub- problems and restrict the extent to which these sub-problems can interact. 12 Pick Your Methodology Wisely: Top – Down or Iterative? To avoid or alleviate such problems, a system engineer needs to select a methodology (i.e. development model) that will fit the purposes and functioning of the system to be developed. Two main approaches of System Development Life Cycle models: Top – Down models (i.e. Waterfall model) Iterative models (i.e. Spiral model) 13 Incorporating Hazard Analysis Hazard Analysis is used to identify the potential hazards and assess their hazard level during the examination of a system. Specifically, Hazard Analysis can: ○ Determine potential hazards ○ Determine worst credible or most likely consequences ○ Determine ways in which they could lead to undesirable outcomes and their likelihood 14 15 Examples of System Failures Samsung Note 7: Nissan recalls vehicles: ○ Airbag failure o Explosion of device ○ Hazard: software was o Hazard: Battery failure improperly classifying the passenger front seat as a child or empty seat 16 Incorporating Hazard Analysis Goals/Purpose of Hazard Analysis: ○ Development of system: Examination of the new system to identify and assess potential hazards and eliminate or control them ○ Operational management: Examination of an existing system to identify and assess hazards to improve the level of safety or to train personnel or to formulate a safety management policy or to increase motivation for efficiency and safety of operation ○ Certification: Examination of a planned or existing system to demonstrate its level of safety and to be accepted by the authorities or public 17 Types of Hazard Analysis Forward and backward analysis: Forward (bottom – up) analysis: ○ It takes an initiating event (or condition) and traces it forward in time ○ Result is a set of states that represents the effects of the initiating event ○ Used to calculate both the effect of an initiating event and later effects that are not necessarily caused by the initiating event Backward (Top – down) analysis: ○ It starts with the final event and works backward 18 Hazard Analysis Techniques A wide range of Hazard Analysis Techniques: FTA (Fault Tree Analysis) ETA (Event Tree Analysis) FMEA (Failure Modes and Effects Analysis) FMECA (Failure Modes, Effects and Criticality Analysis) HAZOP (Hazard and Operability Study) 19 Fault Tree Analysis (FTA) FTA is a backward (or top - down) analysis technique that starts from an identified hazardous event to determine its causes. It analyses the causes of hazards, it does not identify hazards. The top event indicates the system failure that is examined. Each level in the tree lists the more basic events that are necessary and sufficient to cause the problem shown in the level above it. Each level of the tree shows the same thing in more detail. 20 Construction of Fault Tree Analysis takes a particular system state/failure as top event Then the next level (below the top event) represents the causal events related to the top event and so on The logical relations between the causal events are expressed using logic gates. These logic gates are: AND, OR, XOR etc. Probability can also be added to the Fault Tree indicating the likelihood of the top event to happen. 21  Car crash at Crash probability = 0.001311 or FTA example: junction 3 on M6 approximately 1 in 1000. If 6000 cars use the side road every year, (Adapted from Harrison (2009)) then it is expected that 6-7 crashes per year may occur AND Car on side road at Car on M6 at Junction 3 fails to junction 3 stop P=0.01 P=0.1311 OR Driver of car on Driver of car on side road did not side road could stop not stop P=0.12 OR P=0.0111 OR Driving too Driver was Vision Road too Brake Tyres fast too ill obscured slippery failure worn P=0.1 P=0.01 P=0.01 P=0.01 P=0.001 P=0.0001 Event Tree Analysis (ETA) ETA is a forward (or bottom – up) analysis technique that starts from an initiating event exploring multiple scenarios that follow that event. ETA can determine all the possible sequences of events that follow the initiating one. All these possible sequences of events can be used to indicate the different paths that lead to success or failure of the examined system. 23 ETA: Constructing the Diagram ETA construction and probabilities calculation (Adapted from Wikipedia) 24 ETA: Calculating the Probabilities The total probability of each path is calculated by multiplying together probabilities of various branches At each branch the sum of the probabilities is always equal to 1. The probabilities that are calculated are only as good as the individual values. 25 ETA: A Protocol Example Ps = 0.85 Ps = 0.9 PF = 0.05 Ps = 0.92 Ps = 0.018 Ps = 0.95 PF = 0.002 PF = 0.02 Ps = 0.018 Ps = 0.02 PF = 0.002 Ps = 0.009 PF = 0.03 PF = 0.001 PF = 0.01 Ps = 0.025 Ps = 0.03 PF = 0.005 Ps = 0.04 Ps = 0.007 PF = 0.003 PF = 0.01 Ps = 0.012 Ps = 0.009 PF = 0.05 PF = 0.008 Ps = 0.0009 PF = 0.01 PF = 0.0001 PF = 0.001 Adapted from Usenix.org Security Requirements Engineering Managing Security Requirements Security requirements engineering is often the most critical task of managing secure system development. Often, security requirements need to be adjusted to new changes that occur to the system due to: Bug fix (i.e. functional changes) System tuning/upgrade (i.e. small modifications) Evolving environment (i.e. legislation changes) Organisation (i.e. structural or operational changes) 28 Parallelising the Process A common industry practice is to have a security engineer working in different security aspects of the system to be developed. On the contrary, a good management plan would suggest the parallelisation of the security process by including as many experts as possible to inspect and develop the security of a system. Note that the parallelisation approach could also be used in other process of the system development and testing. 29 Managing the Team To enhance security, you need to build a team with the proper knowledge, skills and right incentives. One of the hardest issues to get right is the balance between having everyone on the team responsible for securing their own code, and having a security guru on whom everyone relies. Thus, a solution to this problem could be the recruitment, training and management of your team of developers in such a way that they have or obtain the relevant skills and experience and you create a culture in which they get progressively better at writing secure code. 30  Conclusion Summing up: Managing a project to build, or enhance, a system that has to be secure is not an easy task. Certain management steps need to be followed in order to achieve the best security level possible. Security assurance is not only about system development itself, but it also depends on the system’s environment and the development team. 31 Questions Thank you for your attention! Any Question? 32