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

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 The system can track what activity, data and users
Copyright Justin C. Klein Keane

Authenticity

Audit

Security as Asset Protection

A secure system must protect:

Confidentiality

Threat: Information disclosure Threat: Data corruption

Integrity (and Reliability)

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:

Default or weak credentials Improper trust model Etc. Fundamentally insecure design Software functions exactly as designed but the result is an unintended vulnerability

Logic flaws

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

Penetration testing Some level of access and documentation available Full code review, often combined with other testing tools
Copyright Justin C. Klein Keane

Gray box

White box

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