IA: Week 1 Trust & Threats Trust Models Threats and Vulnerabilities Threat Profiles

IA: Week 1Trust & Threats

Trust Models Threats and Vulnerabilities Threat Profiles

Trust Models

Networks, applications and systems must satisfy our expectations of trust.

1. Identity2. Authentication3. Service agreements4. Privacy

Trust Models

Rely on complete requirements:

1. Business2. Technical3. Legal4. Regulatory5. Fiduciary

Trust

“Generally an entity can be said to 'trust' a second entity when the first entity makes an assumption that the second entity will behave exactly as the first entity expects”

ITU-T X.509, § 3.3.54

Trust Principles

Trust is a quality of a security architecture.Trust is a balance of liability and due diligence.Trust is confidence in predictable behavior.Trust is binding unique attributes to a unique

identity.Trust establishes a trust relationship through a

validation process.

Establishing Trust

Binding a unique set of attributes to a unique identity, i.e. Authentication.

You must have a satisfactory level of confidence in the attributes (credentials) provided by someone to establish a trust relationship.

Establishing Trust

Trust is a binary relationship based on validation of a unique individual identity.

A trust model does involve particular security mechanisms.

Trust Modeling

The process performed to define complimentary threat profile and trust model based on a use-case-driven data flow analysis.

Provides a framework for delivering security mechanisms sufficient to establish the trust required of the system.

Trust Modeling

Identifies specific mechanisms necessary to respond to specific threat models.

Includes validation of an entity's identity.

Includes necessary characteristics for an event to occur.

Threats versus Vulnerabilities

Vulnerability is a characteristic of a system or organization.

A threat originates outside the system or organization and targets the system or organization.

If a threat matches a vulnerability then the system is at risk.

Threat Profiles

The set of threats and vulnerabilities identified through a use-case-driven data flow analysis.

Identifies likely attackers and what they want.

The purpose of a trust model is to respond to a particular threat model.

Gradients of Trust

There are different levels of trust.

Each system will require various levels of trust.

A library requires proof of residence to loan a book.A financial institution requires a passport, drivers

license or birth certificate to open a checking account.

Gradients of Trust

Trust requirements must be matched to the specific kinds of threats or vulnerabilities and the risk that the threat will occur.

There must be a starting point in establishing credentials.

Trust requires a process of credential establishment and consistent validation.

Threats & Risks

Threat profiles identify threats that put your environment at risk.

Threat types: Unauthorized probing of system or data Unauthorized access Introduction of malicious code Unauthorized modification, deletion or disclosure of data Denial of service

Threats & Risks

Any risk analysis must rely on a threat profile.

Use-case-driven data flow analysis of the system: Identifies threats and vulnerabilities Identifies data and resources that are at risk Locates where in the system they are vulnerable

Example

Original Entity Authentication

Use-case-driven data flow analysis of the system: Identifies threats and vulnerabilities Identifies data and resources that are at risk Locates where in the system they are vulnerable

Example

Original Entity Authentication

Is the starting point for all trust models.Relying entities must be convinced of the identities

of all other entities.Level of satisfaction must be specified in a

published security policy.

Original Entity Authentication

Occurs only onceResults in a credential or token

Library card Credit card

The credential can be evaluated, tested and referenced by a relying entity

Evaluation according to a standardized protocolThe credential must be unique and bound to a

specific entity

Original Entity Authentication Steps

1. Entity A requests a trust relationship with Entity B2. Entity B requires Entity A to provide proof of identity

1. In accordance with stated policy3. Entity B validates these proofs of identity4. Entity B returns to Entity A some identity credential that

Entity B can test to validate Entity A in the future

Bootstrap

Entity A uses the token or credential provided by Entity B to re-establish trust.

AGAIN trust depends on the ability to bind unique attributes (credentials) to a unique entity.

Spontaneous Trust

Spontaneous trust does not exist in any meaningful way.

Those systems the purport spontaneous trust have no basis to trust the entity.

In SSL the browser can validate the credentials of the server. However the server cannot validate the browser.

Trust RelationshipsCharacteristics

PortabilityStandardized credential types and formats of credentials

InteroperabilityStandardized protocols for validating credentials

ReliabilityConsistent performance

AssuranceContinued accuracy of credential-to-entity binding

Trust Models

Direct Trust Transitive Trust Assumptive Trust

Direct Trust Model

A validates B's credentials with no reliance on another entity.

No delegation of trust All entities gain trust through a common

entity that is responsible for the original entity authentication.

Direct Trust Model

Public Key Infrastructure (PKI) is often used in direct trust models.

The root certificate authority (CA) initiates all trust relationships.

The CA generates all credentials. Original entity authentication is not

delegated in this model.

Direct Trust Model

Advantages: Validation of credentials is performed by one's self High level of confidence Reduces liability – no dependence of other entities

Disadvantages: Labor intensive Expensive

Transitive Trust Models

Trust is transmitted through another party. A validates and trusts B. B validates and trusts C. A trusts but does not have to validate C.

Transitive Trust is common in peer-to-peer systems.

Transitive Trust Models

In transitive trust systems A has to be confident that B validated C.

Often banks use a transitive model after the merger of two banks each with their own direct trust systems.

Assumptive Trust Models

Assumptive Trust is a form of spontaneous trust.

PGP used to use an assumptive trust model.

Web of Trust and their key ring

Trust Model Development

Acceptable use policyBusiness requirementsThreat profileIdentify appropriate security mechanisms

Security Stance

A basic principle of acceptable use of data and processing resources is the foundation for developing a trust model.

Acceptable Use Policy

Data is accessible on a need-to-know basis only.

Processing resources are available only to those explicitly approved.

Business Requirements

Sometimes determined by legal and regulatory mandates.

Service Level Agreements set speed, throughput, availability requirements.

Acceptable risk for the business.

Security Mechanisms

Response to identified risks.Support business requirements.Enforce security stance.

Data Flow Analysis

Trust Points:Identify all data communication pathsIdentify all processors involvedIdentify all storage repositories

Identify the types of threats affecting each trust point

Data Flow Analysis

Identify risks and results of compromises

Example for a Bank

Direct trust model.All users must be identified and authenticated.Trust and authentication can never be implied nor assumed.No transitive trust.Trusted users can access system on a predefined need-to-know basis.All data shall be encrypted during transfer over the Internet.

Threat Models

Application

Requirements

Roles

Architecture

Scenarios Technologies Security Mechanisms

Example – Web Application

Requirements Store, e-commerce

Roles Internet shoppers

Catalog admins

Architecture Server Database

Scenarios User browsing catalog\ Adds item to shopping cart Etc.

Technologies

Web Server – MS IIS Presentation – ASP.NET (C#) Business logic – C# Data access logic – ADO.NET, T-SQL Stored

Procedures Database Server – MS SQL Server 2008

Application Security Mechanisms

User authentication Application authentication for access to database Access to business logic based on roles No remote administration access is provided

Trust Boundaries

Perimeter firewall Database server trusts calls from the Web app’s

identity Data access components trust that business

components pass fully validated data

Data Flows

Use cases

Entry Points

Port 80 for Web requests Port 443 for SSL All other ports trap by the firewall Logon page is validated client side and server side Catalog administration page

Exit Points

Search page Catalog page

Threats

Brute force attacks using a store dictionary Network sniffing to get client credentials Capture authentication cookie to spoof identity SQL Injection Cross site scritpting Cookie replay attack Attacker assumes control of server Attackers gets crypto keys for CC details

Vulnerabilities

User password storage SQL server unpatched IIS unpatched Lack of strong password policy Weak input validation