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

Slides:



Advertisements
Similar presentations
By: MSMZ. Objective After completing this chapter, you will be able to: Explain 2 contract review stage List the objective of each stage of the contract.
Advertisements

Chapter 14 Fraud Risk Assessment.
JEFF WILLIAMS INFORMATION SECURITY OFFICER CALIFORNIA STATE UNIVERSITY, SACRAMENTO Payment Card Industry Data Security Standard (PCI DSS) Compliance.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Documentation 1 Comprehending the present – Investing in the future.
Management: Analysis and Decision Making
Risks  All projects have some degree of risk  Risks are issues that can cause problems  Delay in schedule  Increased project costs  Technical risk.
Projmgmt-1/33 DePaul University Project Management I - Risk Management Instructor: David A. Lash.
Planning a measurement program What is a metrics plan? A metrics plan must describe the who, what, where, when, how, and why of metrics. It begins with.
Secure Software Development Security Operations Chapter 9 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010.
Unit 201 Models of Software Development Life Cycle (SDLC) The objective of this section is to introduce you the idea of software process – a coherent set.
CSC 395 – Software Engineering Lecture 9: Testing -or- How I Stopped Worrying and Learned to Love the Bug.
CMM Overview - 1 © Paul Sorenson CMPUT Software Engineering refs. IEEE Software, March 1988, 73-79, and IEEE Software, July 1993, (Capability.
7.2 System Development Life Cycle (SDLC)
1.
Risk Management CS 414, Software Engineering I Mark Ardis, Rose-Hulman Institute January 28, 2003.
RISK MANAGEMENT IN SOFTWARE ENGINEERING RISK MANAGEMENT IN SOFTWARE ENGINEERING Prepared by Prepared by Sneha Mudumba Sneha Mudumba.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Testing and Cost / Benefit Tor Stålhane. Why cost / benefit – 1 For most “real” software systems, the number of possible inputs is large. Thus, we can.
Visual 3. 1 Lesson 3 Risk Assessment and Risk Mitigation.
Secure Software Development SW Penetration Testing Chapter 6 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010.
Chapter 10.
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Project Risk Management. The Importance of Project Risk Management Project risk management is the art and science of identifying, analyzing, and responding.
Chapter 8: Systems analysis and design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Risk Analysis vs Security Controls. Security Controls Risk assessment is a flawed safeguard selection method. There is a tendency to confuse security.
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Management & Development of Complex Projects Course Code - 706
Understand Application Lifecycle Management
Requirements Engineering Requirements Elicitation Requirements Analysis Requirements Validation Requirements Management.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Tingxuan Liu Risk Management in Software engineering.
Software Test Metrics When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure,
Test Metrics. Metrics Framework “Lord Kelvin, a renowned British physicist, is reputed to have said: ‘When you can measure what you are speaking about,
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Corporate Governance and Risk Management. Introduction Corporate Governance What does it mean? and Why does it matter? Risk Management Challenges of growth.
Dr. Tom WayCSC Testing and Test-Driven Development CSC 4700 Software Engineering Based on Sommerville slides.
IT Strategy for Business © Oxford University Press 2008 All rights reserved Chapter 12 IT Security Strategies.
1 Figure 11-3: Risk Analysis Financially Sensible Protections  Risk analysis: Balance risks and countermeasture costs Enumeration of Assets  Assets:
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Software Engineering Lecture # 1.
Planning and implementing Customer relationship management projects
The Implementation of BPR Pertemuan 9 Matakuliah: M0734-Business Process Reenginering Tahun: 2010.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Chap 8: Administering Security.  Security is a combination Technical – covered in chap 1 Administrative Physical controls SE571 Security in Computing.
Secure Software Development Abuse Cases Chapter 8 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Software Requirements Specification Document (SRS)
Prepared By: Razif Razali 1 TMK 264: COMPUTER SECURITY CHAPTER SIX : ADMINISTERING SECURITY.
Secure Software Development Security Operations Chapter 9 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
Ashima Wadhwa.  Probably the most time-consuming project management activity.  Continuous activity from initial concept through to system delivery.
Serving IT up with ITIL By Thane Price. IT is the laboratory’s pit crew  Goal : Make technology transparent while accomplishing valuable internal customer.
Formal methods its uses and limitations. A little about formality Objective knowledge / information Objective knowledge / information Information brought.
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
Name: Date: Author: Version:
THINK DIFFERENT. THINK SUCCESS.
Introduction and implementation OWASP Risk Rating Management
Software Quality Engineering
VENDORS, CONSULTANTS AND USERS
Risk Management CSCE 489/689 (Software Security) Fall 2018
Baisc Of Software Testing
Software Risk Management
Presentation transcript:

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

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

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

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

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

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

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. …

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

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

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

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.

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

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