Presentation is loading. Please wait.

Presentation is loading. Please wait.

Secure Software Development Chapter 2 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010.

Similar presentations


Presentation on theme: "Secure Software Development Chapter 2 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010."— Presentation transcript:

1 Secure Software Development Chapter 2 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

2 Software Security 2 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 No noble thing can be done without risks. Security is risk management A continuous risk management process is a necessity. Following the RMF is a full lifecycle activity, –no matter whether you're working on a little project or –a huge corporate application strategy. The basic idea is simple: identify, rank, track, and understand software security risk as it changes over time. Central to the notion of risk management is the idea of describing impact. There is nothing more frustrating to a technical person than identifying a serious problem that never gets fixed. We can avoid that frustration by properly describing impact. RMF allows a consistent and repeatable expertise-driven approach to risk management. Application of RMF in parallel with standard SDLC activities. For a small project, the RMF can be applied by a part-time team member. The RMF can be applied even in non-software situations. No noble thing can be done without risks. Security is risk management A continuous risk management process is a necessity. Following the RMF is a full lifecycle activity, –no matter whether you're working on a little project or –a huge corporate application strategy. The basic idea is simple: identify, rank, track, and understand software security risk as it changes over time. Central to the notion of risk management is the idea of describing impact. There is nothing more frustrating to a technical person than identifying a serious problem that never gets fixed. We can avoid that frustration by properly describing impact. RMF allows a consistent and repeatable expertise-driven approach to risk management. Application of RMF in parallel with standard SDLC activities. For a small project, the RMF can be applied by a part-time team member. The RMF can be applied even in non-software situations. A Risk Management Framework

3 Software Security 3 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 SWS

4 Software Security 4 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Five fundamental activities. –Understand the business context –Identify the business and technical risks –Combine and prioritize the risks, producing a ranked set –Define the risk mitigation strategy –Carry out required fixes and validate that they are correct RMF is a closed-loop process with five basic activity stages, as mentioned. Five fundamental activities. –Understand the business context –Identify the business and technical risks –Combine and prioritize the risks, producing a ranked set –Define the risk mitigation strategy –Carry out required fixes and validate that they are correct RMF is a closed-loop process with five basic activity stages, as mentioned. The Five Stages of Activity

5 Software Security 5 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Software risk management occurs in a business context. Risks are unavoidable and are a necessary part of software development. Commonly, business goals are neither obvious nor explicitly stated. Business goals include but are not limited to increasing revenue, meeting service-level agreements (SLAs), reducing development costs, and generating high return on investment (ROI). to gather data to answer the all-important "Who cares?" question. Software risk management occurs in a business context. Risks are unavoidable and are a necessary part of software development. Commonly, business goals are neither obvious nor explicitly stated. Business goals include but are not limited to increasing revenue, meeting service-level agreements (SLAs), reducing development costs, and generating high return on investment (ROI). to gather data to answer the all-important "Who cares?" question. 1: Understand the Business Context

6 Software Security 6 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Business risks directly threaten one or more business goals. Business risks have impacts that include –direct financial loss, –damage to brand or reputation, –violation of customer or regulatory constraints, –exposure to liability, and –increase in development costs. Risk management needs tying technical risks to the business context in a meaningful way. Business risks directly threaten one or more business goals. Business risks have impacts that include –direct financial loss, –damage to brand or reputation, –violation of customer or regulatory constraints, –exposure to liability, and –increase in development costs. Risk management needs tying technical risks to the business context in a meaningful way. 2: Identify the Business &Technical Risks

7 Software Security 7 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Recognizing technical risks is a high-expertise undertaking that usually requires years of experience. Important to be able to discover and describe technical risks and map them (through business risks) to business goals. A technical risk is a situation that runs counter to the planned design or implementation of the system under consideration. Technical risks involve impacts such as unexpected system crashes, avoidance of controls, unauthorized data modification or disclosure, and needless rework of artifacts during development. Recognizing technical risks is a high-expertise undertaking that usually requires years of experience. Important to be able to discover and describe technical risks and map them (through business risks) to business goals. A technical risk is a situation that runs counter to the planned design or implementation of the system under consideration. Technical risks involve impacts such as unexpected system crashes, avoidance of controls, unauthorized data modification or disclosure, and needless rework of artifacts during development. …

8 Software Security 8 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Large numbers of risks will be apparent in almost any given system. Identifying these risks is important, but it is the prioritization of them that leads directly to creation of value. The prioritization process must take into account which business goals are the most important to the organization. Typical risk metrics include but are not limited to – Risk likelihood, –Risk impact, –Risk severity, and –number of risks emerging and mitigated over time. Collection and display of these metrics can be automated. Large numbers of risks will be apparent in almost any given system. Identifying these risks is important, but it is the prioritization of them that leads directly to creation of value. The prioritization process must take into account which business goals are the most important to the organization. Typical risk metrics include but are not limited to – Risk likelihood, –Risk impact, –Risk severity, and –number of risks emerging and mitigated over time. Collection and display of these metrics can be automated. 3: Synthesize and Rank the Risks

9 Software Security 9 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Technical analysts are pretty good at finding technical problems, but not so good at determining what to do about them. Nobody wants to hear about their problems without hearing some suggested fixes. A risk analysis is only as good as the mitigation strategy it contains. It is always easier to break something than to design something that can't be broken. Typical metrics to consider are financial in nature and include estimated cost, ROI, method effectiveness, and % of risk coverage. Technical analysts are pretty good at finding technical problems, but not so good at determining what to do about them. Nobody wants to hear about their problems without hearing some suggested fixes. A risk analysis is only as good as the mitigation strategy it contains. It is always easier to break something than to design something that can't be broken. Typical metrics to consider are financial in nature and include estimated cost, ROI, method effectiveness, and % of risk coverage. Stage 4: Define the Risk Mitigation Strategy

10 Software Security 10 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 The central concern at this stage: –to validate that software artifacts and processes no longer bear unacceptable risk. This stage should define and leave in place a repeatable, measurable, and verifiable validation process that can be run from time to time to continually verify artifact quality. The central concern at this stage: –to validate that software artifacts and processes no longer bear unacceptable risk. This stage should define and leave in place a repeatable, measurable, and verifiable validation process that can be run from time to time to continually verify artifact quality. Stage 5: Carry Out Fixes and Validate

11 Software Security 11 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. The loop in the RMF shown in the Figure. Risk management is a continuous process. Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. The loop in the RMF shown in the Figure. Risk management is a continuous process.

12 Software Security 12 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010 One foundational approach that is critical to any science is measurement. Look at this phrase: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but ….” One foundational approach that is critical to any science is measurement. Look at this phrase: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but ….” Measurement

13 Software Security 13 Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti ) – Fall 2010


Download ppt "Secure Software Development Chapter 2 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010."

Similar presentations


Ads by Google