Risk	Pretty picture
Service and data unavailability Your service / data could be made unavailable.
Reputation A hacker could do something to your website, and nobody would trust your service anymore.
Data leaks Client lists, industrial secrets, business plans, e-mails etc.
Bank fraud Stealing credit cards, phishing for bank details, etc.
Data loss Losing data such as projects, client data, etc. This can happen due to HDD / SSD faults.

But who cares?
Who cares if I lose my data, or if my website goes down for a few seconds, or if a hacker steals all my personal information including bank details?
What are the consequences?

Well, uh... obviously, you’ll lose money.
The company will lose money with less traffic, and will have to spend money to replace lost data.
This reduces stock market value.

In addition, just because you don’t care that your data is compromised, that doesn’t mean your clients don’t, either.
In addition, if you work in a public sector, providing services such as water and electricity, there can be big repercussions.
If you allow malicious activity, they could do things like shut down the power grid.
If that happens, you wouldn’t be able to read the notes anymore!

So, we get it. Risks bad.
What do we do to defend against this?
Some of these happen via fault.

We can replicate data and backup
Use disaster recovery software

However, some of these happen via attackers.

Who is the Attacker?

Who would want to attack you? After all, you’re such a nice person.

Attacker	Motive	Pretty picture
Competitor	Take down a rival business
Hacker	Get a kick out of hacking you
Activity (hacktivist)	Vigilantism
Nation state	War

What exactly do we want to protect?

Information (our data)
Network (we don’t want them reading our packets 👀)
Physical (please don’t blow up our computers)

How exactly do we protect these?

We can deny unauthorised access to:

Facilities
Equipment
Data centres
Resources

... and use multiple layers of systems:

Surveillance
Security guards
Protective barriers
Locks
Access control protocol

What? Hire security guards for our information and network?
That doesn’t quite work... physical security isn’t enough.
We need a bit more.

Vulnerabilities

A vulnerability is a bug or weakness in a system that, when exploited, could result in unwanted circumstances.
An exploit is a piece of code written to abuse that vulnerability.

There are four kinds of vulnerabilities:

Vulnerabilities in physical systems
Vulnerabilities in infrastructures as networking systems
Vulnerabilities in Operating Systems
Vulnerabilities in Software

The red vulnerabilities are bugs in software.

One such vulnerability could come from a buffer overflow weakness.
This is where we can accidentally overflow a buffer meant to manipulate data and overwrite arbitrary memory addresses.
This can be used to overwrite the original program’s code and run our own code, called a payload.

Now, we’ll go into detail on what a “risk” is.

Vulnerability

Weakness in the system
Internal factor

Threat

Condition that can cause harm
External factor

Risk

Likelihood of the realisation of a threat

Vulnerability without a threat = no risk

Threat without a vulnerability = no risk

So, if we have a vulnerability in our system, but nobody wants to abuse it, then we don’t need to patch it, right?
WRONG
There will always be threats.
There will always be vulnerabilities.
So as long as we have assets, there will always be risks.

What happens when a vulnerability exists?
It has a lifetime before it is patched:

Software released from a vendor (with the unknown vulnerability)
Vulnerability discovered by an attacker and exploit is released
Vulnerability discovered by the vendor
Public dissemination of the vulnerability
Antiviruses start revealing the exploit
Patch released by the vendor
Exploit mitigation deployed on all affected systems

Here is a cool timeline:

Zero-day attacks are exploitations of the vulnerability before it has been disclosed to the public. Nobody notices these.
Follow-on attacks are exploitations of the vulnerability after it has been disclosed to the public, and before it has been patched.
The window of exposure is the range of time in which the vulnerability can be exploited.

Here is a graph showing how much a security expert could earn by finding exploits in the following systems:

Alright... that’s really hard to see, but here’s the ones the slides mention:

Wordpress £5,000
Flash £50,000
Android £100,000
Apple iOS £500,000

CIA Triad

Each vulnerability can harm one or more CIA properties.
Those are:

Confidentiality (exposure of customer / company data)
Integrity (data deletion / modification)
Availability (IT systems becoming inaccessible / taken down)

CVE / CVSS / CWE

How do we catalogue these vulnerabilities?
We could build a unique tuple for each vulnerability, and then store them into an archive.
The tuple structure can look like this:

(id, type, attack vector, threat, exploit)

That’s alright, but it’s a bit crap.
Why?
We could accidentally store the same vulnerability multiple times.
In fact, the Tower of Babel vulnerability has been classified 12 times!

Let’s look at the Common Vulnerabilities and Exposures (CVE) standard.
All the vulnerabilities in CVE:

Violate at least one CIA property.
Are identified by a unique string: CVE-year-number
Are described with a page containing:

Description
URL to a detailed page (references)
Date of creation

Here’s a description page for Heartbleed (CVE-2014-0160).

Now, let’s look at the Common Vulnerability Scoring System (CVSS).
It’s a free and open industry standard for scoring vulnerabilities on a scale of 1 to 10.

Rating	CVSS Score
None	0.0
Low	0.1 - 3.9
Medium	4.0 - 6.9
High	7.0 - 8.9
Critical	9.0 - 10.0

Given a vulnerability, how do we calculate its CVSS score?
There are a number of factors that go into that.

Base Metrics

Is it easy to exploit?
What is the impact?

Temporal Metrics

Is a patch available?
Is an exploit available?

Environmental Metrics

What are the consequences on safety?
How many systems are vulnerable?

The CVSS base score of Heartbleed is 6.4.

Lastly, let’s move on to the Common Weakness Enumeration (CWE).
We’ve just been cataloguing vulnerabilities.
CWE is used for cataloguing weaknesses and related scores.
Here is the page detailing Stack-based Buffer Overflow.

What’s the difference between a weakness and a vulnerability?
A weakness can lead to a vulnerability.
A weakness describes something that could go wrong with software. Once you write a program that has that weakness, and the software can be exploited by some attacker because of that weakness, you’ve now created a vulnerability.
You can think of a vulnerability as an “instantiation” of a weakness.
If you still don’t get it, Tom K. explains this pretty well.

Low-Level Programming

Have you ever learned C?
If not, check it out here.

In C, we have pointers.
Pointers are variables that ‘point’ to a location in memory.

Arrays in C are really just pointers.

arr[5] ← depends on the size of the type of array
*(arr + (sizeof arr type) * 5)

Memory Errors

C has two areas of memory: the stack and the heap.

The stack is where the function calls, arguments, and local variables are stored.
The heap is where all dynamic memory is stored (malloc).

Consider the following program:

#include <stdio.h>

int main(int argc, char** argv)
{
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}

What if we were to pipe in an argument that is more than 500 characters?
C wouldn’t crash; it has no validation for such things.
Instead, it would overwrite bits of the stack that weren’t meant to be overwritten...
... such as the return pointer.

If we overwrite that, we can make the main function return to any malicious code we want.

Assembly

You can transfer data from:

Memory to registers
Registers to registers
Registers to memory

But not memory to memory, because computers don’t have the hardware to do that.

Relative addressing, index is scaled by square number 1 2 4 8 16
We do this because it’s fast; bitwise shift, hardware operation

Malware

Malware bad
Malware: Malicious computer software that interferes with normal computer functions or sends personal data about the user to unauthorized parties over the internet [source].

About Malware

Types:

Target:

Mass (lots of people)
Specific (a few people)

Forms:

Trojan horse (pretends to be good but isn’t)
Virus (spreading by host file)
Worm (spreading by vulnerability)

Characteristics:

Information stealing (keyloggers, sniffers)
Remote access (backdoor, accessing your computer via remote shell)
Ransomware (pay us bitcoin and we will decrypt your files)
Rootkit (hooking into OS system calls)
Scareware (your computer has child porn (it doesn’t), pay us or you’ll go to jail!!!!)
Downloader (download other malware and execute it)
Launcher (launch other malware)

Common Techniques

Persistence

How can they make sure to load each time?

Logon
Explorer hooks
Scheduled tasks
Services
Drivers
Boot execute
AppInit (DLL loaded into every application that starts)

Stealth

How can they hide themselves?

Camouflage as real files
Pretend to be Microsoft
Inject into other processes
Replace legitimate files
Hide from OS (using rootkit)
Replace things that don’t get used often

Packing and Obfuscation

Pack malware inside a wrapper
When you try to inspect application, you only see wrapper

Anti-Analysis

Some malware can detect if they’re in VMs by looking at:

Drivers
Virtualized devices
Virtualisation support software
Analysis tools
Networking

Basic Static Analysis

Portable Executable (PE): file format used by Windows executables

Header: stores info about library dependencies
Sections:

.text - executable code
.rdata - read-only data globally accessible in program
.data - global data accessed throughout program
.rsrc - resources needed by program

Advanced Static Analysis with IDA

How to analyse PE?

Unpack using PEStudio
Dependency Walker
‘strings’ to find all strings in program
Resource Hacker

Or you can use IDA, which lets you read assembly.

Introduction to Risk Analysis

three pillars of software sec:

risk management framework
touchpoints
knowledge

10 steps to cyber security:

network security
user education and awareness
malware prevention
removable media controls
secure configuration
managing user privileges
incident management
monitoring
home and mobile networking

Risk Management: perform discrete risk analysis exercises to identify, track, and mitigate risks throughout SDLC
Risk Analysis: identifying and ranking risks at some stage of the SDLC
Risk Assessment: identifying and evaluating risks

As said before,

asset + vulnerability + threat = risk

If security risk, then introduce security mechanisms.
Then we’ll have a reduced risk level.

Threat event: the event in which the threat exploits the vulnerability and affects the asset
Likelihood: how likely the threat event is to happen
Impact: how bad the threat event would be
Treatment: action that mitigates the risk

Risk analysis process:

Step 1: Context Identification

Characterize target of analysis
Identify and value assets
Define likelihood scale
Define consequence scale
Make risk evaluation matrix
Specify the risk evaluation criteria

Step 2: Risk Identification

Identify threats to the assets through structured brainstorming
Identify vulnerabilities of assets (questionnaires and checklists)

Step 3: Risk Estimation

Determine the level of identified risks
For each threat event

Assign a likelihood value
Assign an impact value

Step 4: Risk Evaluation

We can’t eliminate all risks
Determine which risks need treatment
Risk level is prioritized based on analysis of the likelihood and impact of a threat event

Quantitative: loss of £1M
Qualitative: high, medium, low

Map the risks into the risk evaluation matrix

Step 5: Risk Treatment

Four options:

Accept
Treat
Avoid / Terminate
Transfer

Identify treatments for unaccepted risks
Evaluate and prioritize different treatment

Security analysis methods:

International standards:

ISO 27001 (process) + ISO 27005 (treatments)
ISO 31000
NIST SP 800-30 (process) + NIST SP 800-53 (treatments)

National standards:

IT-Grundschutz (Germany)
Magerit (Spain)

Standards-based:

OCTAVE
CORAS

Eliciting Security Requirements with Misuse Cases

Security Requirements

Security requirements: what system should not be able to do
security requirements elicitation:

identify critical assets
define security goals for assets

confidentiality: prevent unauthorized access
integrity: prevent unauthorized modification
availability: readiness of a correct service
accountability: ability to identify subjects for decisions and actions

Identify threads to assess → misuse cases
identify and analyze the risks
define countermeasures aka security requirements → security cases

functional vs security requirements:

functional requirement

system must provide a function to retrieve personnel info

asset

personnel info

security goal

protect personnel info from confidentiality harm

elicitation methods and techniques

techniques

misuse / abuse cases
attack trees

processes

SQUARE
???

Misuse Cases

use case: what the program should allow
misuse case: what the program should not allow

how to build misuse case:

start from a normal use case model
identify actors (attackers / misusers)

what skills the attacker has?
what resources the attacker has?
what does the attacker want to achieve?

identify misuse cases

what can a bad guy do?

identify threaten relationships between use cases and misuse cases
identify security use cases aka security requirements that mitigate these

misuse case template:

Name: Obtain password
Summary: hacker obtains and misuses user password
Basic path: hacks into network and uses packet sniffer to get usernames and password hashes
Alternative paths: hacker has operator privileges
Mitigation paths: ???
Extension points: ???
Triggers: (what triggers this use-case) always true
Preconditions: (conditions that must be true for the attack to be possible)

System has special user ‘operator’ with extended authorities
The system allows operator to log in over network

Assumptions:

Operator uses network to log on to system as operator (for all paths)
worst case threat:

hacker has operator authorities on the web app for an unlimited time, i.e. they are never caught

Mitigation guarantee (postcondition): (what happens when you mitigate this)

hacker never gets operator authorities on web app

Related business rules:

The role of web app operator shall give full privileges on the web app, the web app computer and the associated local network host computers
Only the role of e-shop system operator shall give the privileges mentioned in br1

Potential misuser profile: (who will actually do this)

Highly skilled, potentially host admin with criminal intent

Stakeholders and threats: (who is affected by this attack)

company: reduced turnover if misuser uses operator access to sabotage system
customer: loss of privacy if misuser uses operator access to find out shopping habits

Scope: (how severe is this)

entire business and business environment

Abstraction level: (at what level does this attack occur)

misuser goal

Attack Trees

attack trees
used for threat modelling, security requirements elicitation
focuses on attackers and different ways they attack systems
root: attack goal
two kinds of attack decomposition:

and - all subgoals must be fulfilled
or - at least one subgoal must be fulfilled

building attack trees:

identify top level attacks against system
brainstorm different ways attack can be achieved
specify children attacks recursively, until attack is so obvious it can’t be decomposed anymore