IA: Week 1 Trust

1
IA Week 1Trust Threats

• Trust Models
• Threats and Vulnerabilities
• Threat Profiles

2
Trust Models

• Networks, applications and systems must satisfy
  our expectations of trust.
• Identity
• Authentication
• Service agreements
• Privacy

3
Trust Models

• Rely on complete requirements
• Business
• Technical
• Legal
• Regulatory
• Fiduciary

4
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

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

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

7
Establishing Trust

• Trust is a binary relationship based on
  validation of a unique individual identity.
• A trust model does involve particular security
  mechanisms.

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

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

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

11
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.
12
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.
13
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.
14
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

15
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

16
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

17
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.
18
Original Entity Authentication

• Occurs only once
• Results 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 protocol
• The credential must be unique and bound to a
  specific entity

19
Original Entity Authentication Steps

• Entity A requests a trust relationship with
  Entity B
• Entity B requires Entity A to provide proof of
  identity
• In accordance with stated policy
• Entity B validates these proofs of identity
• Entity B returns to Entity A some identity
  credential that Entity B can test to validate
  Entity A in the future

20
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.
21
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.
22
Trust RelationshipsCharacteristics

• Portability
• Standardized credential types and formats of
  credentials
• Interoperability
• Standardized protocols for validating credentials
• Reliability
• Consistent performance
• Assurance
• Continued accuracy of credential-to-entity binding

23
Trust Models

• Direct Trust
• Transitive Trust
• Assumptive Trust

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

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

26
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

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

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

29
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

30
Trust Model Development
Acceptable use policy Business requirements Threat
profile Identify appropriate security mechanisms
31
Security Stance
A basic principle of acceptable use of data and
processing resources is the foundation for
developing a trust model.
32
Acceptable Use Policy
Data is accessible on a need-to-know basis
only. Processing resources are available only to
those explicitly approved.
33
Business Requirements
Sometimes determined by legal and regulatory
mandates. Service Level Agreements set speed,
throughput, availability requirements. Acceptable
risk for the business.
34
Security Mechanisms
Response to identified risks. Support business
requirements. Enforce security stance.
35
Data Flow Analysis
Trust Points Identify all data communication
paths Identify all processors involved Identify
all storage repositories Identify the types of
threats affecting each trust point
36
Data Flow Analysis
Identify risks and results of compromises
37
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.
38
Threat Models

• Application
• Requirements
• Roles
• Architecture
• Scenarios
• Technologies
• Security Mechanisms

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

40
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

41
Application Security Mechanisms

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

42
Trust Boundaries

• Perimeter firewall
• Database server trusts calls from the Web apps
  identity
• Data access components trust that business
  components pass fully validated data

43
Data Flows

• Use cases

44
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

45
Exit Points

• Search page
• Catalog page

46
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

47
Vulnerabilities

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