Network and Information Security

Overview of Computer Security

• Keke Gai
• School of Computer Science and Technology, BIT
• gaikeke@bit.edu.cn
• 2021
Contents
• Computer Security Concepts
• Threads, Attacks and Assets
• Security Functional Requirements
• Fundamental Security Design Principles
• Attack Surfaces and Attack Trees
• Computer Security Strategy
Learning objectives
• Describe the key security requirements of
confidentiality, integrity and availability
• Discuss the types security threats and attacks that
must be dealt with
• Summarize the functional requirements for computer
security
• Explain the fundamental security design principles
• Discuss the use of attack surfaces and attack trees
• Understand the principle aspects of a comprehensive
security strategy
Computer Security Concepts

2
NATL INST. OF STAND & TECH R.I.C.

REFERENCI
PUBLICATIONS
A 11 10 3 S2D52Q

nist special Publication 800-12 An Introduction to Computer

Security: The NIST Handbook
U.S. DEPARTMENT OF
COMMERCE
Technology Administration
National Institute of Standards Barbara Guttman and Edward A. Roback
and Technology

COMPUTER SECURITY

Assurance ~) ^ User r
,
) Issues V~ Planning

Personnel

Access
Controls

Physical
Security
icy & C
Support/—-'

Operations
Management

QC
100
nist
.U57
NO. 800-1
1995
Computer Security Concepts
• Confidentiality（机密性）:
• preserving authorized restrictions
on information access and
disclosure.
• including means for protecting
personal privacy and proprietary
information
lity
tia

• Integrity（完整性）:
den

Int
egr
nfi

Data • guarding against improper

Co

tyi

and
services information modification or
destruction,
Availability
• including ensuring information
nonrepudiation and authenticity
Figure 1.1 The Security Requirements Triad
• Availability(可用性）:
安全需求三原则 • ensuring timely and reliable access
to and use of information
Computer Security Concepts
• Authenticity（真实性）:
• The property of being genuine and being able to be verified and trusted;
• Confidence in the validity of a transmission, a message, or message
originator.
• Means verifying that users are who they say they are and that each input
arriving at the system came from a trusted source.
• Accountability（可追踪性）:
• Assure actions of an entity to be traced uniquely to that entity.
• Because truly secure systems aren’t yet an achievable goal, we must be
able to trace a security breach to a responsible party.
• Systems must keep records of their activities to permit later forensic
analysis to trace security breaches or to aid in transaction disputes.
Levels of security breach impact

• Low: the loss will have a limited impact, e.g., a

degradation in mission or minor damage or minor
financial loss or minor harm
• Moderate: the loss has a serious effect, e.g.,
significance degradation on mission or significant
harm to individuals but no loss of life or
threatening injuries
• High: the loss has severe or catastrophic adverse
effect on operations, organizational assets or on
individuals (e.g., loss of life)
Security Categorization Applied to Information Types

Establishing an appropriate security category of an information

type essentially requires determining the potential impact for each
security objective associated with the particular information type.
Challenges of computer security

1. Computer security is not simple

2. One must consider potential (unexpected) attacks
3. Procedures used are often counter-intuitive
4. Must decide where to deploy mechanisms
5. Involve algorithms and secret info (keys)
6. A battle of wits between attacker / admin
7. It is not perceived on benefit until fails
8. Requires constant monitoring
9. Too often an after-thought (not integral)
10. Regarded as impediment to using system
Computer Security Terminology
Security Concepts and Relationships
Vulnerabilities
• Vulnerabilities(脆弱性)
– It can be corrupted , so that it does the wrong thing or
gives wrong answers. For example, stored data values
may differ from what they should be because they
have been improperly modified.
– It can become leaky . For example, someone who
should not have access to some or all of the
information available through the network obtains
such access.
– It can become unavailable or very slow. That is, using
the system or network becomes impossible or
impractical.
Attacks: Passive and Active
• Passive attacks attempt to learn or make use of information from the
system but does not affect system resources
• eavesdropping/monitoring transmissions
• difficult to detect
• emphasis is on prevention rather than detection
• two types:
– message contents
– traffic analysis
• Active attacks involve modification of the data stream
• goal is to detect them and then recover
• four categories:
– Masquerade(假冒)
– Replay(重放)
– modification of messages(篡改)
– denial of service(拒绝服务)
Threats and Attacks
Threats and Assets
Countermeasure(对策)
• prevent
means used to deal • detect
with security attacks • recover

may introduce new

vulnerabilities
Residual
vulnerabilities may
remain
goal is to minimize
residual level of risk
to the assets
Security functional requirements (FIPS 200)
Security functional requirements (FIPS 200)
Security functional requirements (FIPS 200)
Security functional requirements (FIPS 200)
• Technical measures
– Access control; identification & authentication; system &
communication protection; system & information
integrity
• Management controls and procedures
– Awareness & training; audit & accountability;
certification, accreditation, & security assessments;
contingency planning; maintenance; physical &
environmental protection; planning; personnel security;
risk assessment; systems & services acquisition
• Overlapping technical and management
– Configuration management; incident response; media
protection
Fundamental security design principles

• Despite years of research, it is still difficult to

design systems that comprehensively prevent
security flaws
• But good practices for good design have been
documented (analogous to software engineering)
– Economy of mechanism, fail-safe defaults, complete
mediation, open design, separation of privileges, lease
privilege, least common mechanism, psychological
accountability, isolation, encapsulation, modularity,
layering, least astonishment
Fundamental security design principles

• Economy of mechanism: the design of security

measures should be as simple as possible
– Simpler to implement and to verify
– Fewer vulnerabilities
• Fail-safe default: access decisions should be
based on permissions; i.e., the default is lack of
access
• Complete mediation: every access should
checked against an access control system
• Open design: the design should be open rather
than secret (e.g., encryption algorithms)
Fundamental security design principles

• Isolation
– Public access should be isolated from critical
resources (no connection between public and critical
information)
– Users files should be isolated from one another
(except when desired)
– Security mechanism should be isolated (i.e.,
preventing access to those mechanisms)
• Encapsulation: similar to object concepts (hide
internal structures)
• Modularity: modular structure
Fundamental security design principles

• Layering (defense in depth): use of multiple,

overlapping protection approaches
• Least astonishment: a program or interface
should always respond in a way that is least
likely to astonish a user
Fundamental security design principles

• Layering (defense in depth): use of multiple,

overlapping protection approaches
• Least astonishment: a program or interface
should always respond in a way that is least
likely to astonish a user
Fundamental security design principles

• Separation of privilege: multiple privileges

should be needed to do achieve access (or
complete a task)
• Least privilege: every user (process) should have
the least privilege to perform a task
• Least common mechanism: a design should
minimize the function shared by different users
(providing mutual security; reduce deadlock)
• Psychological acceptability: security mechanisms
should not interfere unduly with the work of
users
Computer Security Strategy

Specification & Implementation Correctness &

policy & mechanisms assurance

what is the
how does it do does it really
security scheme
it? work?
supposed to do?
Computer Security Strategy
• Security Policy
– informal statement of rules and practices that
specify or regulate security services
– factors to consider:
• value of the protected assets
• vulnerabilities of the system
• potential threats and the likelihood of attacks
– trade-offs to consider:
• ease of use versus security
• cost of security versus cost of failure and recovery
Computer Security Strategy
• Security Implementation
– Prevention: An ideal security scheme is one in which no attack is
successful.
– Detection: Absolute protection is not feasible, but it is practical to
detect security attacks.
– Response: If security mechanisms detect an ongoing attack, the
system may be able to respond in such a way as to halt the attack
and prevent further damage.
– Recovery: An example of recovery is the use of backup systems, so
that if data integrity is compromised, a prior, correct copy of the
data can be reloaded.
Computer Security Strategy
• Assurance and Evaluation
– assurance
• the degree of confidence one has that the security
measures work as intended
• both system design and implementation
– evaluation
• process of examining a system with respect to certain
criteria
• involves testing and formal analytic or mathematical
techniques
Chapter 2 – Cryptographic Tools

1
 Cryptographic Tools
• cryptographic algorithms important element
in security services
• review various types of elements
– symmetric encryption
– public-key (asymmetric) encryption
– digital signatures and key management
– secure hash functions
• example is use to encrypt stored data

2
Symmetric Encryption

3
 Attacking Symmetric Encryption
• cryptanalysis
– rely on nature of the algorithm
– plus some knowledge of plaintext characteristics
– even some sample plaintext-ciphertext pairs
– exploits characteristics of algorithm to deduce
specific plaintext or key
• brute-force attack
– try all possible keys on some ciphertext until get
an intelligible translation into plaintext

4
Exhaustive Key Search

5
Symmetric Encryption Algorithms

6
 DES and Triple-DES
• Data Encryption Standard (DES) is the most
widely used encryption scheme
– uses 64 bit plaintext block and 56 bit key to
produce a 64 bit ciphertext block
– concerns about algorithm & use of 56-bit key
• Triple-DES
– repeats basic DES algorithm three times
– using either two or three unique keys
– much more secure but also much slower
7
 Advanced Encryption Standard
(AES)
• needed a better replacement for DES
• NIST called for proposals in 1997
– efficiency, security, HW/SW suitability, 128, 256,
256 keys
• selected Rijndael in Nov 2001
• symmetric block cipher
• uses 128 bit data & 128/192/256 bit keys
• now widely available commercially

8
 Block
verses
Stream
Ciphers

9
 Message Authentication
• protects against active attacks
• verifies received message is authentic
– contents unaltered
– from authentic source
– timely and in correct sequence
• can use conventional encryption
– only sender & receiver have key needed
• or separate authentication mechanisms
– append authentication tag to cleartext message
10
Message Authentication Codes

11
Secure Hash Functions

12
Message
Auth

13
 Hash Function Requirements
• Applied to any size data
• H produces a fixed-length output
• H(x) is relatively easy to compute for any given x
• one-way property
– computationally infeasible to find x such that H(x) = h
• weak collision resistance
– computationally infeasible to find y ≠ x such tha H(y) = H(x)
• strong collision resistance
– computationally infeasible to find any pair (x, y) such that H(x) = H(y)

14
 Hash Functions
• two attack approaches
– cryptanalysis
• exploit logical weakness in alg
– brute-force attack
• trial many inputs
• strength proportional to size of hash code (2n/2)
• SHA most widely used hash algorithm
– SHA-1 gives 160-bit hash
– more recent SHA-256, SHA-384, SHA-512 provide
improved size and security

15
Public Key Encryption

16
 Public Key Authentication
Authentication and/or data integrity

17
 Public Key Requirements
1. computationally easy to create key pairs
2. computationally easy for sender knowing public key to
encrypt messages
3. computationally easy for receiver knowing private key to
decrypt ciphertext
4. computationally infeasible for opponent to determine private
key from public key
5. computationally infeasible for opponent to otherwise
recover original message
6. useful if either key can be used for each role

18
 Public Key Algorithms
• RSA (Rivest, Shamir, Adleman)
– developed in 1977
– only widely accepted public-key encryption alg
– given tech advances need 1024+ bit keys
• Diffie-Hellman key exchange algorithm
– only allows exchange of a secret key
• Digital Signature Standard (DSS)
– provides only a digital signature function with SHA-1
• Elliptic curve cryptography (ECC)
– new, security like RSA, but with much smaller keys

19
 Public Key Certificates
See textbook figure p.63

20
 Digital
Envelopes

Another application of public key alg

21
 Random Numbers
• random numbers have a range of uses
• requirements:
• randomness
– based on statistical tests for uniform distribution
and independence
• unpredictability
– successive values not related to previous
– clearly true for truly random numbers
– but more commonly use generator
22
 Pseudorandom verses Random
Numbers
• often use algorithmic technique to create
pseudorandom numbers
– which satisfy statistical randomness tests
– but likely to be predictable
• true random number generators use a
nondeterministic source
– e.g. radiation, gas discharge, leaky capacitors
– increasingly provided on modern processors

23
 Practical Application:
Encryption of Stored Data

• common to encrypt transmitted data

• much less common for stored data
– which can be copied, backed up, recovered
• approaches to encrypt stored data:
– back-end appliance (hardware device close to data storage;
encrypt close to wire speed)
– library based tape encryption (co-processor board
embedded in tape drive)
– background laptop/PC data encryption
24
 Summary
• introduced cryptographic algorithms
• symmetric encryption algorithms for
confidentiality
• message authentication & hash functions
• public-key encryption
• digital signatures and key management
• random numbers

25
Chapter 2 – Symmetric Encryption
and Message Confidentiality

1
 Symmetric Encryption and Message
Confidentiality
Ø also known as: conventional encryption, secret-key, or
single-key encryption
l only alternative before public-key crypto in 70’s
l still most widely used alternative
l has ingredients: plaintext, encryption algorithm, secret key,
ciphertext, and decryption algorithm
Ø generically classified along dimensions of:
1. type of operations used
2. number of keys used
3. way in which the plaintext is processed
2
 Cryptanalysis
Øattacks:
lciphertext only - least info, hardest
lknown plaintext - some plain/cipher pairs
lchosen plaintext - get own plain/cipher pairs
lchosen ciphertext - rarer
lchosen text - rarer
Øonly weak algs fail a ciphertext-only attack
Øusually design algs to withstand a known-
plaintext attack
3
 Computationally Secure Algs
Ø encryption is computationally secure if:
l cost of breaking cipher exceeds info value
l time required to break cipher exceeds the useful lifetime of the info
Ø usually very difficult to estimate the amount of effort required to
break
Ø can estimate time/cost of a brute-force attack (see Ch 2)

4
 Feistel
Cipher
Structure

5
 Block Cipher Structure
Ø have a general iterative block cipher structure
l with a sequence of rounds
l with substitutions / permutations controlled by key
Ø parameters and design features:
l block size
l key size
l number of rounds
l subkey generation algorithm
l round function
l fast software en/decrypt

6
Data Encryption Standard (DES)

7
 Triple DES (3DES)
Øfirst used in financial applications
Øin DES FIPS PUB 46-3 standard of 1999
Øuses three keys & three DES executions:
C = E(K3, D(K2, E(K1, P)))
Ødecryption same with keys reversed
Øuse of decryption in second stage gives
compatibility with original DES users
Øeffective 168-bit key length, slow, secure
ØAES will eventually replace 3DES
8
Advanced
Encryption
Standard
(AES)

9
AES Round Structure

10
 Substitute Bytes
Øa simple table lookup in S-box
la 16´16 matrix of byte values
lmapping old byte to a new value
• e.g. {95} maps to {2A}
la permutation of all possible 256 8-bit values
Øconstructed using finite field properties
ldesigned to be resistant to known cryptanalytic
attacks
Ødecrypt uses inverse of S-box
11
 Shift Rows
Ø on encrypt left rotate each row of State by 0,1,2,3
bytes respectively
Ø decrypt does reverse
Ø to move individual bytes from one column to another
and spread bytes over columns

12
 Mix Columns & Add Key
ØMix Columns
loperates on each column individually
lmapping each byte to a new value that is a
function of all four bytes in the column
luse of equations over finite fields
lto provide good mixing of bytes in column
ØAdd Round Key
lsimply XOR State with bits of expanded key
lsecurity from complexity of round key expansion
and other stages of AES
13
 Stream Ciphers
Ø processes input elements continuously
Ø key input to a pseudorandom bit generator
l produces stream of random like numbers
l unpredictable without knowing input key
l XOR keystream output with plaintext bytes
Ø are faster and use far less code
Ø design considerations:
l encryption sequence should have a large period
l keystream approximates random number properties
l uses a sufficiently long key
14
RC4

15
 Modes of Operation
Ø block ciphers process data in blocks
l e.g. 64-bits (DES, 3DES) or 128-bits (AES)
Ø for longer messages must break up
l and possibly pad end to blocksize multiple
Ø have 5 five modes of operation for this
l defined in NIST SP 800-38A
l modes are: ECB, CBC, CFB, OFB, CTR

16
 Electronic Codebook (ECB)
Ø simplest mode
Ø split plaintext into blocks
Ø encrypt each block using the same key
Ø “codebook” because have unique ciphertext value for each plaintext block
l not secure for long messages since repeated plaintext is seen in repeated
ciphertext

17
Cipher Block Chaining (CBC)

18
Cipher Feedback (CFB)

19
Counter (CTR)

20
Location of Encryption

21
 Key Distribution
Øsymmetric crypto needs a shared key:
Øtwo parties A & B can achieve this by:
lA selects key, physically delivers to B
l3rd party select keys, physically delivers to A, B
• reasonable for link crypto, bad for large no’s users
lA selects new key, sends encrypted using previous
old key to B
• good for either, but security fails if any key discovered
l3rd party C selects key, sends encrypted to each of A
& B using existing key with each
• best for end-to-end encryption
22
Key Distribution

23
 Summary
Ø introduced symmetric encryption basics
Ø DES, 3DES and AES
Ø stream ciphers and RC4
Ø modes of operation
Ø location of encryption
Ø key distribution

24
 Chapter 2 – Public-Key
Cryptography and Message
Authentication
Public-Key Cryptography and Message
Authentication
• now look at technical detail concerning:
– secure hash functions and HMAC
– RSA & Diffie-Hellman Public-Key Algorithms
 Simple Hash Functions
• a one-way or secure hash function used in
message authentication, digital signatures
• all hash functions process input a block at a time
in an iterative fashion
• one of simplest hash functions is the bit-by-bit
exclusive-OR (XOR) of each block
Ci = bi1 Å bi2 Å . . . Å bim
– effective data integrity check on random data
– less effective on more predictable data
– virtually useless for data security
 SHA Secure Hash Functions
• SHA originally developed by NIST/NSA in 1993
• was revised in 1995 as SHA-1
– US standard for use with DSA signature scheme
– standard is FIPS 180-1 1995, also Internet RFC3174
– produces 160-bit hash values
• NIST issued revised FIPS 180-2 in 2002
– adds 3 additional versions of SHA
– SHA-256, SHA-384, SHA-512
– with 256/384/512-bit hash values
– same basic structure as SHA-1 but greater security
• NIST intend to phase out SHA-1 use
SHA-512 Structure
SHA-512
Round
 Other Secure Hash Functions
• most based on iterated hash function design
– if compression function is collision resistant
– so is resultant iterated hash function
• MD5 (RFC1321)
– was a widely used hash developed by Ron Rivest
– produces 128-bit hash, now too small
– also have cryptanalytic concerns
• Whirlpool (NESSIE endorsed hash)
– developed by Vincent Rijmen & Paulo Barreto
– compression function is AES derived W block cipher
– produces 512-bit hash
 HMAC
• interest a MAC using a cryptographic hash
– due to speed and code availability
• must incorporate key into use of hash alg
• HMAC (RFC2104) widely supported
– used in IPsec, TLS & SET
• HMAC treats hash as “black box”
• HMAC proven secure if embedded hash
function has reasonable cryptographic
strength
 HMAC
Structure
 Security of HMAC
• security based on underlying hash strength
• have prob given time and no msg-MAC’s
• either attacker computes output even with
random secret IV
– brute force key O(2n), or use birthday attack
• or attacker finds collisions in hash function
even when IV is random and secret
– ie. find M and M' such that H(M) = H(M')
– birthday attack O( 2n/2)
– MD5 secure in HMAC since only observe
 RSA Public-Key Encryption
• by Rivest, Shamir & Adleman of MIT in 1977
• best known & widely used public-key alg
• uses exponentiation of integers modulo a prime
• encrypt: C = Me mod n
• decrypt: M = Cd mod n = (Me)d mod n = M
• both sender and receiver know values of n and e
• only receiver knows value of d
• public-key encryption algorithm with
– public key PU = {e, n} & private key PR = {d, n}.
RSA Algorithm
RSA Example
 Attacks on RSA
• brute force
– trying all possible private keys
– use larger key, but then slower
• mathematical attacks (factoring n)
– see improving algorithms (QS, GNFS, SNFS)
– currently 1024-2048-bit keys seem secure
• timing attacks (on implementation)
– use - constant time, random delays, blinding
• chosen ciphertext attacks (on RSA props)
 Diffie-Hellman Key Exchange
• first public-key type scheme proposed
• by Diffie & Hellman in 1976 along with the
exposition of public key concepts
– note: now know that Williamson (UK CESG)
secretly proposed the concept in 1970
• practical method to exchange a secret key
• used in a number of commercial products
• security relies on difficulty of computing
discrete logarithms
 Diffie-
Hellman
Algorithm
 Diffie-Hellman Example
• have
– prime number q = 353
– primitive root a = 3
• A and B each compute their public keys
– A computes YA = 397 mod 353 = 40
– B computes YB = 3233 mod 353 = 248
• then exchange and compute secret key:
– for A: K = (YB)XA mod 353 = 24897 mod 353 = 160
– for B: K = (YA)XB mod 353 = 40233 mod 353 = 160
• attacker must solve:
– 3a mod 353 = 40 which is hard
– desired answer is 97, then compute key as B does
Key Exchange Protocols
 Man-in-the-Middle Attack
• attack is:
1. Darth generates private keys XD1 & XD2, and their public
keys YD1 & YD2
2. Alice transmits YA to Bob
3. Darth intercepts YA and transmits YD1 to Bob. Darth also
calculates K2
4. Bob receives YD1 and calculates K1
5. Bob transmits XA to Alice
6. Darth intercepts XA and transmits YD2 to Alice. Darth
calculates K1
7. Alice receives YD2 and calculates K2
• all subsequent communications compromised
 Other Public-Key Algorithms
• Digital Signature Standard (DSS)
– FIPS PUB 186 from 1991, revised 1993 & 96
– uses SHA-1 in a new digital signature alg
– cannot be used for encryption
• elliptic curve cryptography (ECC)
– equal security for smaller bit size than RSA
– seen in standards such as IEEE P1363
– still very new, but promising
– based on a mathematical construct known as the
elliptic curve (difficult to explain)
 Summary
• discussed technical detail concerning:
– secure hash functions and HMAC
– RSA & Diffie-Hellman Public-Key Algorithms
Computer Security: Principles
and Practice

Chapter
EECS710:3: User Authentication
Information Security
Professor Hossein Saiedian
Fall 2014

1
 Chapter 3 overview
• Electronic user authentication principles
• Password-based authentication
• Token-based authentication
• Biometric authentication
• Remote user authentication
• Security issues for user authentication
• Practical application: an iris biometric system
• Case study: security problems for ATM systems
2
 Learning objectives
• Discuss the four general means of authenticating
a user’s identity
• Explain the mechanism by which hashed
passwords used for user authentication
• Understand the use of the Bloom filters in
password management
• Present an overview of token-based user
authentication
• Discuss the issues involved and the approaches
for remote user authentication

3
 User Authentication
• Fundamental security building block
– basis of access control & user accountability
• The process of verifying an identity claimed by or
for a system entity
• Two steps:
– identification: specify
– verification: bind entity (person) and identifier
• Distinct from message authentication (when
communicating parties are concerned with the integrity of the exchanges
messages)

4
 A model for electronic user
authentication
• NIST SP 800-63-2 defines EUA as: the process of establishing
confidence in user identity that are electronically presented
• The NIST SP 800-63-2 model
– User applies to registration authority (RA) and becomes a subscriber
of a credential service provider (CSP)
– RA is a trusted entity
– The CSP exchanges with the subscriber
– The credential (a data structure) binds an identity to a token
possessed by the subscriber
– Claimant: the party to be authenticated
– Verifier: the party verifying
– The verifier passes an assertion about the subscriber to the relaying
party (PR)

5
A model for electronic user
authentication

6
 Means of user authentication
• Four means of authenticating user's identity
• Based one something the individual
– knows, e.g. password, PIN
– possesses, e.g. key, token, smartcard
– is (static biometrics), e.g. fingerprint, retina
– does (dynamic biometrics), e.g. voice, sign
• Can use alone or combined
• All can provide user authentication
• All have issues
7
 Risk assessment for user
authentication
• Assurance level: the degree of certainty that a
user has presented a credential that refers to
his/her identity
– Level 1: little confidence (an online forum)
– Level 2: some confidence (professional organizations)
– Level 3: High confidence (patent office applicants)
– Level 4: Very high confidence (employees accessing
restricted/sensitive services)
• Potential impact: low, moderate, high impacts

8
 Risk assessment for user
authentication
Assurance Level Impact
Profiles

Potential Impact Categories for Authentication

1 2 3 4
Errors

Inconvenience, distress, or damage to

Low Mod Mod High
standing or reputation

Financial loss or organization liability Low Mod Mod High

Harm to organization programs or interests None Low Mod High
Unauthorized release of sensitive information None Low Mod High

Mod/
Personal safety None None Low
High

Civil or criminal violations None Low Mod High

9
 Password authentication
• Widely used user authentication method
– user provides name/login and password
– system compares password with that saved for
specified login
• Authenticates ID of user logging and
– that the user is authorized to access system
– determines the user’s privileges
– is used in discretionary access control

10
 Password vulnerabilities
• offline dictionary attack
• specific account attack (user john)
• popular password attack (against a wide range of
IDs)
• password guessing against single user (w/ previous
knowledge about the user)
• workstation hijacking
• exploiting user mistakes
• exploiting multiple password use
• electronic monitoring

11
 Countermeasures for password
vulnerability
• stop unauthorized access to password file
• intrusion detection measures
• account lockout mechanisms
• policies against using common passwords but
rather hard to guess passwords
• training & enforcement of policies
• automatic workstation logout
• encrypted network links

12
 Countermeasures for password
vulnerability
• It is worthwhile to study/research password
and password vulnerabilities
– Most common
– Still the most efficient

13
Use of hashed
passwords

14
 Why a salt value?
• Prevents duplicate passwords from being
visible in the password file
• Increases the difficulty of offline dictionary
attacks
• Nearly impossible to tell if a person used the
same password on multiple systems

15
 UNIX Implementation
• Original scheme
– 8 character password form 56-bit key
– 12-bit salt used to modify DES encryption into a
one-way hash function
– output translated to 11 character sequence
• Now regarded as woefully insecure
– e.g. supercomputer, 50 million tests, 80 min
• Sometimes still used for compatibility

16
 Improved implementations
• Have other, stronger, hash/salt variants
• Many systems now use MD5
– with 48-bit salt
– password length is unlimited
– is hashed with 1000 times inner loop
– produces 128-bit hash
• OpenBSD uses Blowfish block cipher based
and hash algorithm called Bcrypt
– uses 128-bit salt to create 192-bit hash value
17
 Password Cracking
• Dictionary attacks
– try each word then obvious variants in large
dictionary against hash in password file
• Rainbow table attacks
– a large dict of possible passwords
– for each password:
• precompute tables of hash values for all salts
• a mammoth table of hash values: e.g. 1.4GB table cracks
99.9% of alphanumeric Windows passwords in 13.8 secs
– not feasible if larger salt values used
18
 Password choices/concerns
• users may pick short passwords
– e.g. 3% were 3 chars or less, easily guessed
– system can reject choices that are too short
• users may pick guessable passwords
– so crackers use lists of likely passwords
– e.g. one study of 14000 encrypted passwords
guessed nearly 1/4 of them
– would take about 1 hour on fastest systems to
compute all variants, and only need 1 break!

19
 Another case study
• An analysis of passwords used by 25,000
students
• Over 10% recovered after 10^10 guesses

20
 Password File Access Control
• Can block offline guessing attacks by denying
access to encrypted passwords
– make available only to privileged users
– often using a separate shadow password (for su
only)
• Still have vulnerabilities
– exploit O/S bug
– accident with permissions making it readable
– users with same password on other systems
– access from unprotected backup media
– sniff passwords in unprotected network traffic
21
 Using Better Passwords
• Clearly have problems with passwords
• Goal to eliminate guessable passwords
– Still easy for user to remember
• Techniques
– user education
– computer-generated passwords
– reactive password checking (periodic checking)
– proactive password checking (at the time of
selection)

22
 Proactive Password Checking
• Rule enforcement plus user advice, e.g.
– 8+ chars, upper/lower/numeric/punctuation
– may not suffice
• Password cracker
– list of bad passwords
– time and space issues
• Markov Model
– generates guessable passwords
– hence reject any password it might generate
• Bloom Filter
– use to build table based on dictionary using hashes
– check desired password against this table

23
 Token-based authentication
• Object user possesses to authenticate, e.g.
– memory card (magnetic stripe)
– smartcard

24
 Memory Card
• store but do not process data
• magnetic stripe card, e.g. bank card
• electronic memory card
• used alone for physical access (e.g., hotel
rooms)
• some with password/PIN (e.g., ATMs)
• Drawbacks of memory cards include:
– need special reader
– loss of token issues
– user dissatisfaction (OK for ATM, not OK for
computer access)
25
 Smartcard
• credit-card like
• has own processor, memory, I/O ports
– ROM, EEPROM, RAM memory
• executes protocol to authenticate with reader/computer
– static: similar to memory cards
– dynamic: passwords created every minute; entered
manually by user or electronically
– challenge-response: computer creates a random
number; smart card provides its hash (similar to PK)
• also have USB dongles

26
 Electronic identify cards
• An important application of smart cards
• A national e-identity (eID)
• Serves the same purpose as other national ID
cards (e.g., a driver’s licence)
– Can provide stronger proof of identity
– A German card
• Personal data, Document number, Card access number (six
digit random number), Machine readable zone (MRZ): the
password
• Uses: ePass (government use), eID (general use), eSign (can
have private key and certificate)

27
User authentication with eID

28
 Biometric authentication
• Authenticate user based on one of their
physical characteristics:
– facial
– fingerprint
– hand geometry
– retina pattern
– iris
– signature
– voice

29
 Operation of a
biometric
system

Verification is analogous to
user login via a smart card
and a PIN

Identification is biometric info

but no IDs; system compares
with stored templates

30
 Biometric Accuracy
• The system generates a matching score (a number) that quantifies
similarity between the input and the stored template
• Concerns: sensor noise and detection inaccuracy
• Problems of false match/false non-match

31
 Remote User Authentication
• Authentication over network more complex
– Problems of eavesdropping, replay
• Generally use challenge-response
– user sends identity
– host responds with random number r
– user computes f(r,h(P)) and sends back
– host compares value from user with own
computed value, if match user authenticated
• Protects against a number of attacks
33
Protocol for a password verification
• Similar approach
for token and
biometric
verification

34
 Authentication Security Issues
• Client attacks: attacker attempts to achieve
user authentication without access to the
remote host
– Masquerade as a legitimate user (e.g., guess the
password or try all passwords)
– Countermeasure: strong passwords; limit number
of attempts

35
 Authentication Security Issues
• Host attacks: attacker attacks the host where
passwords/passcodes are stored
– Countermeasure: hashing, protect password
databases

36
 Authentication Security Issues
• Eavesdropping: attacker attempts to learn
passwords by observing the user, finding
written passwords, keylogging
– Countermeasures
• diligence to keep passwords
• multifactor authentication
• admin revoke compromised passwords

37
 Authentication Security Issues
• Replay: attacker repeats a previously captured
user response
– Countermeasure
• Challenge-response
• 1-time passcodes

38
 Authentication Security Issues
• eavesdropping
• replay
• trojan horse

39
 Authentication Security Issues
• Trojan horse: an application or physical device
masquerades as an authentic application or
device
– Countermeasure: authentication of the client within a
trusted security environment
• Denial of service: attacker attempts to disable a
user authentication service (via flooding)
– Countermeasure: a multifactor authentication with a
token

40
Practical Application

41
 Summary
• Introduced user authentication
– using passwords
– using tokens
– using biometrics
• Remote user authentication issues
• Example application and case study

43
Computer Security: Principles
and Practice

Chapter 4: Access Control

EECS710: Information Security
Professor Hossein Saiedian
Fall 2014

1
 Access Control
• “The prevention of unauthorized use of a
resource, including the prevention of use of a
resource in an unauthorized manner“
• Central element of computer security
• Assume have users and groups
– authenticate to system
– assigned access rights to certain resources on
system

2
Access Control Principles

3
 Access control policies
• Discretionary access control (DAC): based on the identity of
the requestor and access rules
• Mandatory access control (MAC): based on comparing
security labels with security clearances (mandatory: one with
access to a resource cannot pass to others)
• Role-based access control (RBAC): based on user roles
• Attribute-based access control: based on the attributes of the
user, the resources and the current environment

4
 Access Control Requirements
• Reliable input: a mechanism to authenticate
• Fine and coarse specifications: regulate access at varying levels
(e.g., an attribute or entire DB)
• Least privilege: min authorization to do its work
• Separation of duty: divide steps among different individuals
• Open and closed policies: accesses specifically authorized or all
accesses except those prohibited
• Administrative policies: who can add, delete, modify rules

5
 Access Control Elements
• Subject: entity that can access objects
– a process representing user/application
– often have 3 classes: owner, group, world
• Object: access controlled resource
– e.g. files, directories, records, programs etc
– number/type depend on environment
• Access right: way in which subject accesses an
object
– e.g. read, write, execute, delete, create, search
6
 Discretionary Access Control
• Often provided using an access matrix
– lists subjects in one dimension (rows)
– lists objects in the other dimension (columns)
– each entry specifies access rights of the specified
subject to that object
• Access matrix is often sparse
• Can decompose by either row or column

7
 Access Control Structures

• Access control lists (decomposed by column)

• Capability tickets (decomposed by row)
• See page 119
• Also see alternative table representation on
page 120 (tabular but not sparse)

8
An access matrix

9
Access matrix data structures

10
Alternate authorization table

11
 An Access Control Model

• Extend the universe of objects to include

processes, devices, memory locations,
subjects

12
 Access
Control
Function

13
Access control system commands

14
 Protection Domains: More Useful
• Set of objects together with access rights to those objects
• More flexibility when associating capabilities with protection
domains
• In terms of the access matrix, a row defines a protection domain
• User can spawn processes with a subset of the access rights of the
user
• Association between a process and a domain can be static or
dynamic
• In user mode certain areas of memory are protected from use and
certain instructions may not be executed
• In kernel mode privileged instructions may be executed and
protected areas of memory may be accessed

15
 UNIX File Concepts
• UNIX files administered using inodes (index
nodes)
• An inode:
– control structure with key info on file (attributes,
permissions, …)
– on a disk: an inode table for all files
– when a file is opened, its inode is brought to RAM
• Directories form a hierarchical tree
– may contain files or other directories
– are a file of names and inode numbers

16
 UNIX File Access Control
• Unique user identification number (user
ID)
• Member of a primary group identified
by a group ID
• 12 protection bits
• 9 specify read, write, and execute
permission for the owner of the file,
members of the group and all other
users
• 2 speficiy SetID, SetGID
• 1 is the sticky bit (only owner can
remove, delete, …, a directory)
• The owner ID, group ID, and protection bits
are part of the file’s inode

17
 UNIX File Access Control
• “set user ID”(SetUID) or “set group ID”(SetGID)
– system temporarily uses rights of the file owner/group in addition to
the real user’s rights when making access control decisions
– enables privileged programs to access files/resources not generally
accessible
• Sticky bit
– on directory limits rename/move/delete to owner
• Superuser
– is exempt from usual access control restrictions

18
 UNIX Access Control Lists
• Modern UNIX systems support ACLs
• Can specify any number of additional
users/groups and associated rwx permissions
• When access is required
– select most appropriate ACL
• owner, named users, owning/named groups, others
– check if have sufficient permissions for access

19
UNIX extended access control list

20
 Role-Based
Access Control
Access based on
‘role’, not identity

Many-to-many
relationship between
users and roles

Roles often static

21
 Role-Based
Access Control

Role-users and
roles-object
access matrix

22
 General RBAC, Variations
• A family of RBAC with four models
1. RBAC0: min functionality
2. RBAC1: RBAC0 plus role (permission) inheritance
3. RBAC2: RBAC0 plus constraints (restrictions)
4. RBAC3: RBAC0 plus all of the above
• RBAC0 entities
– User: an individual (with UID) with access to system
– Role: a named job function (tells authority level)
– Permission: equivalent to access rights
– Session: a mapping between a user and set of roles to which a
user is assigned

23
 Role-Based
Access Control

Double arrow: ‘many’ relationship

Single arrow: ‘one’ relationship

24
 Example of role hierarchy
• Director has most
privileges
• Each role inherits all
privileges from lower
roles
• A role can inherit from
multiple roles
• Additional privileges can
be assigned to a role

25
 Constraints
• A condition (restriction) on a role or between
roles
– Mutually exclusive
• role sets such that a user can be assigned to only one of the
role in the set
• Any permission can be granted to only one role in the set
– Cardinality: set a maximum number (of users) wrt a
role (e.g., a department chair role)
– Prerequisite role: a user can be assigned a role only if
that user already has been assigned to some other
role

26
 Attribute-based access control
• Fairly recent
• Define authorizations that express conditions on
properties of both the resource and the subject
– Each resource has an attribute (e.g., the subject that
created it)
– A single rule states ownership privileges for the creators
• Strength: its flexibility and expressive power
• Considerable interest in applying the model to
cloud services

27
 Types of attributes
• Subject attributes
• Object attributes
• Environment attributes

28
 Subject attributes
• A subject is an active entity that causes
information to flow among objects or changes
the system state
• Attributes define the identity and
characteristics of the subject
– Name
– Organization
– Job title

29
 Object attribute
• An object (or resource) is a passive
information system-related entity containing
or receiving information
• Objects have attributes that can be leveraged
to make access control decisions
– Title
– Author
– Date

30
 Environment attributes
• Describe the operational, technical, and even
situational environment or context in which
the information access occurs
– Current date
– Current virus/hacker activities
– Network security level
– Not associated with a resource or subject
• These attributes have so far been largely
ignored in most access control policies

31
 Sample ABAC scenario
1. A subject requests
access to an object
2. AC is governed by a set
of rules (2a): assesses
the attr of subject (2b),
object (2c) and env (2d)
3. AC grants subject
access to object if
authorized

32
ACL vs ABAC trust relationships

33
ACL vs ABAC trust relationships

34
 Identity, Credential, and Access
Management (ICAM)
• A comprehensive approach to managing and
implementing digital identities, credentials, and access
control
• Developed by the U.S. government
• Designed to create trusted digital identity
representations of individuals and nonperson entities
(NPEs)
• A credential is an object or data structure that
authoritatively binds an identity to a token possessed
and controlled by a subscriber
• Use the credentials to provide authorized access to an
agency’s resources

35
 1. Connects digital identity
to individuals

ICAM

2. Data structures that binds

a token possessed
by a subscriber

4. Identity verification of
individuals from external
organizations
3. Management of how access
is granted to entities

36
Case study: RBAC system for a bank

37
Case study: RBAC system for a bank
• b has more access than A (strict ordering)
• Inheritance makes tables simpler

38
Case study: RBAC system for a bank

39
 Summary
• introduced access control principles
– subjects, objects, access rights
• discretionary access controls
– access matrix, access control lists (ACLs),
capability tickets
– UNIX traditional and ACL mechanisms
• role-based access control
• case study

40
Computer Security: Principles
and Practice

Chapter 5: Information
EECS710: Database Security
Security
Professor Hossein Saiedian
Fall 2014

1
 Database systems
• Structured collection of data stored for use by
one or more applications
• Contains the relationships between data items
and groups of data items
• Can sometimes contain sensitive data that
needs to be secured
• Query language: Provides a uniform interface
to the database

2
Database Security

3
 Relational Databases
• Constructed from tables of data
– each column holds a particular type of data
– each row contains a specific value these
– ideally has one column where all values are
unique, forming an identifier/key for that row
• Have multiple tables linked by identifiers
• Sse a query language to access data items
meeting specified criteria

4
 Relational databases
• Table of data consisting of rows and columns
– Each column holds a particular type of data
– Each row contains a specific value for each column
– Ideally has one column where all values are unique, forming an
identifier/key for that row
• Enables the creation of multiple tables linked together by
a unique identifier that is present in all tables
• Use a relational query language to access the database
– Allows the user to request data that fit a given set of criteria

5
A relational database example

6
 Relational database terms
• Relation/table/file
• Tuple/row/record
• Attribute/column/field
• Primary key: uniquely identifies a row
• Foreign key: links one table to attributes in
another
• View/virtual table: Result of a query that
returns selected rows and columns from one
or more tables
7
Abstract view of a relation

8
Relational Database Elements

9
 Structured Query Language
• Structure Query Language (SQL)
– originally developed by IBM in the mid-1970s
– standardized language to define, manipulate, and
query data in a relational database
CREATE – several
TABLE similar
department ( versions
CREATEof ANSI/ISO
VIEW standard
newtable (Dname, Ename, Eid, Ephone)
Did INTEGER PRIMARY KEY, AS SELECT D.Dname E.Ename, E.Eid, E.Ephone
Dname CHAR (30), FROM Department D Employee E
Dacctno CHAR (6) )
WHERE E.Did = D.Did

CREATE TABLE employee (

Ename CHAR (30),
Did INTEGER,
SalaryCode INTEGER,
Eid INTEGER PRIMARY KEY,
Ephone CHAR (10),
FOREIGN KEY (Did) REFERENCES department (Did) )

10
 SQL injection attacks
• One of the most prevalent and dangerous
network-based security threats
• Sends malicious SQL commands to the
database server
• Depending on the environment SQL injection
can also be exploited to:
– Modify or delete data
– Execute arbitrary operating system commands
– Launch denial-of-service (DoS) attacks

11
A Typical Injection Attack

12
 Sample SQL injection
• The SQLi attack typically works by prematurely
terminating a text string and appending a new
command

SELECT fname
FROM student
where fname is ‘user prompt’;

User: John’; DROP table Course;--

13
 Sample SQL injection: tautology
$query= “
SELECT info FROM user WHERE name =
`$_GET[“name”]’ AND pwd = `GET[“pwd”]`
”;

Attacker enters: ` OR 1=1 –-

14
 In-band attacks
• Tautology: This form of attack injects code in one or
more conditional statements so that they always
evaluate to true
• End-of-line comment: After injecting code into a
particular field, legitimate code that follows are nullified
through usage of end of line comments
• Piggybacked queries: The attacker adds additional
queries beyond the intended query, piggy-backing the
attack on top of a legitimate request

15
 Database Access Control
• DBMS provide access control for database
• assume have authenticated user
• DBMS provides specific access rights to portions of the
database
– e.g. create, insert, delete, update, read, write
– to entire database, tables, selected rows or columns
– possibly dependent on contents of a table entry
• can support a range of policies:
– centralized administration
– ownership-based administration
– decentralized administration

16
 Inferential attack (gathering info)
• There is no actual transfer of data, but the
attacker is able to reconstruct the information
by sending particular requests and observing
the resulting behavior of the
Website/database server
– Illegal/logically incorrect queries: lets an attacker
gather important information about the type and
structure of the backend database of a Web
application

17
 Out-band attack
• This can be used when there are limitations
on information retrieval, but outbound
connectivity from the database server is lax

18
 SQLi countermeasures
• Defensive coding: stronger data validation
• Detection
– Signature based
– Anomaly based
– Code analysis
• Runtime prevention: Check queries at runtime
to see if they conform to a model of expected
queries

19
 SQL Access Controls
• If the user has access to the entire database or just portions
of it
• Two commands:
– GRANT {privileges | role} [ON table] TO {user |
role | PUBLIC} [IDENTIFIED BY password] [WITH
GRANT OPTION]
• e.g. GRANT SELECT ON ANY TABLE TO john
– REVOKE {privileges | role} [ON table] FROM
{user | role | PUBLIC}
• e.g. REVOKE SELECT ON ANY TABLE FROM john
– WITH GRANT OPTION: whether grantee can grant
“GRANT” option to other users
• Typical access rights are:
– SELECT, INSERT, UPDATE, DELETE, REFERENCES

20
Cascading Authorizations

21
 Role-Based Access Control
• Role-based access control work well for DBMS
– eases admin burden, improves security
• Categories of database users:
– application owner
– end user
– administrator
• DB RBAC must manage roles and their users

22
Inference

23
Inference Example

24
 Inference Countermeasures
• Inference detection at database design
– alter database structure or access controls
• Inference detection at query time
– by monitoring and altering or rejecting queries

25
 Statistical Databases
• Provides data of a statistical nature
– e.g. counts, averages
• Two types:
– pure statistical database
– ordinary database with statistical access
• some users have normal access, others statistical
• Access control objective to allow statistical use
without revealing individual entries
• Security problem is one of inference
26
 Protecting
Against Inference

27
 Perturbation
• Add noise to statistics generated from data
– will result in differences in statistics
• Data perturbation techniques
– data swapping
– generate statistics from probability distribution
• Output perturbation techniques
– random-sample query
– statistic adjustment
• Must minimize loss of accuracy in results

28
 Database Encryption
• Databases typical a valuable info resource
– protected by multiple layers of security: firewalls, authentication, O/S
access control systems, DB access control systems, and database
encryption
• Can encrypt
– entire database - very inflexible and inefficient
– individual fields - simple but inflexible
– records (rows) or columns (attributes) - best
• also need attribute indexes to help data retrieval
• Varying trade-offs

29
Database Encryption

30
 Cloud computing
• An increasing trend in many organizations to move a
substantial portion (or all) of their IT to cloud computing
• NIST SP-800-145 defines cloud computing as: “A model for
enabling ubiquitous, convenient, on-demand network access
to a shared pool of configurable computing resources (e.g.,
networks, servers, storage, applications, and services) that
can be rapidly provisioned and released with minimal
management effort or service provider interaction. …”

31
Cloud computing elements

32
 Essential characteristics: Broad
network access
• Capabilities available over a network
• Accessed thru standard mechanisms
• Use by heterogeneous client platforms
(desktops, laptops, tablets, cell phones)

33
 Essential characteristics: Rapid
elasticity
• The ability to expand/reduce services to
specific requirements
• Large numbers of servers during the holidays
• Smaller number of resources during off-peak
periods
• Release a resource when a task is completed

34
 Essential characteristics: Measured
service
• Cloud system automatically
– Control and optimize resource use by leveraging a
metering capability appropriate to the type of
service
– Storage, processing, bandwidth, active users

35
 Essential characteristics: On-demand
service
• A consumer can unilaterally provision
computing capabilities without requiring
human interaction
– Server time, network storage
– Resources wont have to a permanent part of the
client’s IT infrastructure

36
 Essential characteristics: Resource
pooling
• As a consequence of the above
• The providers resources are pooled to serve
multiple consumers using a multi-tenant
model
• Multiple resources assigned and re-assigned
to clients
– Storage, processing power, bandwidth …
• Consumers need not to know the physical
location of the service
37
 Service model: SaaS
• provides service to
customers in the form of
application software
• Clients need not to install
• Clients can access
application via various
platforms thru a simple
interface (often a
browser)

38
 Service model: PaaS
• Provides service to
customers in the form of
a platform on the which
the customer apps can
run
• Clients deploy on the
cloud
• PaaS provides useful
building block/tools

39
 Service model: IaaS
• Provides clients access
to the underlying cloud
infrastructure
• VM and other
abstracted hardware,
OS, APIs
• Amazon Elastic
Computing (EC2) and
Windows Azure

40
 Deployment models
• Public: the cloud resources/services are
available to the general public
• Private: The cloud infrastructure is solely for
an organization
• Community: the cloud infrastructure is for a
specific community and is shared by several
organizations
• Hybrid: a composition two or more of the
above
41
A typical cloud service context

42
NIST’s reference architecture
(conceptual model)

43
 NIST’s reference architecture
(conceptual model)
• Cloud customer: A person or organization that
uses or is interested in cloud providers services
• Cloud provider (CP): a person or organization
that makes cloud services available
• Cloud auditor: A party that conducts
independent assessment of sources (e.g.,
security)
• Cloud broker: A party that manages use,
performance,, negotiations
• Cloud carrier: An intermediator that provides
connectivity and service transport
44
 Cloud provider (CP)
• For SaaS: CP deploys, configures, maintains,
updates app software
• For PaaS: CP manages the computing
infrastructure for the platform (middleware,
database, OS, programming languages, tools)
• For IaaS: CP acquires physical computing
resources: servers, network, storage, …

45
 Cloud security risks
• Abuse and nefarious use of cloud computing
– Relatively easy to register for the services
– Many cloud services offer free trials
– Enables hackers to get inside to conduct attacks
(spamming, DoS, …)
– The burden on CP to provide protection
• Countermeasures
1.Stricter/restrict registration
2.Enhanced credit card monitoring
3.Comprehensive monitoring (traffic)

46
 Cloud security risks
• Insecure interfaces of APIs
– CPs expose a set of APIs for customers apps
– Security depends on APIs: must be secure (from
authentication to encryption)
• Countermeasures
1. Analyzing the security of APIs
2. Ensuring strong authentication and access control
3. Understanding the dependency chair between the
APIs

47
 Cloud security risks
• Malicious insiders
– Client organization relinquishes many (or all) of its
IT and gives to the CP
– A grave concern: malicious insider activity
• Countermeasures (by client)
1. Comprehensive supplier assessment
2. Specify human resource requirements as part of
legal contract
3. Require transparency

48
 Cloud security risks
• Shared technology issues
– IaaS services are delivered in a scalable way by a
shared infrastructure (CPU caches, GPUs, …)
– Probably not designed for multi-tenant architecture
– Vulnerable to attacks (insider and outsiders)
• Countermeasures
1. Implement best security practices during
implementation, deployment, configuration
2. Monitor environment for unauthorized activities
3. Promote strong authentication and access control

49
 Cloud security risks
• Data loss or leakage
– Cloud storage may be the only backup storage
– Could be devastating for many clients if data is lost
• Countermeasures
1. Implement strong API access control
2. Encrypt and protect integrity when in transit
3. Analyze data protection at design and run time

50
 Cloud security risks
• Account or service hijacking
– Usually with stolen credentials
– Compromise confidentiality, integrity and
availability
• Countermeasures
1. Prohibit sharing of credentials between users
2. Leverage strong multi-factory authentication
3. Employ proactive monitoring

51
 Data protection in the cloud
• Data must be secured while at transit, in use,
or at rest
– Client can employ encryption for transit
– Client can encrypt data for storage (rest) but can
also be CP’s responsibility (key management)

52
 Cloud security as a service
• Identify management
• Data loss prevention
• Web security
• E-mail security
• Encryption
• Business continuity
• Network security
• …

53
 Summary
• Introduced databases and DBMS
• Relational databases
• Database access control issues
– SQL, role-based
• Inference
• Statistical database security issues
• Database encryption
• Cloud security

54
Computer Security: Principles
and Practice

Chapter 6: Malicious Software

EECS710: Information Security
Professor Hossein Saiedian
Fall 2014

1
 Malware
“A program that is inserted into a system,
usually covertly, with the intent of
compromising the confidentiality, integrity, or
availability of the victim’s data, applications, or
operating system or otherwise annoying or
disrupting the victim.”

2
 Malicious software
• Programs exploiting system vulnerabilities
• Known as malicious software or malware
– program fragments that need a host program
• e.g. viruses, logic bombs, and backdoors
– independent self-contained programs
• e.g. worms, bots
– replicating or not
• Sophisticated threat to computer systems

3
 Malware Terminology
• Virus: attaches itself to a program
• Worm: propagates copies of itself to other computers
• Logic bomb: “explodes” when a condition occurs
• Trojan horse: fakes/contains additional functionality
• Backdoor (trapdoor): allows unauthorized access to functionality
• Mobile code: moves unchanged to heterogeneous platforms
• Auto-rooter Kit (virus generator): malicious code (virus) generators
• Spammer and flooder programs: large volume of unwanted “pkts”
• Keyloggers: capture keystrokes
• Rootkit: sophisticated hacker tools to gain root-level access
• Zombie: software on infected computers that launch attack on others (aka
bot)

4
 Some terms
• Payload: actions of the malware
• Crimeware: kits for building malware; include
propagation and payload mechanisms
– Zeus, Sakura, Blackhole, Phoenix
• APT (advanced persistent threats)
– Advanced: sophisticated
– Persistent: attack over an extended period of time
– Threat: selected targets (capable, well-funded
attackers)

5
 Viruses
• Piece of software that infects programs
– modifying them to include a copy of the virus
– so it executes secretly when host program is run
• Specific to operating system and hardware
– taking advantage of their details and weaknesses
• A typical virus goes through phases of:
– dormant: idle
– propagation: copies itself to other program
– triggering: activated to perform functions
– execution: the function is performed

6
 Virus structure
• Components:
– infection mechanism: enables replication
– trigger: event that makes payload activate
– payload: what it does, malicious or benign
• Prepended/postpended/embedded
• When infected program invoked, executes
virus code then original program code
• Can block initial infection (difficult) or
propagation (with access controls)
7
Virus structure

8
 Compression virus

P1 is infected

9
 Virus classification
• By target
– boot sector: infect a master boot record
– file infector: infects executable OS files
– macro virus: infects files to be used by an app
– multipartite: infects multiple ways
• By concealment
– encrypted virus: encrypted; key stored in virus
– stealth virus: hides itself (e.g., compression)
– polymorphic virus: recreates with diff “signature”
– metamorphic virus: recreates with diff signature and behavior

10
 Macro and scripting viruses
• Became very common in mid-1990s since
– platform independent
– infect documents
– easily spread
• Exploit macro capability of Office apps
– executable program embedded in office doc
– often a form of Basic
• More recent releases include protection
• Recognized by many anti-virus programs
11
 E-Mail Viruses
• More recent development
• Melissa
– exploits MS Word macro in attached doc
– if attachment opened, macro activates
– sends email to all on users address list and does
local damage

12
 Virus countermeasures
• Prevention: ideal solution but difficult
• Realistically need:
– detection: determine what occurred
– identification: identify the specific virus
– removal: remove all traces
• If detected but can’t identify or remove, must
discard and replace infected program

13
 Anti-virus evolution
• Virus & antivirus tech have both evolved
• Early viruses simple code, easily removed
• As viruses become more complex, so did the
countermeasures
• Generations
– first - signature scanners (bit patterns all the
same)
– second – heuristics (integrity checks; checksums)
– third - identify actions (find by actions they do)
– fourth - combination packages

14
 Generic decryption
• Runs executable files through GD scanner:
– CPU emulator to interpret instructions
– virus scanner to check known virus signatures
– emulation control module to manage process
• Lets virus decrypt itself in interpreter
• Periodically scan for virus signatures
• Let virus do the work for an antivirus program
by exposing it in a controlled environment
15
 Digital immune system

1. A monitoring pgm infers a virus, sends a copy to an adm machine

2. Adm encrypts, sends to a central analysis machine
3. Central analysis: Safe exec of virus, analyze, give a prescription
4. Prescription sent back to the adm machines
5. Adm machine forwards to all clients
6. Prescription forwarded to other organizations
7. Subscribers worldwide receive regular updates IBM/Symantec Project

16
Behavior-blocking software
Integrates with the OS; looks for bad behavior

Monitored behaviors:
-Attempts to open, view, delete, modify files
-Attempts to format drives
-Modifications to the logic of executables
-Modifications to critical system settings
-Scripting of emails to send exec contents

17
 Worms
• Replicating program that propagates over net
– using email, remote exec, remote login
• Has phases like a virus:
– dormant, propagation, triggering, execution
– propagation phase: searches for other systems, connects to it, copies
self to it and runs
• May disguise itself as a system process
• Concept seen in Brunner’s “Shockwave Rider”
• Implemented by Xerox Palo Alto labs in 1980’s

18
 Morris worm
• One of best know worms
• Released by Robert Morris in 1988
– Affected 6,000 computers; cost $10-$100 M
• Various attacks on UNIX systems
– cracking password file to use login/password to
logon to other systems
– exploiting a bug in the finger protocol
– exploiting a bug in sendmail
• If succeed have remote shell access
– sent bootstrap program to copy worm over
19
Worm Propagation Model (based on recent
attacks)

linear rate of infection

exponential rate of infection

20
 More recent worm attacks
• Code Red
– July 2001 exploiting MS IIS bug
– probes random IP address, does DDoS attack
– consumes significant net capacity when active
– 360,000 servers in 14 hours
• Code Red II variant includes backdoor: hacker controls the
worm
• SQL Slammer (exploited buffer-overflow vulnerability)
– early 2003, attacks MS SQL Server
– compact and very rapid spread
• Mydoom (100 M infected messages in 36 hours)
– mass-mailing e-mail worm that appeared in 2004
– installed remote access backdoor in infected systems

21
 State of worm technology
• Multiplatform: not limited to Windows
• Multi-exploit: Web servers, emails, file sharing …
• Ultrafast spreading: do a scan to find vulnerable hosts
• Polymorphic: each copy has a new code
• Metamorphic: change appearance/behavior
• Transport vehicles (e.g., for DDoS)
• Zero-day exploit of unknown vulnerability (to
achieve max surprise/distribution)

22
 Worm countermeasures
• Overlaps with anti-virus techniques
• Once worm on system A/V can detect
• Worms also cause significant net activity
• Worm defense approaches include:
– signature-based worm scan filtering: define signatures
– filter-based worm containment (focus on contents)
– payload-classification-based worm containment
(examine packets for anomalies)
– threshold random walk scan detection (limit the rate of
scan-like traffic)
– rate limiting and rate halting (limit outgoing traffic
when a threshold is met)

23
Proactive worm containment
1. PWC agent monitors
outgoing traffic for
increased activity

2. When an agent notices

high traffic, it informs
the PWC manager; mgr
propagates to other
hosts

3. Hosts receive alert

and decide if to ignore
(based on time of last
incoming pkt)

4. Relaxation period
(based on threshold)

24
 Mobile code
• Scripts, macros or other portable instructions
• Popular ones: JavaScript, ActiveX, VBScript
• Heterogeneous platforms
• From a remote system to a local system
• Can act as an agent for viruses, works, and Trojan
horses
• Mobile phone works: communicate the Bluetooth
connections (e.g., CommWarrior on Symbian but
attempts on Android and iPhone)

25
 Client-side vulnerabilities
• Drive-by-downloads: common in recent
attacks
• Exploits browser vulnerabilities (when a user
visits a website controlled by the attacker or a
compromised website)
• Clickjacking

26
 Social engineering, spam, email,
Trojans
• Spam (much better protection now)
• Trojan horse: looks like a useful tool but
contains hidden code

27
 Payload
• Data destruction, theft
• Data encryption (ransomware)
• Real-world damage
– Stuxnet: caused physical damage also (targeted to
Siemens industrial control software)
• Logic bomb

28
 Payload attack agents: bots
(zombie/drone)
• Program taking over other computers and
launch attacks
– hard to trace attacks
• If coordinated form a botnet
• Characteristics:
– remote control facility (distinguishing factor)
• via IRC/HTTP etc
– spreading mechanism
• attack software, vulnerability, scanning strategy
• Various counter-measures applicable (IDS,
honeypots, …)
29
 Uses of bots
• DDoS
• Spamming
• Sniffing traffic
• Keylogging
• Spreading malware
• Installing advertisement
• Manipulating games and polls

30
 Payload: information theft
• Credential theft, key loggers, spyware
• Phishing identify theft
• Spear phishing (act as a trusted source for a
specific target)

31
 Payload: rootkits and backdoor
• Set of programs installed for admin access
• Malicious and stealthy changes to host O/S
• May hide its existence
– subverting report mechanisms on processes, files, registry entries etc
• May be persistent (survives reboot) or memory-based
• Do not rely on vulnerabilities
– installed via Trojan
– installed via hackers
• Backdoor: often by programmers

32
 Rootkit System Table Mods
A Unix Example
User API calls refer to a number; the system
maintains a system call table with one entry per number;
each number is used to index to a corresponding system routine

rootkit modifies the table and the calls go to the hackers

replacements

33
 Countermeasures
• Prevention
• Detection, identification, removal
• Requirement
– generality
– Timeliness
– Resiliency
– Minimal DoS costs
– Transparency
– Global/local coverage (inside and outside attackers)
34
 Summary
• introduced types of malicous software
– incl backdoor, logic bomb, trojan horse, mobile
• virus types and countermeasures
• worm types and countermeasures
• bots
• rootkits

35