Cyber Defense Summary: Intrusion detection, Encryption and key Exchanges

Intrusion Detection

Intrusion Definition: Unauthorized access attempt to a system or resource.
Intrusion Detection: Monitoring system events to detect unauthorized access attempts in real-time.

Intrusion Activities Examples

Remote compromise of an email/web server
Password cracking
Unauthorized viewing/copying of sensitive data

Intrusion Detection Systems (IDS)

Components:
- Sensors: Collect data.
- Analyzers: Determine intrusion occurrence.
- User Interface: View output and control system behavior.
Types:
- Host-based IDS: Monitors a single host.
- Network-based IDS: Monitors network traffic.

IDS Principles

Intruder behavior differs from legitimate users.
Overlapping behaviors cause false positives and negatives.

IDS Requirements

Continuous operation with minimal supervision.
Fault-tolerant and recoverable from crashes.
Resistant to subversion and self-monitoring.
Minimal overhead and dynamic reconfiguration.
Adaptable, scalable, and provides graceful degradation.

Host-Based IDS

Monitors host activities for suspicious behavior.
Detects intrusions, logs events, and sends alerts.
Detects external and internal intrusions.

Intrusion Detection Measures

Login and Session Activity:
- Login Frequency: Detects unusual login times.
- Login Locations: Identifies unfamiliar locations.
- Time Since Last Login: Detects break-ins on "dead" accounts.
- Session Duration: Flags masqueraders.
- Output Quantity: Detects data leakage.
Command/Program Execution Activity:
- Execution Frequency: Detects unusual commands.
- Resource Utilization: Flags virus or Trojan injection.
- Execution Denials: Detects privilege escalation attempts.
File Access Activity:
- Read/Write Frequency: Detects masquerading or browsing.
- Records Accessed: Detects attempts to obtain sensitive data.
- Access Failures: Detects persistent unauthorized access attempts.

Host-Based IDS Approaches

Anomaly Detection:
- Threshold Detection: Counts event occurrences over time.
- Profile-Based: Detects deviations from user activity profiles.
Signature Detection:
- Uses rules or attack patterns to identify intruder behavior.

Network-Based IDS (NIDS)

Monitors network traffic in real-time.
Examines network, transport, and application-level activity.
Includes sensors, management servers, and consoles.
Traffic analysis occurs at the sensor, server, or both.

NIDS Sensor Deployment

Inline Sensor:
- Traffic passes through the sensor; can block attacks.
Passive Sensor:
- Monitors a copy of the traffic; more efficient due to reduced handling.

Network Tap for Passive NIDS Sensor

Connects via network tap to copy traffic.
Separate interfaces for monitoring and management.

Network IDS Techniques

Signature and anomaly detection.
Alerts and logs events upon detection.

NIDS Sensor Locations & Characteristics:

Location 1:
- Monitors attacks penetrating perimeter defenses.
- Highlights firewall policy issues.
- Detects attacks targeting web or FTP servers.
Location 2:
- Documents number/types of incoming attacks.
- High processing burden.
Location 3:
- Monitors both internal and external attacks.
- Detects unauthorized internal activity.
Location 4:
- Monitors specific user workstations or departments.
- Focuses on high-value assets.

SNORT

Lightweight IDS for real-time packet capture and rule analysis.
Easily deployed with low memory/processor usage.

SNORT Rules

Simple, flexible rule definition language.
Composed of a header and options.
Header Components: Action, Protocol, Source/Destination IP Address/Port, Direction.
- Bidirectional option considers address/port pairs in either direction.

SNORT Rule Actions

alert: Generate alert and log packet.
log: Log the packet.
pass: Ignore the packet.
activate/dynamic: Activate dynamic rules.
drop: Drop packet and log (iptables).
reject: Drop packet, log, and send TCP reset/ICMP unreachable.
sdrop: Drop packet without logging (iptables).

Symmetric Encryption

Provides confidentiality for transmitted or stored data using a single key.

Simplified Model of Symmetric Encryption

Encryption: $Y = E[K, X]$ (Plaintext X encrypted with key K to produce ciphertext Y).
Decryption: $X = D[K, Y]$ (Ciphertext Y decrypted with key K to produce plaintext X).

Attacking Symmetric Encryption

Cryptanalytic Attacks: Exploit algorithm characteristics with plaintext knowledge to deduce plaintext or key.
Brute-Force Attack: Trying all possible keys until intelligible plaintext is obtained.

Requirements for Secure Symmetric Encryption

Strong encryption algorithm: ciphertext and key are infeasible to be deciphered.
Secure key exchange and storage.

Average Time for Exhaustive Key Search

128-bit key considered safe.
Formula: Time = $2^{(KeySize - 1)} / DecryptionsPerMicrosecond$

Block & Stream Ciphers

Block Cipher:
- Processes input in blocks; can reuse keys.
Stream Cipher:
- Processes input continuously; faster and uses less code.
- Encrypts one byte at a time using a pseudorandom stream.

Block Cipher Encryption

Diagram illustrating block encryption sequence using a key K.

Stream Encryption

Diagram: Plaintext byte stream combined with pseudorandom key stream to produce ciphertext byte stream.

Comparison of Encryption Algorithms.

Chart showing characteristics of DES, Triple DES, and AES encryption. Key sizes, block sizes vary between them.

Message Authentication

Protects against active attacks.
Verifies message authenticity, integrity, and timeliness.
Uses conventional encryption where sender & receiver share a key. Ensures content unaltered, from authentic source, in correct sequence

Authentication via Symmetric Encryption

Symmetric encryption alone is insufficient for data authentication.
Reordering of ciphertext blocks doesn't affect decryption.
Authentication involves key verification, error detection codes, sequence numbers, and timestamps.

Authentication Without Message Encryption

Authentication tags/codes are generated using keys and appended to messages.
Messages are transmitted in plaintext.

Message Authentication Codes (MAC)

Message + Key -> MAC
Destination uses same algorithm/key to compare calculated MAC to incoming MAC value, ensuring integrity

Secure Hash Functions

Takes a variable length message to fixed length output for security.

Message Authentication Using a One-Way Hash Function

Diagrams illustrating different methods.
Using conventional encryption (symmetic key)
Using secret value.

Hash Function Requirements

Variable input, fixed output.
Computationally easy to compute H(x).
Computationally infeasible to find:
- x such that $H(x) = h$
- y ≠ x such that $H(y) = H(x)$
- Any pair (x, y) such that $H(x) = H(y)$

Security of Hash Functions

Attacked via cryptanalysis or brute-force.
Strength depends on the length of the hash code.
Secure Hash Algorithm (SHA) is widely used.
Additional Applications: passwords and intrusion detection.

Symmetric Key Distribution

Parties must share and protect the same key.
Frequent key changes limit compromised data.
Key distribution involves securely delivering keys to authorized parties without interception.

Key Distribution Options

Key physically delivered.
Third party delivers key.
Old key encrypts new key.
Third party C delivers key via encrypted links to A and B.

Kerberos

Key distribution and user authentication service.
Centralized authentication server authenticates users to servers and vice versa.
Relies exclusively on symmetric encryption.

Kerberos Overview

Authentication Server (AS) and Ticket Granting Server (TGS) process

Kerberos Version 4

(1) $C→ AS: IDc||PC||IDv$
(2) $AS → C: Ticket$
(3) $C→V: IDC || Ticket$
Formula : $Ticket = E(K,, [IDc||ADc||IDv])$

A More Secure Authentication Dialogue

Minimize password entries and prevent plaintext transmission.
Ticket-granting server (TGS) issues tickets to authenticated users.
- Timestamp used to prevent replaying captured ticket.
Once per user logon session:
- $(1) C→AS: IDC || ID tgs$
- (2) AS→C: E(Kc, Tickettgs) $</li></ul></li><li>Once per type of service:<ul><li>(3) C→TGS: IDC || IDV || Tickettgs$
- (4) TGS →C: Tickety $</li></ul></li><li>Once per service session:<ul><li>(5) C→V: ID c || Ticket$
Formula: Tickettgs = $E(Ktgs, [IDC || ADC || ID tgs || TS1 || Lifetime1])$
Formula: Ticket,, = $E(K,, [IDc|| ADc|| ID, || TS2 || Lifetime2])$

Problem: Both TGS and an application service must be able to prove that the person using a ticket is the same person to whom that was issued

Solution: session keys to exchange authenticator
session key (KC,tgs) between client and TGS; session key (KC,V) between client C and application service V

Summary of Kerberos Version 4 Message Exchanges

Authentication Service Exchange to obtain ticket-granting ticket
$(1) C → AS ID c || IDtgs || TS1$
$(2) AS → C E(K c, [Kc,tgs || IDtgs || TS2 || Lifetime2 || Tickettgs])$
Tickettgs = $E(Ktgs, [Kc,tgs || IDC || ADC || IDtgs || TS2 || Lifetime2])$
Ticket-Granting Service Exchange to obtain service-granting ticket
$(3) C → TGS IDv || Tickettgs || Authenticatorc$
$(4) TGS → C E(Kc,tgs, [Kc,v || IDv || TS4 || Ticketv])$
Tickettgs = $E(Ktgs, [Kc,tgs || IDC || ADC || IDtgs || TS2 || Lifetime2])$
Ticketv = $E(Kv, [Kc,v || IDC || ADC || IDv || TS4 || Lifetime4])$
Authenticatorc = $E(Kc,tgs, [IDC || ADC || TS3])$
Client/Server Authentication Exchange to obtain service
$(5) C → V Ticketv || Authenticatorc$
$(6) V → C E(Kc,v, [TS5 + 1])$ (for mutual authentication)
Ticketv = $E(Kv, [Kc,v || IDC || ADC || IDv || TS4 || Lifetime4])$
Authenticatorc = $E(Kc,v, [IDC || ADC || TS5])$
Summary of Kerberos Version 4 Message Exchanges

Kerberos exchanges between client, authentication server, ticket granting server and provider.

Table 4.2 covers rationale for the elements of the Kerberos Version 4 Protocol, why each portion is used.

Public-Key Cryptography

Proposed by Diffie and Hellman in 1976.
Uses separate public and private keys.
Private key is kept secret and some form of protocol is needed for distribution

Public-Key Encryption Model

Components: Plaintext, Encryption Algorithm, Public/Private Key, Ciphertext, Decryption Algorithm.

Usage of Private/Public keys.

Sender encrypts data using receiver’s public key. Receiver decrypts the message using his/her corresponding private key. Used to provide confidentiality.
User encrypts data using his or her own private key; used to provide authentication and data integrity.

Public-Key Cryptography Requirements

Computationally easy to create key pairs, encrypt messages. Computationally infeasible for opponent to determine private key from public key and knowing public key and cipher to recover original message

Public-Key Certificate Use

Digital Certificates
Used to verify public key for a user by signing statement of that key, by CA

X.509

ITU-T recommendation that defines a directory service.
Defines a framework for authentication services.
The directory may serve as a repository of public-key certificates

User certificates generated by a CA have the following characteristics

The standard does not dictate the use of a specific algorithm but recommends RSA
Any user with access to the public key of the CA can verify the user public key that was certified. Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them

Public-Key Certificate, Revocation

It may be desirable on occasion to revoke a certificate before it expires for one of the following reasons:
The user’s private key is assumed to be compromised
The user is no longer certified by this CA reasons for this include subject’s name has changed, the certificate is superseded, or the certificate was not issued in conformance with the CA’s policies or The CA’s certificate is assumed to be compromised

Applications For Public-Key Cryptosystems

Digital signature and Digital Envelopes

Digital Signatures

Used for authenticating both source and data integrity.
Created by encrypting hash code with private key.
Does not provide confidentiality.
*Even in the case of complete encryption, message can be decrypted using public key; message is safe from alteration but not eavesdropping.

Digital Envelopes

Symmetric encryption requires exchanging keys before sending/receiving messages securely
Digital envelop protects a message without first exchanging the same secret key between sender and receiver

TLS/SSL

TLS is an Internet standard that evolved from SSL.
It is a general-purpose service implemented as a set of protocols that rely on TCP.
TLS could be provided as part of the underlying protocol suite and therefore be transparent to applications, alternatively can be embedded in specific packages.

SSL/TLS Protocol Stack

Handshake
Change Cipher Spec
Alert Protocol
Heartbeat Protocol

TLS Two important concepts

A transport that provides a suitable type of service • For TLS such connections are peer-to- peer relationships • Connections are transient associated with one session TLS connection
An association between a client and a server • Created by the Handshake Protocol
Define a set of cryptographic security parameters which can be shared among multiple connections
Are used to avoid the expensive negotiation of new security parameters for each connection TLS session。

TLS Session States

Session identifier
Peer certificate. This may be null
Compression method • The algorithm used to compress data prior to encryption
For each connection, several secret values are used
Connection states have : serverrandom, clientrandom • Sequence numbers