Security Overview Security Objectives Confidentiality prevent detect deter improper

Security Overview

Security Objectives Confidentiality: prevent/detect/deter improper disclosure of information Integrity: prevent/detect/deter improper modification of information Availability: prevent/detect/deter improper denial of access to services Farkas CSCE 824 2

Distributed applications Authenticity Non-repudiation Farkas CSCE 824 3

Sample Questions What is the trade off between the security objectives? Give an example of the security objectives in the domain of college education. Consider the trend about attack sophistication and intruder’s knowledge. Recommend an approach to enhance the security of future computing systems. Farkas CSCE 824 4

Achieving Security Policy What Mechanism How to protect? Assurance How Farkas good is the protection? CSCE 824 5

Security Policy Organizational Policy Computerized Information System Policy Farkas CSCE 824 6

Sample Questions Why do we need to fit the security policy into the organizational policy? Why is it recommended to separate policy from mechanism? What does “assurance” mean in the context of security? Give an example security policy enforced on your personal computer/CSE computing system/CEC computing system and recommend security mechanism to implement the policy. Farkas CSCE 824 7

Security Mechanism Prevention Detection Tolerance/Recovery Farkas CSCE 824 8

Security Tradeoffs Security Functionality COST Ease of Use Farkas CSCE 824 9

Threats, Attacks, Vulnerability, Risk § Types of threats § Types of attacks § Relation to security objectives § M(ethod), O(pportunity), and M(otive) of attacks § Methods of defense – Security planning § Risk Management Farkas CSCE 824 10

Risk Management Framework (Business Context) Understand Business Context Identify Business and Technical Risks Carry Out Fixes and Validate Synthesize and Rank Risks Define Risk Mitigation Strategy Measurement and Reporting Farkas CSCE 824 11

Sample Questions Give an example of vulnerability, threat, risk, and attack in the domain of … What does it mean “weakest link” of defense? Recommend a way to increase computing system’s security by incorporating security trade offs into the security planning. Why do we need to understand the business context to have effective security? Farkas CSCE 824 12

Cryptography

Insecure communications Snooper Confidential Insecure channel Sender Recipient

Cryptographic Protocols § Messages should be transmitted to destination § Only the recipient should see it § Only the recipient should get it § Proof of the sender’s identity § Message shouldn’t be corrupted in transit § Message should be sent/received once only

Conventional (Secret Key) Cryptosystem Plaintext Ciphertext Encryption Plaintext Decryption Sender Recipient C=E(K, M) M=D(K, C) K K needs secure channel

Public Key Cryptosystem Recipient’s public Key (Kpub) Plaintext Recipient’s private Key (Kpriv) Ciphertext Encryption Plaintext Decryption Sender Recipient C=E(Kpub, M) M=D(Kpriv, C) Kpub needs reliable channel

Cryptography Cryptanalyst’s goal: Break message Break key Break algorithm Taxonomy of attacks Breakable vs. unbreakable cryptographic system Properties of good cryptosystem.

Cryptosystem Vulnerabilities • • Passive Attacker (Eavesdropper) Active Attacker • Capabilities

Basic Encryption Techniques Substitution Permutation Combinations and iterations of these Techniques and attacks ADVANTAGES/DISADVANTAGES!

Inherent Weaknesses of Symmetric Cryptography § Key distribution must be done secretly (difficult when § § parties are geographically distant, or don't know each other) Need a key for each pair of users § n users need n*(n-1)/2 keys If the secret key (and cryptosystem) is compromised, the adversary will be able to decrypt all traffic and produce fake messages

Product Ciphers One encryption applied to the result of the other En(En-1(…(E 1(M)))), e. g. , Double transposition Substitution followed by permutation, followed by substitution, followed by permutation… Broken for Chosen Farkas plaintext CSCE 824 22

Trustworthy Encryption Systems Based on sound mathematics Has been analyzed by experts Has stood the test of time Examples: Data Encryption Standard (DES), Advanced Encryption Standard (AES), River-Shamir-Adelman (RSA)

Public Key Encryption Farkas CSCE 824 24

Public-Key Encryption Two keys – one is private one is public Solves the key distribution problem (but need reliable channel) Provides electronic signatures Slower than secret-key encryption Farkas CSCE 522 - Farkas 824 CSCE 25

Public-Key Encryption Needed for security: One of the keys must be kept secret Impossible (at least impractical) to decipher message if no other information is available Knowledge of algorithm, one of the keys, and samples of ciphertext must be insufficient to determine the other key Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 26

RSA – Notation C = E(KE-B, M) M = D(KD-B, C) KE-B: public key of B KD-B: private key of B E: encryption alg. D: decryption alg. M: plaintext C: ciphertext Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 27

RSA Both sender and receiver know n Sender knows e Only receiver knows d Modulus: Remainder after division, i. e. , if a mod n=b then a=c*n+b Need: Find values e, d, n such that Med mod n = M mod n Easy to calculate Me, Cd for all M < n Infeasible to determine d give e Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 28

Signature and Encryption A Plaintext Signed Plaintext D E B’s public key A’s private key Lecture 6 Farkas B Encrypted Signed Plaintext CSCE 522 - Farkas 824 CSCE Signed Plaintext D E Plaintext A’s public key B’s private key 29

Non-repudiation Requires notarized signature, involving a third party Large system: hierarchies of notarization Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 30

Cryptographic Hash Functions Farkas CSCE 824 31

Hash Functions Hash function h maps an input x of arbitrary length to a fixed length output h(x) (compression) Accidental or intentional change to the data will change the hash value Given h and x, h(x) is easy to compute (ease of computation) Lecture 8 -9 Farkas CSCE 522 - Farkas CSCE 824 32

Good Hash Function 1. 2. 3. 4. It is easy to compute the hash value for any given message It is infeasible to find a message that has a given hash It is infeasible to modify a message without changing its hash It is infeasible to find two different messages with the same hash Lecture 8 -9 Farkas CSCE 522 - Farkas CSCE 824 33

Cryptographic Protocols Farkas CSCE 824 34

Protocols Good protocol characteristics: Established in advance Mutually subscribed Unambiguous Complete Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 35

Symmetric-Key Distribution: Symmetric-Key Techniques Symmetric-Key without Server Symmetric-Key with Server Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 36

Symmetric-Key Distribution: Public-Key Techniques Simple secret key distribution Secret key distribution with confidentiality and authentication Diffie-Hellman Key Exchange Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 37

Simple secret key distribution Public key of S 1. KE-S ||ID-S Sender Recipient 2. E KE-S(Ksession) Vulnerable to active attack! HOW? Lecture 6 Farkas Secret Session key CSCE 522 - Farkas 824 CSCE 38

With confidentiality and authentication Assume: KE-R and KE-S are known in advance Nonce 1. E KE-R[N 1||ID-A] Sender 2. E KE-S[N 1||N 2] Recipient 3. E KE-R[N 2] 4. E KE-R E KD-S(Ksession) Question: Why do we need reliable distribution of public keys? Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 39

Intruder in the Middle Attack John Intruder Hi Rose, I’m John. Hi John, I’m Rose. Intruder and John Uses Diffie-Hellman To agree on key K. Intruder and Rose Uses Diffie-Hellman To agree on key K’. Question: the attacker may want to have K and K’ be the same, Why? Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 40

Asymmetric-Key Exchange Without server Broadcasting Publicly available directory With server Public key distribution center Certificates Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 41

Public-key certificates Certificate Authority KE-S C-S=EKD-CAuth[Time 1, ID-S, KE-S] KE-R CR=EKD-CAuth[Time 2, ID-R, KE-R] 1. C-S Sender Lecture 6 Farkas 2. C-R CSCE 522 - Farkas 824 CSCE Recipient 42

Certificates Guarantees the validity of the information Establishing trust Public key and user identity are bound together, then signed by someone trusted Need: digital signature Lecture 6 Farkas CSCE 522 - Farkas 824 CSCE 43

Digital Signature Need the same effect as a real signature Un-forgeable Authentic Non-alterable Not Lecture 6 Farkas reusable CSCE 522 - Farkas 824 CSCE 44

Digital signature Direct digital signature: public-key cryptography based Arbitrated digital signature: Conventional encryption: Arbiter sees message Arbiter does not see message Public-key Lecture 6 Farkas based Arbiter does not see message CSCE 522 - Farkas 824 CSCE 45

Identification and Authentication Farkas CSCE 824 46

Authentication Allows an entity (a user or a system) to prove its identity to another entity Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

Authentication Information Must be securely maintained by the system.

Authentication Requirements Network must ensure Data exchange is established with addressed peer entity not with an entity that masquerades or replays previous messages Network must ensure data source is the one claimed Authentication generally follows identification Establish validity of claimed identity Provide protection against fraudulent transactions

User Authentication What the user knows Password, personal information What the user possesses Physical key, ticket, passport, token, smart card What the user is (biometrics) Fingerprints, voiceprint, signature dynamics

Passwords Commonly used method For each user, system stores (user name, F(password)), where F is some transformation (e. g. , one-way hash) in a password file F(password) is easy to compute From F(password), password is difficult to compute Password is not stored in the system When user enters the password, system computes F(password); match provides proof of identity

Vulnerabilities of Passwords Inherent vulnerabilities Easy to guess or snoop No control on sharing Practical vulnerabilities Visible if unencrypted in distributed and network environment Susceptible for replay attacks if encrypted naively Password advantage Easy to modify compromised password.

Attacks on Password Guessing attack/dictionary attack Social Engineering Sniffing Trojan login Van Eck sniffing

One-time Password Use the password exactly once!

Lamport’s scheme Doesn’t require any special hardware System computes F(x), F 2(x), …, F 100(x) (this allows 100 logins before password change) System stores user’s name and F 100(x) User supplies F 99(x) the first time If the login is correct, system replaces F 100(x) with F 99(x) Next login: user supplies F 98(x) … and so on User calculates Fn(x) using a hand-held calculator, a workstation, or other devices

Time Synchronized Secret key DES Time One Time Password Farkas CSCE 824 56

Challenge Response • Non-repeating challenges from the host is used • The device requires a keypad Work station Network Host User ID Challenge Response Farkas CSCE 824 57

Access Control Farkas CSCE 824 58

Access Control Protection objects: system resources for which protection is desirable Memory, file, directory, hardware resource, software resources, etc. Subjects: active entities requesting accesses to resources User, owner, program, etc. Access mode: type of access Read, write, execute

Access Control Requirement Cannot be bypassed Enforce least-privilege and need-to-know restrictions Enforce organizational policy

Access Control Access control: ensures that all direct accesses to object are authorized l Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs l Need: l – Proper user identification and authentication – Information specifying the access rights is protected form modification Farkas CSCE 824 61

Access Control l Access control components: – Access control policy: specifies the authorized accesses of a system – Access control mechanism: implements and enforces the policy l Separation of components allows to: – Define access requirements independently from implementation – Compare different policies – Implement mechanisms that can enforce a wide range of policies Farkas CSCE 824 62

Closed vs. Open Systems Closed system Open System (minimum privilege) (maximum privilege) Access requ. Exists Rule? yes Access permitted Farkas no Access requ. Allowed accesse s Exists Rule? no Access permitted Access denied CSCE 824 Disallowed accesses yes Access denied 63

Access Control Models All accesses Discretionary AC Mandatory AC Farkas Role-Based AC CSCE 824 64

Discretionary Access Control Access control is based on User’s identity and Access control rules Most common administration: owner based Users can protect what they own Owner may grant access to others Owner may define the type of access given to others

Access Matrix Model OBJECTS AND SUBJECTS S U B J E C T S File 1 Joe File 2 Read Write Own Sam Farkas CSCE 824 66

Grant and Revoke GRANT <privilege> ON <relation> To <user> [WITH GRANT OPTION] ------------------------------------------------------------------ GRANT SELECT * ON Student TO Matthews GRANT SELECT *, UPDATE(GRADE) ON Student TO FARKAS GRANT SELECT(NAME) ON Student TO Brown GRANT command applies to base relations as well as views

Grant and Revoke REVOKE <privileges> [ON <relation>] FROM <user> ------------------------------------------------------------- REVOKE SELECT* ON Student FROM Blue REVOKE UPDATE ON Student FROM Black REVOKE SELECT(NAME) ON Student FROM Brown

Non-cascading Revoke B E A D C F A revokes D’s privileges E B A F C Farkas CSCE 824 69

Cascading Revoke B E A D C F A revokes D’s privileges B A C Farkas CSCE 824 70

Positive and Negative Authorization B - E + + A C Farkas D Problem: Contradictory authorizations • GRANT <privilege> ON X TO <user> • DENY <privilege> ON X TO <user> CSCE 824 71

Negative Authorization - B + + A C Farkas E D Positive authorization granted By A to D becomes blocked but NOT deleted. CSCE 824 72

DAC and Trojan Horse Brown: read, write Employee Brown Read Employee Black, Brown: read, write REJECTED! Black is not allowed To access Employee Black’s Employee Black Farkas CSCE 824 73

DAC and Trojan Horse Brown: read, write Employee Word Processor Reads Employee Uses shared program Brown Black, Brown: read, write TH Inserts Trojan Horse Into shared program Black Farkas Copies Employee To Black’s Employee CSCE 824 Black’s Employee 74

DAC Overview Advantages: Intuitive Easy to implement Disadvantages: Inherent vulnerability (look TH example) Maintenance of ACL or Capability lists Maintenance of Grant/Revoke Limited power of negative authorization

Mandatory Access Control Objects: security classification e. g. , grades=(confidential, {student-info}) Subjects: security clearances e. g. , Joe=(confidential, {student-info}) Access rules: defined by comparing the security classification of the requested objects with the security clearance of the subject e. g. , subject can read object only if label(subject) dominates label(object) Farkas CSCE 824 76

Mandatory Access Control If access control rules are satisfied, access is permitted e. g. , Joe wants to read grades. label(Joe)=(confidential, {student-info}) label(grades)=(confidential, {student-info}) Joe is permitted to read grades Granularity of access rights! Farkas CSCE 824 77

Mandatory Access Control Security Classes (labels): (A, C) A – total order authority level C – set of categories e. g. , A = confidential > public , C = {student-info, dept-info} (confidential, {student-info, dept-info}) (confidential, {student-info}) (confidential, {dept-info}) (confidential, { }) (public, {student-info, dept-info}) (public, {student-info}) (public, {, dept-info}) (public, { }) Farkas CSCE 824 78

Mandatory Access Control Dominance ( ): label l=(A, C) dominates l’=(A’, C’) iff A A’ and C C’ e. g. , (confidential, {student-info}) (public, {student-info}) BUT (confidential, {student-info}) (public, {student-info, department-info}) Farkas CSCE 824 79

Bell- La. Padula (BLP) Model Confidentiality protection Lattice-based access control Subjects Objects Security Farkas labels Supports decentralized administration CSCE 824 80

BLP Reference Monitor All accesses are controlled by the reference monitor Cannot be bypassed Access is allowed iff the resulting system state satisfies all security properties Trusted subjects: subjects trusted not to compromise security Farkas CSCE 824 81

BLP Axioms 1. Simple-security property: a subject s is allowed to read an object o only if the security label of s dominates the security label of o No read up Applies to all subjects Farkas CSCE 824 82

BLP Axioms 2. *-property: a subject s is allowed to write an object o only if the security label of o dominates the security label of s No write down Applies Farkas to un-trusted subjects only CSCE 824 83

Blind Writes Improper modification of data Most implementations disallow blind writes Farkas CSCE 824 84

Trojan Horse and BLP Brown: read, write Word Processor Use shared program Brown Secret Reference Monitor Employee Secret Read Employee Black, Brown: read, write Black’s Employee TH Black Public Farkas Insert Trojan Horse Into shared program Copy Employee To Black’s Employee CSCE 824 Public Secret Public 85

RBAC Motivation Multi-user systems Multi-application systems Permissions are associated with roles Role-permission assignments are persistent v. s. user-permission assignments Intuitive: competency, authority and responsibility

RBAC Allows to express security requirements but CANNOT ENFORCE THESE PRINCIPLES e. g. , RBAC can be configured to enforce BLP rules but its correctness depend on the configuration done by the system security officer.

Roles User group: collection of user with possibly different permissions Role: mediator between collection of users and collection of permissions RBAC independent from DAC and MAC (they may coexist) RBAC is policy neutral: configuration of RBAC determines the policy to be enforced

RBAC 3 consolidated model RBAC 1 role hierarchy RBAC 2 constraints RBAC 0 base model Farkas CSCE 824 89

RBAC 0 U Users assignment S Sessions Farkas R Roles Permission P assignment Permissions . . . CSCE 824 90

RBAC 1 Role Hierarchy U Users assignment S Sessions Farkas R Roles Permission P assignment Permissions . . . CSCE 824 91

RBAC 1 Role Hierarchy Specialist Physician Primary-care Physician Inheritance of privileges Health-care provider Farkas CSCE 824 92

RBAC 2 U Users assignment S Sessions Farkas R Roles Permission P assignment Permissions . . . Constraints CSCE 824 93

RBAC 3 U Users assignment S Sessions Farkas R Roles Permission P assignment Permissions . . . Constraints CSCE 824 94

Next Class Database security Farkas CSCE 824 95