Copyright Justin C. Klein Keane InfoSec Training Introduction to Information Security Concepts.

Copyright Justin C. Klein Keane

InfoSec Training

Introduction to Information Security Concepts


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?


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)


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.)


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


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


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...


What is Security?

Defined in terms of threats Secure from what?


Security Concepts

The Golden Rule (Au) Authentication

Users are who they claim to be, or at least can present credentials

Authenticity Data has not been altered and remains true to

its original form Audit

The system can track what activity, data and users


Security as Asset Protection

A secure system must protect: Confidentiality

Threat: Information disclosure Integrity (and Reliability)

Threat: Data corruption Access

Threat: Denial of service


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


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


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


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


Even if it's bug free

Bug free software can still have vulnerabilities: Configuration problems:

Default or weak credentials Improper trust model Etc.

Logic flaws Fundamentally insecure design Software functions exactly as designed but the

result is an unintended vulnerability Two bug free systems might have insecure

interaction


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


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


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


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...


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)

Secure Design


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


Application Security Testing

Black box Penetration testing

Gray box Some level of access and documentation

available White box

Full code review, often combined with other testing tools


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


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


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?


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?


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


Non Technical Threats

Risk calculation involves assessing threats Some threats are not strictly system related:

Reputational damage Misinformation Business risks (ex: grant funding)


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


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


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 InfoSec Training Introduction to Information Security Concepts.

Documents

Transcript of Copyright Justin C. Klein Keane InfoSec Training Introduction to Information Security Concepts.