CSCE 548 Architectural Risk Analysis. CSCE 548 - Farkas2 Reading This lecture: – McGraw: Chapter 5 Next lecture: – Secure Software Construction Jan Jürjens,

Slides:



Advertisements
Similar presentations
Security+ All-In-One Edition Chapter 17 – Risk Management
Advertisements

Risk Assessment What is RISK?  requires vulnerability  likelihood of successful attack  amount of potential damage Two approaches:  threat modeling.
Networked Systems Survivability CERT ® Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA © 2002 Carnegie.
CSCE 522 Building Secure Software. CSCE Farkas2 Reading This lecture – McGraw: Ch. 3 – G. McGraw, Software Security,
CST 481/598 Many thanks to Jeni Li.  Potential negative impact to an asset  Probability of a loss  A function of three variables  The probability.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
1 Software Testing and Quality Assurance Lecture 14 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Sanjay Goel, School of Business/Center for Information Forensics and Assurance University at Albany Proprietary Information 1 Unit Outline Quantitative.
Risk Management.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Patching MIT SUS Services IS&T Network Infrastructure Services Team.
Comp 8130 Presentation Security Testing Group Members: U Hui Chen U Ming Chen U Xiaobin Wang.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Software Process and Product Metrics
Application Threat Modeling Workshop
Introduction to Network Defense
SEC835 Database and Web application security Information Security Architecture.
CSCE 548 Secure Software Development Risk-Based Security Testing.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation.
Information Systems Security Computer System Life Cycle Security.
Discussing “Risk Analysis in Software Design” 1 FEB Joe Combs.
Security Risk Management
Risk Analysis in Software Design Author: Verdon, D. and McGraw, G. Presenter: Chris Hundersmarck.
Slide 1 Using Models Introduced in ISA-d Standard: Security of Industrial Automation and Control Systems (IACS) Rahul Bhojani ISA SP99 WG4 Meeting.
CSCE 548 Secure Software Development Test 1 Review.
CSCE 548 Code Review. CSCE Farkas2 Reading This lecture: – McGraw: Chapter 4 – Recommended: Best Practices for Peer Code Review,
Web Security for Network and System Administrators1 Chapter 2 Security Processes.
Risk Assessment and Management. Objective To enable an organisation mission accomplishment, by better securing the IT systems that store, process, or.
Lesson 7-Managing Risk. Overview Defining risk. Identifying the risk to an organization. Measuring risk.
Telerik Software Academy Software Quality Assurance.
CSCE 522 Secure Software Development Best Practices.
1 ITGD 2202 Supervision:- Assistant Professor Dr. Sana’a Wafa Al-Sayegh Dr. Sana’a Wafa Al-SayeghStudent: Anwaar Ahmed Abu-AlQumboz.
CSCE 548 Building Secure Software. CSCE Farkas2 Reading This lecture: – McGraw: Chapter 1 – Recommended: CyberInsecurity: The Cost of Monopoly,
Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved.McGraw-Hill/Irwin.
CSCE 522 Secure Software Development Best Practices.
Lesson 20-Risk Management. Background  Risk management can be described as a decision-making process.  Effective risk management avoids costly oversights.
Chapter 11: Policies and Procedures Security+ Guide to Network Security Fundamentals Second Edition.
Introduction to Information Security
Security Administration. Links to Text Chapter 8 Parts of Chapter 5 Parts of Chapter 1.
CSCE 548 Secure Software Development Security Operations.
1 Figure 11-3: Risk Analysis Financially Sensible Protections  Risk analysis: Balance risks and countermeasture costs Enumeration of Assets  Assets:
CSCE 201 Secure Software Development Best Practices.
Visual 1. 1 Lesson 1 Overview and and Risk Management Terminology.
What is RISK?  requires vulnerability  likelihood of successful attack  amount of potential damage Two approaches:  threat modeling  OCTAVE Risk/Threat.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
Information Security Governance and Risk Chapter 2 Part 2 Pages 69 to 100.
INFORMATION SECURITY MANAGEMENT L ECTURE 8: R ISK M ANAGEMENT C ONTROLLING R ISK You got to be careful if you don’t know where you’re going, because you.
Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
INFORMATION SECURITY MANAGEMENT L ECTURE 8: R ISK M ANAGEMENT C ONTROLLING R ISK You got to be careful if you don’t know where you’re going, because you.
Stoimen Stoimenov QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
CSCE 548 Secure Software Development Penetration Testing.
Dr. Gerry Firmansyah CID Business Continuity and Disaster Recovery Planning for IT (W-XIV)
Risk management «Once we know our weaknesses, they cease to do us any harm.» G.C. Lichtenberg.
CSCE 548 Secure Software Development Risk-Based Security Testing
CSCE 548 Secure Software Development Use Cases Misuse Cases
TOPIC 3 RISK MANAGEMENT.
Security Engineering.
CSCE 548 Secure Software Development Test 1 Review
Air Carrier Continuing Analysis and Surveillance System (CASS)
RISK MANAGEMENT An Overview: NIPC Model
I have many checklists: how do I get started with cyber security?
Security Threats Severity Analysis
INFORMATION SYSTEMS SECURITY and CONTROL
Must cost less than possible Impact
Societal resilience analysis
Cybersecurity Threat Assessment
ONAP Risk Assessment – Preparation Material - Overview of the Process - Terminology - Assumptions
Presentation transcript:

CSCE 548 Architectural Risk Analysis

CSCE Farkas2 Reading This lecture: – McGraw: Chapter 5 Next lecture: – Secure Software Construction Jan Jürjens, Towards Development of Secure Systems using UMLsec, Lodderstedt et. al, SecureUML: A UML-Based Modeling Language for Model-Driven Security,

CSCE Farkas3 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field 5. Abuse cases 6. Security Requirements 2. Risk Analysis External Review 4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

CSCE Farkas4 Requirement Analysis Identify and document the customer’s requirements for a proposed system Client: brief idea on what the system should do Requirement Analyst: – Detailed system requirements – Implied requirements – Regulatory requiremetns – Create: Software Requirements Specification (SRS) What the product should do

CSCE Farkas5 Software Requirement Specification Functional requirements – Features a software has – Implied requirements Non-Functional requirements – Performance, reliability, security, etc. – Effects quality of product Regulatory requirements – Law, standards, organizational regulation, contract, etc. External interface requirements – Interaction with other software and hardware Acceptance criteria – Confirm that the software is working according to the client’s specification

CSCE Farkas6 Review SRS Cost effective: getting the requirements right Manual review: team of experts (at least 3) for hours/session Detection rate of good review: 60-90% More cost effective to do requirement review than code testing alone

CSCE Farkas7 Design Flaws 50 % of security problems Need: explicitly identifying risk Quantifying impact: tie technology issues and concerns to business Continuous risk management

CSCE Farkas8 Security Risk Analysis Risk analysis: identifying and ranking risks Risk management: number of discrete risk analysis exercises, tracking risk, mitigating risks Need: understanding of business impact

CSCE Farkas9 Security Risk Analysis Learn about the target of analysis Discuss security issues Determine probability of compromise Perform impact analysis Rank risks Develop mitigation strategy Report findings

Learn about the target Specifications, documents, design, etc. Discuss, brainstorm Determine major components and security needs Use/study software Identify threats CSCE Farkas10

Discuss security issues Argue about how the product works, areas of disagreement Identify possible vulnerabilities (lists, tools) Identify exploits and protection Understand security controls (current, planned) CSCE Farkas11

Determine probability of compromise Attack scenarios Historical data Balance control against threat CSCE Farkas12

Perform impact analysis Impact on assets and business goals Impact on security posture Impact on social sector CSCE Farkas13

Rank risk Connect to business goals Regulatory requirements Customer’s needs Capabilities CSCE Farkas14

Develop mitigation strategy Countermeasures – Technical – Societal – Ecomonics Capabilities and preferences CSCE Farkas15

Report findings Major vs. minor risks Decision support for mitigating risk CSCE Farkas16

CSCE Farkas17 Traditional Risk Analysis Financial loss-based – Balance cost vs. loss Mathematically derived “risk rating” – Threat, probability, and impact Qualitative assessment – Knowledge-driven or anecdotal factors – Social Impact

CSCE Farkas18 Terminology Asset: object of protection Risk: probability that the asset will suffer an attack Threat: the actor (agent) who is the source of danger Vulnerability: defect or weakness in the system Countermeasures or safeguards: management, operational, and technical control to protect confidentiality, integrity, and availability Impact: impact on the organization Probability: likelihood that the event will occur (high, medium, low)

CSCE Farkas19 Knowledge Requirements Three basic steps: – Attack resistance analysis Attack patterns and exploit graphs – Ambiguity analysis Knowledge of design principles – Weakness analysis Knowledge of security issues Forest-level view: What does the software do? – Critical components and interaction between them – Identify risk related to flaws

CSCE Farkas20 Risk Calculation Financial loss: ALE = SLE x ARO – ALE – annualized loss expectancy – SLE – single loss expectancy – ARO – annualized rate of occurrence Distinguish between attacks based on frequency of occurance Qualitative risk assessment (e.g., loss of reputation, loss of trust, etc.) ROI: return-on-investment – Note: security is more like insurance… it will never hit a “big payoff”

CSCE Farkas21 Limitations of Traditional Approaches Hard to find correct data for statistical distribution Do not necessarily provide an easy guide Modern applications are complex: contextual variability of risk

CSCE Farkas22 Modern Risk Analysis Address risk as early as possible in the requirements level Impact: – Legal and/or regulatory risk – Financial or commercial considerations – Contractual considerations – Social Impact Requirements: “must-haves,” “important-to- have,” and “nice-but-unnecessary-to-have”

CSCE Farkas23 Basic Risk Analysis Tailored for specific vulnerabilities High-level overview Meaningful results Cross-tier analysis – different trust zones Use of deployment pattern Decomposing software on a component-by- component basis

CSCE Farkas24 Risk Analysis Practice Ad-hoc manner Does not scale and not repeatable or consistent Depends on knowledge and expertise of analyst Results are difficult to compare

CSCE Farkas25 Attack Resistance Analysis Information about known attacks, attack patterns, and vulnerabilities – known problems – Identify general flaws: using secure design literature and checklists – Map attack patterns: based on abuse cases and attack patterns – Identify risk in the architecture: using checklist – Understand and demonstrate the viability of known attacks

CSCE Farkas26 Ambiguity Analysis Discover new risks Parallel activities of team members  unify understanding – Private list of possible flaws – Describe together how the system worked Need a team of experienced analysts

CSCE Farkas27 Weakness Analysis Understanding the impact of external software dependencies – Middleware – Outside libraries – Distributed code – Services – Physical environment – Etc.

CSCE Farkas28 Social Vulnerability of Computer Attacks Vipul Gupta

CSCE Farkas29 Background What is Social Vulnerability – No single definition – Generally accepted as – inability of the society to move out of harm’s way, that is, incase of a disaster (or computer attack) how easily can the society (or the victim (s)) recover from it Why Social Vulnerability – Every computer attack has economic and social impacts – Social impacts of a computer attack are usually not quantifiable

CSCE Farkas30 Background Impacts on our society (examples) – – Death caused by malfunctioning of computer based equipment – Suicide due to losing everything in a computer based fraud scheme – Ruining of one’s credit – Depression, anxiety, other emotional or physical health related issues – “Internet Addiction” – may be caused by the ‘presence’ of computer – Etc. – What happens if the computer based system is not available for the intended use (DoS or virus attacks considered)

CSCE Farkas31 Importance of Social Vulnerability Computers are an essential part of today’s life Large scale computer attacks will inhibit the functioning of the society (yes, they may be possible in future) Are some sections of the society likely to be more damaged in the event of a computer attack ? (Ability to recover easily from those attacks)

CSCE Farkas32 Background Research Goal: – Map the social vulnerability of computer attacks based on geographical locations within South Carolina – Develop a model for social vulnerability assessment of computer attacks (currently no such model exists)

CSCE Farkas33 Background Research on Social Vulnerability in Natural Disasters – Extensive research has been done in this area – Hypothesize the similarities and differences between a computer attack and a natural disaster (why?) Most natural disasters are prone to specific geographical areas Do computer attacks exhibit the same feature (based on the social factors)

CSCE Farkas34 Research Activities Preliminary hypothesis – – Comparison of natural and computer disasters – Study the factors influencing computer attacks – Identified 9 factors to indicate vulnerability to attacks: updates, installed security software, malicious scanning, firewall protection, “free” downloads, P2P sharing, unverified downloads, shared system/passwords, system maintenance

CSCE Farkas35 Research Activities Considered age, education (computer experience), income (wealth) as the social factors influencing the vulnerability (+/-) to study – – Are some people more prone to computer attacks than others? Can some people recover from a computer attack faster than others? Income EducationAge The 9 factors

CSCE Farkas36 Next Class Expressing Security Needs during design