FIT 5003 Software Security Apostolos Fournaris (Lecturer)
Apostolos.fournaris@monash.edu
Dr. Ron Steinfeld (Chief Examiner)
ron.steinfeld@monash.edu
Faculty of Information Technology Monash University, Australia
1
Why study Software Security?
2
Why study Software Security?
• Target Credit-Card Attacks (Dec. 2013)
• 40 Million CC numbers stolen
• 90 lawsuits filed against Target
• Target spent $61 Million responding to breach
• Target profits fell in holiday period by 46%
3
Why study Software Security?
4
Why study Software Security?
Windows Server Message Block (SMB) protocol
US National Security Agency discovered -> EternalBlue Shadow Brokers: EternalBlue -> WannaCry
WannaCry Patch is released two months before.
5
Why study Software Security?
NotPetya
which started as a fake Ukrainian tax software update, infected hundreds of thousands of computers in more than 100 countries in just a few days. This ransomware is a variant of an older attack dubbed Petya, except the later attack uses the same exploit behind WannaCry.
NotPetya malware changes its behavior when Kaspersky security products are detected.
6
Why study Software Security?
The Heartbleed Bug
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
7
Why study Software Security?
Google
Apple
IBM
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference= 720951&SearchOrder=4
8
Why study Software Security?
9
Why study Software Security?
Meltdown
Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware vulnerabilities allow programs to steal data which is currently processed on the computer.
Spectre
10
Why study Software Security?
While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents.
11
Why study Software Security?
AI for Security
How about the Security of AI systems?
12
The Basics… Roles
• Black Hats: attempt to break the security of a system without legal permission
• Grey Hats: First generation black hats motivated by the challenge of finding vulnerabilities and increasing system security
• Second Generation of Black Hats: Black hats motivated by promise of financial gain (in reality… criminals)
• Third Generation: Information Warriors: Black hats motivated by ethical, moral, or political goals
• White Hats: their work is to uphold the law and provide security assurances to users
• Their activity is bounded by rules, laws, and a code of ethics.
• They play on the defensive side. Any activity in an offensive role can be traced to
strengthening the defense.
• software engineers should be white hats→write code that is resistant to attacks.
1. write code that is lacking vulnerabilities.
2. A second activity is to locate vulnerabilities already existing in a given codebase. This involves locating the security-critical code and looking for bugs known to cause problems.
3. A final activity is to integrate security features into code. This may include authentication mechanisms or encryption algorithms. In each case, the feature must be integrated correctly
for it to function properly.
13
Why is software security important?
•
Compromised software can lead to: • Loss of productivity
• Eg, DoS attacks, loss of data • Loss of trust
• “It’s hard to build and easy to lose: a single violation of trust can destroy years of slowly accumulated credibility.” – Jakob Nielsen
• Loss of money
• Loss of business due to loss of trust or competitive advantage
• Expense of fixing the damage
• Expense of fixing security vulnerabilities
14
Objectives of this unit
• Demonstrate the importance of developing secure software
• Introduce various security threats, vulnerabilities and controls that need to be addressed during the development of secure and trusted software (systems)
• Introduce secure (and insecure) programming principles and practices
• Motivate you as a software developer to apply secure programming principles and practices in your projects
15
Objectives of this unit
Objectives for this Introductory module
• Put software security into perspective
• Define the concepts of vulnerability, threat, attack and
countermeasures
• Characteristics of a security-minded developer
• Define trust and how to increase trustworthiness of software
16
Terminology
Adversary (threat agent) – An entity that attacks, or bares a threat to, a system…. (Black Hat)
System Resource (Asset) – Data; a service provided by a system; a system capability; an item of system equipment; a facility that houses system operations and equipment.
Threat – A potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm.
Vulnerability – Flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.
Risk – An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.
Attack -An assault on system security that derives from an intelligent threat; a deliberate attempt to evade security services and violate security policy of a system.
17
Terminology – Mitigation
Mitigation strategy includes:
1. Countermeasure-Anaction,device,procedure,or technique that reduces a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken.
2. Security Policy – A set of rules and practices that specify how a system or org provides security services to protect sensitive and critical system resources.
• What all these does this mean in terms of Software Security? • Not a straight forward solution.
• Due to software complexity there is a plethora of countermeasures
• Security policy→A secure Software design strategy→A secure Software Development Cycle.
18
Terminology… Interactions
19
The Security by Design concept
• For the common software user the functionality of a program remains the same between a secure version of it and an insecure version
• Hard to justify the need for security…
• Typically, in most software solutions security is an after-thought
• Patching a program in order to make it secure (while originally it wasn’t) is not a good practice. Why?
• What we need is to include security at the software design and development time
• “Software security is the idea of engineering software so that it continues to function correctly under malicious attack.” – Gary MaGraw
• A program is said to be secure if new states of the objects modified by the program are collectively in an acceptable state even in adversarial environment
20
Software Development Process
Common phases in software development: • Requirements
• Design
• Implementation
• Testing/assurance
• These phases of development apply to the whole project, its individual
components, and its refinements/iterations
• We need to enhance this model to include security in every phase
Three pillars of software security:
• applied risk management,
• software security touchpoints, and • knowledge
21
Applied Risk Management
• A way to gather the requisite data to make a good judgment call, based on knowledge of vulnerabilities, threats, impacts, and probabilities
• The Risk Management Framework can be used:
1. 2. 3. 4. 5.
Understand the business context (identify the assets) Identify the business and technical risks
Synthesize and prioritize the risks, producing a ranked set Define the risk mitigation strategy
Carry out required fixes and validate that they are correct
Part of the Risk Analysis is the creation of a Threat Model
22
Software Security Touchpoints
• Touchpoints: a set of good security practices that must be applied throughout the whole Software Development LifeCycle
• Secure Software Development LifeCycle
23
Software Security Knowledge
• Know your enemy:
• Software security knowledge can be organized into seven knowledge catalogs (principles, guidelines, rules, vulnerabilities, exploits, attack patterns, and historical risks)
• Grouped into three knowledge categories:
• prescriptive knowledge,
• diagnostic knowledge, and
• historical knowledge.
• training begins with a description of the problem and demonstrates its impact and importance
24
Vulnerability
CVE
Common Vulnerabilities and Exposures
26
CVE
27
CVE
CVE Numbering Authorities (CNAs)
CNAs are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities
•Australia: 1 •Austria: 1 •Canada: 3 •China: 7 •France: 1 •Germany: 2 •Israel: 1
•Japan: 3 •Netherlands: 2 •Russia: 2 •South Korea: 1 •Taiwan: 3
•UK: 1 •USA: 55
28
Software Vulnerabilities
•Memory safety violations, such as:
• Buffer overflows and over-reads • Dangling pointers
•Input validation errors, such as:
• Codeinjection
• Cross-site scripting in web applications
• Directory traversal
• E-mailinjection
• Formatstringattacks
• HTTPheaderinjection/responsesplitting
•Privilege-confusion bugs, such as:
• Clickjacking
• Cross-site request forgery in web applications • FTPbounceattack
29
Software Vulnerabilities
•Privilege escalation •Race conditions, such as:
• Symlink races
• Time-of-check-to-time-of-use bugs • SQLinjection
•Side-channel attack • Timingattack
•User interface failures, such as:
• BlamingtheVictimpromptingausertomakeasecurity
decision without giving the user enough information to
answer it
• RaceConditions
• Warning fatigue or user conditioning.
30
Software Vulnerabilities
31
Threat Modelling (Architectural Risk Analysis)
Threat Model
• Create a model of the software/system/ technology
• •A model abstracts away the details so you can look at the whole
• The threat model makes explicit the adversary’s assumed powers
• Consequence: The threat model must match reality, otherwise the risk analysis of the system will be wrong
• The threat model is critically important
• If you are not explicit about what the attacker can do, how can you assess whether your design will repel that attacker?
33
Threat Modelling Basics
• What?
• A repeatable process to find and address all threats to your product
• When?
• The earlier you start, the more time to plan and fix
• Why?
• Requirement of secure software development
• How?
34
STRIDE Approach
• Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege
• To follow STRIDE, you decompose your system into relevant components, analyse each component for susceptibility to threats, and mitigate them
35
Example: Network User
• An (anonymous) user that can connect to a service via the network • Can:
• measure the size and timing of requests and responses • run parallel sessions
• provide malformed inputs, malformed messages
• drop or send extra messages!
• Example attacks: SQL injection, XSS, CSRF, buffer overrun payloads, …
36
Example: Snooping User
• Internet user on the same network as other users of some service
• For example, someone connected to an unencrypted Wi-Fi network at a coffee shop
• Thus, can additionally
• Read/measure others’ messages,
• Intercept, duplicate, and modify messages
• Example attacks: Session hijacking (and other data theft), denial of service
37
Example: Co-located User
• Internet user on the same machine as other users of some service • E.g., malware installed on a user’s laptop
• Thus, can additionally
• Read/write user’s files (e.g., cookies) and memory
• Snoop keypresses and other events Read/write the user’s display (e.g., to spoof)
• Exampleattacks:Passwordtheft(andothercredentials/secrets)
38
Bad Model = Bad Security
• Any assumptions you make in your model are potential holes that the adversary can exploit!
• Mistaken assumptions
• Assumption: Encrypted traffic carries no information
• By analysing the size and distribution of messages, you can infer application state
• Assumption: Timing channels carry little information
• Timing measurements of previous RSA implementations could be used eventually reveal a remote SSL secret key
39
Threat Modelling Process
40
Process Diagramming
• Use DFDs (Data Flow Diagrams)
• Include processes, data stores, data flows • Include trust boundaries
• Diagrams per scenario may be helpful
• Update diagrams as product changes
• Enumerate assumptions, dependencies • Number everything (if manual)
41
Diagram Elements
The DFD elements of a diagram are the SW assets
42
Diagram Elements: Examples
43
Example DFD: An online Petshop
44
Diagrams: Trust Boundaries
• Add trust boundaries that intersect data flows
• Trust boundaries represent the border between trusted and untrusted elements
• Trust is complex. Consider the context under which you can enable trust…
• You might trust your mechanic with your car, your dentist with your teeth, and your banker with your money, but you probably don’t trust your dentist to change your spark plugs.
• Points/surfaces where an attacker can interject
• Machine boundaries, privilege boundaries, integrity boundaries are examples of trust boundaries
• Threads in a native process are often inside a trust boundary, because they share the same privileges, rights, identifiers and access
• Processes talking across a network always have a trust boundary
• May create a secure channel, but they’re still distinct entities
• Encrypting network traffic is an ‘instinctive’ mitigation
• But doesn’t address tampering or spoofing
45
Diagram Layers
• Diagram layers Context Diagram
• Very high-level; entire component / product / system
• Level 1 Diagram
• High level; single feature / scenario
• Level 2 Diagram
• Low level; detailed sub-components of features
• Level 3 Diagram
• More detailed: rare to need more layers, except in huge projects or when you’re drawing more trust boundaries
46
Context Diagram – the Highest Layer
47
Level 1 Diagram
48
Apply STRIDE to Each Element
49
Mitigation as part of Threat Modelling
Mitigations are an area of expertise, such as networking, databases, or cryptography ❑Possible Mitigation strategies:
• Do nothing.
• Remove the feature.
• Turn off the feature.
• Warn the user.
❑Counter the threat with technology. ❑Amateurs make mistakes ❑Mitigation failures will appear to work
❑Until an expert looks at them
❑We hope that expert will work for us
❑When you need to invent mitigations, get expert help 50
Standard Mitigations
51
Standard Mitigations
52
Validating Threat Models
• Validate the whole threat model
• Does diagram match final code?
• Are threats enumerated?
• Minimum: STRIDE per element that touches a trust boundary
• Has Test / QA reviewed the model?
• Tester approach often finds issues with threat model or details
• Is each threat mitigated?
• Are mitigations done right?
• Did you check these before Final Security Review?
• Shipping will be more predictable
53
Tips of Finding a Good Model
•Compare against similar systems!
•What attacks does their design contend with?
•Understand past attacks and attack patterns! •How do they apply to your system?
•Challenge assumptions in your design
•What happens if an assumption is untrue? What would a breach potentially cost you?
•How hard would it be to get rid of an assumption, allowing for a stronger adversary?What would that development cost?
54