InfoSec Training
Introduction to Information
Security Concepts
Copyright Justin C. Klein Keane
Vocabulary: Security Policy




Refers to the way a system is supposed to
function
Can be explicit or implicit
Outlines assumptions of protections and
violations
If you users don't have passwords is account
hijack a violation of policy?
Copyright Justin C. Klein Keane
Vocabulary: Incident




Security incident is a violation (or series of
violations) of a systems security policy
Scope can vary from narrow to broad
Incidents are events caused by (malicious)
behavior
Can be automated (a virus) or manual (abuse of
access)
Copyright Justin C. Klein Keane
Vocabulary: Threat



Potential cause of a security incident
Can be purposeful (a specific tool used to break
into a site or a malicious insider)
Accidental (floods, fire, lost backup tape, etc.)
Copyright Justin C. Klein Keane
Vocabulary: Vulnerability

Flaw in a system that could allow a threat to
violate the security policy

Can be a result of oversight or architecture

Logic flaws can present vulnerabilities

Vulnerabilities are static aspects of systems
Copyright Justin C. Klein Keane
Vocabulary: Exploit



Exploit is when a threat capitalizes on a
vulnerability
Exploits can be manual or automated
Exploits demonstrate that there is a problem
with a system
Copyright Justin C. Klein Keane
Vocabulary: Malware

Software that does bad stuff

Malware include virus and worm code

Includes software designed to modify legitimate
systems to:

Allow unauthorized remote access

Hide evidence of intrusion

Exfiltrate data from a target

Surreptitiously monitor user activity

And more...
Copyright Justin C. Klein Keane
What is Security?

Defined in terms of threats

Secure from what?
Copyright Justin C. Klein Keane
Security Concepts

The Golden Rule (Au)

Authentication


Authenticity


Users are who they claim to be, or at least can
present credentials
Data has not been altered and remains true to
its original form
Audit

The system can track what activity, data and
users
Copyright Justin C. Klein Keane
Security as Asset Protection

A secure system must protect:

Confidentiality


Integrity (and Reliability)


Threat: Information disclosure
Threat: Data corruption
Access

Threat: Denial of service
Copyright Justin C. Klein Keane
Security Lifecycle

Security is a process not a product

Complexity is the enemy of security

Security is an evolutionary landscape

“Secure” is a point in time evaluation

“Secure” is defined by known threats
Copyright Justin C. Klein Keane
0 day




0 day is a vulnerability for which there is no
patch available
If 0 day cannot be predicted, how can we
defend against it?

0 day can often be mitigated

How can we detect 0 day?
Defense in depth is often the only defense
against 0 day
When evaluating security you should assume 0
day
Copyright Justin C. Klein Keane
A Word on Software Bugs




Software engineering is a robust, and mature,
field of academic study
All software projects of sufficient size and
complexity contain bugs, regardless of
development process
A certain number of bugs will be security related
Conclusion: all software contain security related
bugs
Copyright Justin C. Klein Keane
Classifying Software Bugs

Not all bugs are the same

Bugs may present wildly varying threats


Bugs may have different risks associated with
them
All bugs are significant, however
Copyright Justin C. Klein Keane
Even if it's bug free

Bug free software can still have vulnerabilities:

Configuration problems:




Logic flaws



Default or weak credentials
Improper trust model
Etc.
Fundamentally insecure design
Software functions exactly as designed but the
result is an unintended vulnerability
Two bug free systems might have insecure
interaction
Copyright Justin C. Klein Keane
Vulnerability Synergy



Linking one vulnerability to another
Chains of low risk, or low significant
vulnerabilities can lead to a serious vulnerability
Even if highest risk bugs are all patched, a
combination of low risk bugs could lead to
compromise
Copyright Justin C. Klein Keane
Sisyphean Task


A sufficiently resourced and motivated attacker
will always compromise security
Defenders must be right 100% of the time,
attackers need only succeed once

You can't possibly defend against everything

Attacker motivation is unknowable
Copyright Justin C. Klein Keane
Protect, Detect, React





The security lifecycle, also known as the
security hamster wheel of pain
EVERY step is critical
Detection is dependent on observation and
reporting
Logs are some of the best places to do
detection
More on each step later
Copyright Justin C. Klein Keane
How can we get ahead?




The protect/detect/react cycle often requires an
incident to move from detect/react to better
protection
It is important to keep the cycle moving
independently of a security incident
Collecting metrics is key to making informed
decisions
Start with security first...
Copyright Justin C. Klein Keane
Secure Design

Threat modeling

Maximize ROI with high impact, low cost,
mitigations

Good authentication, authorization and audit

Fault tolerance or Rugged Design


Applications should protect against
unexpected actions
This includes good exception handling

Test driven design, with tests that should fail

Secure Application Development Lifecycle (SDLC)
Copyright Justin C. Klein Keane
Penetration Testing

Actively attacking your own systems

Can reveal flaws in protection, including gaps


Can proactively identify vulnerabilities (prevent
0 day)
Helps more accurately frame risk assessment
Copyright Justin C. Klein Keane
Application Security Testing

Black box


Gray box


Penetration testing
Some level of access and documentation
available
White box

Full code review, often combined with other
testing tools
Copyright Justin C. Klein Keane
Using Automation

Automation is critical for a timely review

Automation can lead to false positives

Automated tools without skilled human
operators can be useless

Deluge of false positives

Poor risk assignment
Copyright Justin C. Klein Keane
Gold Standard for Security
Reporting

Security reporting after a review should include:





List of vulnerabilities, ranked/grouped by
severity
Demonstration of exploit
List of suggested mitigation and work around
strategies
List of patches and/or fixes for the issue
A good security test should be repeatable
Copyright Justin C. Klein Keane
Resource Allocation



In the real world resources are limited
Given the scope of security it is impossible to
cover all fronts
How does one make smart resource allocation
decisions?
Copyright Justin C. Klein Keane
Risk Calculations

Risk can be used to draw comparisons

Risk generally calculated:




Risk = Likelihood x Severity
Good risk ratings allow you to compare apples
to apples
Can focus attention and resources to greatest
need
How can we baseline these without METRICS?
Copyright Justin C. Klein Keane
Flaw in Risk Calculation




Likelihood can never actually be measured
because it is within the attackers control
How can you quantify what you don't know?
Severity may hinge on unknown consequences
or attacker motivation
Some resources may escape risk calculation
Copyright Justin C. Klein Keane
Non Technical Threats

Risk calculation involves assessing threats

Some threats are not strictly system related:

Reputational damage

Misinformation

Business risks (ex: grant funding)
Copyright Justin C. Klein Keane
Typical Poor Risk Calculation

Home user doesn't protect their machine
because they have no data of value

Risk = medium likelihood x low impact

Home user may not understand full impact:

Attacker can use webcam

Attacker can use mic to record conversations

Attacker can use connection to compromise
wireless router to allow anonymous wireless
Copyright Justin C. Klein Keane
Linchpin in Most Flaws

Many risk calculations fail because the
assessor measures risk based on:



Perceived attacker motivation
Without understanding what an attacker is after
there is no effective way to protect resources
“Industry best practice” may provide a guide
Copyright Justin C. Klein Keane
Moving Forward


Goal is an adaptive, metrics based information
security program
Resources should be fluid, and allocated based
on actual need

Reactive capabilities should be maximized

Reduction of misguided protective measures

Constant metrics gathering and reevaluation

Learn, grow, share
Copyright Justin C. Klein Keane