IA: Week 1 Trust & Threats

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. AssumptiveTrust 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 app’s 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