Engineering Secure Software

Slides:



Advertisements
Similar presentations
Sachin Rawat Crypsis SDL Threat Modeling.
Advertisements

Implementing Tableau Server in an Enterprise Environment
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation.
Ragib Hasan University of Alabama at Birmingham CS 491/691/791 Fall 2012 Lecture 2 08/21/2012 Security and Privacy in Cloud Computing.
Engineering Secure Software. Does Security Even Matter?  At your table, introduce yourselves: Your name, degree, & app domain What is your favorite software.
Engineering Secure Software. Uses of Risk Thus Far  Start with the functionality Use cases  abuse/misuse cases p(exploit), p(vulnerability)  Start.
Automated Security Testing with Formal Threat Models Frank Xu Ph.D.
Access Control Methodologies
1 Cryptography and Network Security Third Edition by William Stallings Lecturer: Dr. Saleem Al_Zoubi.
Information Networking Security and Assurance Lab National Chung Cheng University The Ten Most Critical Web Application Security Vulnerabilities Ryan J.W.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
OWASP Mobile Top 10 Why They Matter and What We Can Do
SSH Secure Login Connections over the Internet
Threat Modeling for Cloud Computing (some slides are borrowed from Dr. Ragib Hasan) Keke Chen 1.
Ragib Hasan Johns Hopkins University en Spring 2010 Lecture 2 02/01/2010 Security and Privacy in Cloud Computing.
Firewall Implementation and Design Term: January 2005 Dana Epp COMP 4706.
Architecting secure software systems
Security Architecture
Computer & Network Security
SEC835 Practical aspects of security implementation Part 1.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
APPLICATION PENETRATION TESTING Author: Herbert H. Thompson Presentation by: Nancy Cohen.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 1 Security Architecture.
Practical Threat Modeling for Software Architects & System Developers
Copyright © 2003 Jorgen Thelin / Cape Clear Software 1 A Web Services Security Framework Jorgen Thelin Chief Scientist Cape Clear Software Inc.
Need for Security Control access to servicesControl access to services Ensure confidentialityEnsure confidentiality Guard against attacksGuard against.
OWASP Building Secure Web Applications And the OWASP top 10 vulnerabilities.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 1 Security Architecture.
Introduction and Overview of Information Security and Policy By: Hashem Alaidaros 4/10/2015 Lecture 1 IS 332.
Computer Security By Duncan Hall.
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
INTRODUCTION TO COMPUTER & NETWORK SECURITY INSTRUCTOR: DANIA ALOMAR.
Module 7: Designing Security for Accounts and Services.
Presented by Mike Sues, Ethical Hack Specialist Threat Modeling.
By Ramesh Mannava.  Overview  Introduction  10 secure software engineering topics  Agile development with security development activities  Conclusion.
Engineering Secure Software. Does Security Even Matter?  Find two other people near you Introduce yourself What is your favorite software development.
ASP.NET 2.0 Security Alex Mackman CM Group Ltd
Web Database Security Session 12 & 13 Matakuliah: Web Database Tahun: 2008.
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.
Engineering Secure Software. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow.
Matthias Rohr Practical Threat Modeling with Microsofts Threat Modeling Tool 2016.
Threat Modeling for Cloud Computing
Threat Modeling - An Overview All Your Data is Mine
Design for Security Pepper.
VIRTUALIZATION & CLOUD COMPUTING
Engineering Secure Software
Evaluating Existing Systems
Threat modeling Aalto University, autumn 2013.
Cryptographic Hash Function
Outline What does the OS protect? Authentication for operating systems
Server Concepts Dr. Charles W. Kann.
Evaluating Existing Systems
Off-line Risk Assessment of Cloud Service Provider
Security Engineering.
Outline What does the OS protect? Authentication for operating systems
Engineering Secure Software
Chapter 19: Building Systems with Assurance
Engineering Secure Software
CS 465 Terminology Slides by Kent Seamons Last Updated: Sep 7, 2017.
Engineering Secure Software
Security Risk Assessment
Copyright Gupta Consulting, LLC.
Engineering Secure Software
Security Risk Assessment
Engineering Secure Software
White Box testing & Inspections
Security Principles and Policies CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Cryptography and Network Security
Presentation transcript:

Engineering Secure Software Threat Modeling

Uses of Risk Thus Far Start with the functionality Use cases  abuse/misuse cases p(exploit), p(vulnerability) Start with what to protect Goals  High-level Risks  Indicators  Tests Assets Domain, domain, domain Today: start with threats © 2011-2012 Andrew Meneely

STRIDE Spoofing Tampering Repudiation Information disclosure Denial of Service Elevation of privilege I am Spartacus. Looks like Johnny got an A! Didn’t Johnny have a B? Johnny’s SSN is… Please try again later. sudo rm –rf /home/johnny

STRIDE ~> Security Properties Kind of the inverse of security properties, but not fully Tampering  Integrity violation Repudiation  Integrity of the history violation Information Disclosure  Confidentiality violation Denial of service  Availability violation Spoofing Violating authentication You are not who you say you are (e.g. session hijacking, guessing passwords) Elevation of privilege Violating authorization You can access things you should not be allowed to access (e.g. permissions, network access)

Repudiation A threat to the belief that integrity was preserved Didn’t Johnny have a B? Provenance Logs Hash (digest) algorithms Third-party verification e.g. artwork, copyright registration Ultimately, another type of integrity violation …but not exactly a tampering threat Protect against tampering? Filter access, etc. Protect against repudiation? Keep a reliable history

Architectural Risk Analysis Discuss security risk once most of the architecture is settled Motivation: a few good early decisions goes a long way e.g. incorporating encryption e.g. authentication & access control concerns e.g. choice of technologies used Must-haves vs. Nice-to-haves at the design level Emphasis of design flaws over code-level vulnerabilities Note: “Risk Analysis” is not necessarily “Modeling”

Threat Modeling Architectural risk analysis tool Methodology: Built at Microsoft, on top of Visio STRIDE concept Methodology: Define architecture elements Processes External interactors Data store Connect with data flows Define trust & machine boundaries Map STRIDE to each element & relationship

Primitives External interactors Process Data store Data flow e.g. clients, other systems, dependencies Process Architecture-centered functionality e.g. dispatcher, input validator Data store e.g. database, file system Data flow Domain & Design-specific explanation of data e.g. “HTTP Login Requests”

Boundaries Machine boundaries Trust boundaries Same physical machine If the input can be trusted

e.g. Generic Webapp with MVC Note: example is typically more domain-specific e.g. How will we prevent spoofing of the browser? e.g. How will we prevent tampering of queries? e.g. How do we avoid persistent data from the DB being disclosed? E.g. How will we avoid repudiation of the database?

Analysis What the tool does… Threats arise when… Eliminates categories of threats Forces you describe mitigations Helps record assumptions Go directly to file a bug Threats arise when… Flows cross boundaries More processes Forgetting what to trust

Tips for Threat Modeling Be honest with the process Make sure the model represents reality (or what you really believe reality will be) Consider all types of threats – code-level vulns are just a “for example” As with all modeling, use appropriate complexity Overly-simplified? Departs from reality You get exactly what you put into it – no new knowledge Overly-complicated? Too much to analyze “Check it off the list” syndrome Test your model Think of a specific security concern, then try to see where it fits in your threat model

Today’s Activity Groups of 2-3 Go through the Threat Modeling activity Tool: c:\Program Files (x86)\Microsoft\SDL Threat Modeling\SDLTM.exe For attendance, find me to check you off for today before leaving