WORMS

UNIT II: Malware and Vulnerability

Adarsh Kumar
Professor, Systems, School of Computer Science, UPES, Dehradun,
Uttarakhand, India
[email protected]

February 21, 2025

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 1 / 88

Table of Contents

1 Worms
Detection and Prevention Algorithms
Signature-Based Prevention Algorithm
Behavioral Prevention Algorithm
Network-Based Prevention
Patch Management
Access Control
Network Segmentation
Least Privilege Principle

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 2 / 88

Detection and Prevention Algorithms

Detection Algorithms Prevention Algorithms

Signature-Based Detection Signature-Based Prevention
Heuristic-Based Detection Behavioral Prevention
Behavioral-Based Detection Network-Based Prevention
Anomaly-Based Detection Patch Management
Sandboxing Access Control
Static Code Analysis Network Segmentation
Least Privilege Principle

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 3 / 88

Signature-Based Prevention Algorithm
Signature Database Creation:
Signature Definition: Each signature represents a specific pattern of malicious activity.
These patterns could be sequences of bytes, hashes of files, or known exploit sequences.
Mathematical Representation: Let S = {s1 , s2 , . . . , sn } be the set of all signatures
where each si is a signature defined in a specific format (e.g., byte sequences).

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 4 / 88

Signature-Based Prevention Algorithm
Signature Database Creation:
Signature Definition: Each signature represents a specific pattern of malicious activity.
These patterns could be sequences of bytes, hashes of files, or known exploit sequences.
Mathematical Representation: Let S = {s1 , s2 , . . . , sn } be the set of all signatures
where each si is a signature defined in a specific format (e.g., byte sequences).
Data Collection:
Incoming Data: Let D represent the incoming data stream which needs to be analyzed
for threats.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 4 / 88

Signature-Based Prevention Algorithm
Signature Database Creation:
Signature Definition: Each signature represents a specific pattern of malicious activity.
These patterns could be sequences of bytes, hashes of files, or known exploit sequences.
Mathematical Representation: Let S = {s1 , s2 , . . . , sn } be the set of all signatures
where each si is a signature defined in a specific format (e.g., byte sequences).
Data Collection:
Incoming Data: Let D represent the incoming data stream which needs to be analyzed
for threats.
Pattern Matching:
Matching Process: For each signature si in the signature database S, the algorithm
checks if si exists in the incoming data D.
Mathematical Operation: This can be represented as a search operation where the
algorithm searches for occurrences of si in D.
Naive Search: For each si , scan through D to find if si is a substring of D. This is a
basic form of pattern matching with a time complexity of O(m · n), where m is the length
of D and n is the length of si .
Optimized Search: Using algorithms like Knuth-Morris-Pratt or Boyer-Moore can improve
search efficiency, potentially reducing time complexity to O(m + n) in practice.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 4 / 88

Signature-Based Prevention Algorithm
Signature Database Creation:
Signature Definition: Each signature represents a specific pattern of malicious activity.
These patterns could be sequences of bytes, hashes of files, or known exploit sequences.
Mathematical Representation: Let S = {s1 , s2 , . . . , sn } be the set of all signatures
where each si is a signature defined in a specific format (e.g., byte sequences).
Data Collection:
Incoming Data: Let D represent the incoming data stream which needs to be analyzed
for threats.
Pattern Matching:
Matching Process: For each signature si in the signature database S, the algorithm
checks if si exists in the incoming data D.
Mathematical Operation: This can be represented as a search operation where the
algorithm searches for occurrences of si in D.
Naive Search: For each si , scan through D to find if si is a substring of D. This is a
basic form of pattern matching with a time complexity of O(m · n), where m is the length
of D and n is the length of si .
Optimized Search: Using algorithms like Knuth-Morris-Pratt or Boyer-Moore can improve
search efficiency, potentially reducing time complexity to O(m + n) in practice.
Detection and Prevention:
Detection: If a signature si is found in D, a match is detected.
Prevention Actions: Based on the detected signatures, predefined actions are taken, such
as blocking the data, alerting the user, or logging the event.
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 4 / 88
Example: Byte Sequence Matching

Example Scenario: Let’s consider a simple example where D is a byte stream, and each
signature si is a sequence of bytes.
Signature Database Example:
s1 = 0x90, 0x90, 0x90 (NOP sled)
s2 = 0xDE, 0xAD, 0xBE, 0xEF (Example signature)

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 5 / 88

Example: Byte Sequence Matching

Example Scenario: Let’s consider a simple example where D is a byte stream, and each
signature si is a sequence of bytes.
Signature Database Example:
s1 = 0x90, 0x90, 0x90 (NOP sled)
s2 = 0xDE, 0xAD, 0xBE, 0xEF (Example signature)
Data to Scan:
D = 0x00, 0x00, 0x90, 0x90, 0x90, 0xAB, 0xCD

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 5 / 88

Example: Byte Sequence Matching

Example Scenario: Let’s consider a simple example where D is a byte stream, and each
signature si is a sequence of bytes.
Signature Database Example:
s1 = 0x90, 0x90, 0x90 (NOP sled)
s2 = 0xDE, 0xAD, 0xBE, 0xEF (Example signature)
Data to Scan:
D = 0x00, 0x00, 0x90, 0x90, 0x90, 0xAB, 0xCD
Matching Process:
For s1 : Scan D for the byte sequence 0x90, 0x90, 0x90.
For s2 : Scan D for the byte sequence 0xDE, 0xAD, 0xBE, 0xEF.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 5 / 88

Example: Byte Sequence Matching

Example Scenario: Let’s consider a simple example where D is a byte stream, and each
signature si is a sequence of bytes.
Signature Database Example:
s1 = 0x90, 0x90, 0x90 (NOP sled)
s2 = 0xDE, 0xAD, 0xBE, 0xEF (Example signature)
Data to Scan:
D = 0x00, 0x00, 0x90, 0x90, 0x90, 0xAB, 0xCD
Matching Process:
For s1 : Scan D for the byte sequence 0x90, 0x90, 0x90.
For s2 : Scan D for the byte sequence 0xDE, 0xAD, 0xBE, 0xEF.
Result:
s1 is found at position 2 in D, so a match is detected, and appropriate action is taken.
s2 is not found in D, so no action is taken for s2 .

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 5 / 88

Example: Byte Sequence Matching

Example Scenario: Let’s consider a simple example where D is a byte stream, and each
signature si is a sequence of bytes.
Signature Database Example:
s1 = 0x90, 0x90, 0x90 (NOP sled)
s2 = 0xDE, 0xAD, 0xBE, 0xEF (Example signature)
Data to Scan:
D = 0x00, 0x00, 0x90, 0x90, 0x90, 0xAB, 0xCD
Matching Process:
For s1 : Scan D for the byte sequence 0x90, 0x90, 0x90.
For s2 : Scan D for the byte sequence 0xDE, 0xAD, 0xBE, 0xEF.
Result:
s1 is found at position 2 in D, so a match is detected, and appropriate action is taken.
s2 is not found in D, so no action is taken for s2 .
Note: A NOP sled is a sequence of ”No Operation” (NOP) instructions placed in the memory
area where an attacker intends to execute malicious code. Its purpose is to create a large,
contiguous region of memory that does nothing (i.e., it executes no operations), allowing the
attacker to direct the execution flow to any part of this region and still eventually reach the
malicious payload.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 5 / 88

Limitations and Mathematical Extensions

Limitations
Signature-Based Detection Limitations
This approach only detects known threats. It cannot identify new, unknown
threats that do not have corresponding signatures.
The efficiency of the matching process can vary based on the size of the
database and the complexity of the signatures.

Mathematical Extensions
Probabilistic Models
Some systems use probabilistic models or machine learning to improve detection
accuracy and reduce false positives.

Hash-Based Matching
Using hash functions to represent signatures and hashes of data can speed up the
matching process.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 6 / 88

Behavioral Prevention Algorithm
Behavioral Prevention in cybersecurity is a technique used to detect and
prevent threats based on the behavior of programs or processes, rather
than relying on known signatures. This approach aims to identify and
block malicious activities by analyzing deviations from normal behavior
patterns.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 7 / 88

Behavioral Prevention Algorithm (Step 1):Data Collection and
Profiling
Normal Behavior Profiling:
Definition: Establish a profile of normal behavior for programs or
processes. This profile includes typical resource usage patterns,
system calls, file operations, network activity, etc.
Mathematical Representation: Let B represent the normal
behavior profile. This profile can be defined as a set of parameters or
statistical distributions for various metrics.
For example, if analyzing CPU usage, BCPU might be modeled as a
normal distribution N (µCPU , σCPU ) where µCPU is the mean CPU
usage and σCPU is the standard deviation.
Data Collection:
Collect data from the system or application to build the normal
behavior profile. This data can be represented as a vector of features
X = [x1 , x2 , . . . , xn ] where each xi represents a specific behavior
metric.
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 8 / 88
Behavioral Prevention Algorithm (Step 2):Behavior Analysis
Feature Extraction:
Extract features from ongoing system activities or program executions. Let
Xt = [x1,t , x2,t , . . . , xn,t ] denote the feature vector at time t.
Behavioral Modeling:
Statistical Analysis: Use statistical models to represent the normal behavior. For
example, a multivariate normal distribution can be used to model normal behavior across
multiple features.
Mean Vector (µ): Average of observed features.
Covariance Matrix (Σ): Measures the variance and correlation between features.
The normal behavior B can be represented as N (µ, Σ).
Anomaly Detection:
Mahalanobis Distance: Measure the distance of the current behavior Xt from the normal
behavior profile using the Mahalanobis distance.
q
DM (Xt ) = (Xt − µ)T Σ−1 (Xt − µ)

where DM (Xt ) is the Mahalanobis distance, µ is the mean vector of normal behavior, and
Σ−1 is the inverse of the covariance matrix.
Thresholding: Compare the Mahalanobis distance with a predefined threshold θ. If
DM (Xt ) > θ, the behavior is considered anomalous.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 9 / 88

Behavioral Prevention Algorithm (Step 3):Response
Mechanism

Alert Generation:
If the behavior is detected as anomalous, generate an alert or log the
event.
Preventive Actions:
Based on the severity of the detected anomaly, take preventive
actions such as blocking the process, isolating the system, or
terminating the suspicious activity.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 10 / 88

Step 1: Normal Behavior Profiling
Data Collection and Feature Extraction
Monitoring two features:
x1 = CPU usage (%)
x2 = Memory usage (MB)
Collected dataset:

30 400

32 420
X = 28

390
31 410
29 405
Step 1: Compute the Mean Vector
Mean of CPU Usage:
30 + 32 + 28 + 31 + 29
µCPU = = 30
5
Mean of Memory Usage:
400 + 420 + 390 + 410 + 405
µMemory = = 405
5
Mean Vector:  
30
µ=
405

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 11 / 88

Step 2: Compute the Covariance Matrix
Step 2: Compute Variances and Covariance
Variance of CPU Usage:

2 (30 − 30)2 + (32 − 30)2 + (28 − 30)2 + (31 − 30)2 + (29 − 30)2
σCPU =
4
0+4+4+1+1
= = 2.5
4
Variance of Memory Usage:

2 (400 − 405)2 + (420 − 405)2 + (390 − 405)2 + (410 − 405)2 + (405 − 405)2
σMemory =
4
25 + 225 + 225 + 25 + 0
= = 125
4
Covariance between CPU and Memory:
(30 − 30)(400 − 405) + (32 − 30)(420 − 405)
+ (28 − 30)(390 − 405) + (31 − 30)(410 − 405)
+ (29 − 30)(405 − 405)
Cov(CPU, Memory) =
4
(0)(−5) + (2)(15) + (−2)(−15) + (1)(5) + (−1)(0) 0 + 30 + 30 + 5 + 0
= = = 16.25
4 h i 4
Covariance Matrix: 2.5 16.25
Σ = 16.25 125
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 12 / 88
Step 3: Anomaly Detection using Mahalanobis Distance
New Observation:  
40
Xt =
480
Step 1: Compute the Deviation Vector
     
40 30 10
Xt − µ = − =
480 405 75
Step 2: Compute the Inverse of the Covariance Matrix
Using the formula for a 2 × 2 inverse matrix:
2
 
−1 1 σMemory −Cov(CPU, Memory)
Σ = 2
det(Σ) −Cov(CPU, Memory) σCPU
Determinant:
det(Σ) = (2.5 × 125) − (16.25 × 16.25) = 312.5 − 264.0625 = 48.4375
Inverse:  
2.58 −0.34
Σ−1 ≈
−0.34 0.052
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 13 / 88
Step 4: Compute Mahalanobis Distance

Step 3: Compute Mahalanobis Distance

q
DM (Xt ) = (Xt − µ)T Σ−1 (Xt − µ)

Step 4: Compute the Quadratic Form

  
  2.58 −0.34 10
10 75
−0.34 0.052 75
p
DM (Xt ) = (25.8 − 25.5 + 3.9)

DM (Xt ) ≈ 2.05
Step 5: Compare with Threshold
Predefined threshold: θ = 2.0
Since DM (Xt ) = 2.05 > 2.0, the behavior is anomalous.
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 14 / 88
Network-Based Prevention

Worms are malicious programs that propagate through a network by

exploiting vulnerabilities in systems.
To prevent the spread of worms, it is crucial to detect and contain
them early.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 15 / 88

Network-Based Prevention

Worms are malicious programs that propagate through a network by

exploiting vulnerabilities in systems.
To prevent the spread of worms, it is crucial to detect and contain
them early.
We use a Susceptible-Infected-Recovered (SIR) model to
mathematically represent the propagation dynamics.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 15 / 88

Network-Based Prevention

Worms are malicious programs that propagate through a network by

exploiting vulnerabilities in systems.
To prevent the spread of worms, it is crucial to detect and contain
them early.
We use a Susceptible-Infected-Recovered (SIR) model to
mathematically represent the propagation dynamics.
The susceptible-infected-Recovered (SIR) model can be applied to
network worm prevention by treating the network as a population and
the worm as an infectious disease.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 15 / 88

Network-Based Prevention

Worms are malicious programs that propagate through a network by

exploiting vulnerabilities in systems.
To prevent the spread of worms, it is crucial to detect and contain
them early.
We use a Susceptible-Infected-Recovered (SIR) model to
mathematically represent the propagation dynamics.
The susceptible-infected-Recovered (SIR) model can be applied to
network worm prevention by treating the network as a population and
the worm as an infectious disease.
The SIR model is a mathematical model used to describe the spread
of infectious diseases.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 15 / 88

Network-Based Prevention

Worms are malicious programs that propagate through a network by

exploiting vulnerabilities in systems.
To prevent the spread of worms, it is crucial to detect and contain
them early.
We use a Susceptible-Infected-Recovered (SIR) model to
mathematically represent the propagation dynamics.
The susceptible-infected-Recovered (SIR) model can be applied to
network worm prevention by treating the network as a population and
the worm as an infectious disease.
The SIR model is a mathematical model used to describe the spread
of infectious diseases.
It divides the population into three compartments: Susceptible (S),
Infected (I), and Recovered (R).

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 15 / 88

Mathematical Modeling of Network Traffic

Let:
N : Total number of nodes (hosts) in the network.
t: Time variable (continuous time).
S(t): Number of susceptible nodes at time t.
I(t): Number of infected nodes at time t.
R(t): Number of removed (recovered) nodes at time t.
λ: Infection rate (worm spread rate from infected to susceptible nodes).
δ: Recovery rate (rate at which infected nodes are removed).

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 16 / 88

Differential Equations for Worm Propagation

SIR Model Equations

dS(t)
= −λS(t)I(t) (1)
dt
dI(t)
= λS(t)I(t) − δI(t) (2)
dt
dR(t)
= δI(t) (3)
dt

These equations model the rate of change in susceptible, infected,

and recovered nodes.
The goal is to minimize I(t), the number of infected nodes, over time.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 17 / 88

Prevention Strategy

Monitor network traffic for abnormal patterns indicating worm

propagation.
Use early warning systems to detect rapid increases in I(t).
Isolate infected nodes to prevent further spread:

Isolate Node if I(t) > Threshold (4)

Apply patches to susceptible nodes to reduce λ.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 18 / 88

Numerical Example - Initial Conditions

Consider a network of 1000 computers.

Initial conditions:
S(0) = 990 (Susceptible computers)
I(0) = 10 (Infected computers)
R(0) = 0 (Recovered/Patched computers)
Parameters:
Infection rate β = 0.3
Recovery rate γ = 0.1

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 19 / 88

Mathematical Equations

Change in Susceptible (S):

dS I
= −β · S ·
dt N
Change in Infected (I):

dI I
=β·S· −γ·I
dt N
Change in Recovered (R):

dR
=γ·I
dt

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 20 / 88

Time Step 0 (t = 0)

Initial conditions:
S(0) = 990
I(0) = 10
R(0) = 0

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 21 / 88

Time Step 1 (t = 1)

Change in Susceptible (S):

I(0)
∆S = −β · S(0) ·
N
10
∆S = −0.3 · 990 · = −2.97 ≈ −3
1000
Change in Infected (I):

I(0)
∆I = β · S(0) · − γ · I(0)
N
∆I = 2.97 − 1 = 1.97 ≈ 2
Change in Recovered (R):

∆R = γ · I(0)

∆R = 0.1 · 10 = 1
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 22 / 88
Updated Values at Time Step 1

S(1) = S(0) + ∆S = 990 − 3 = 987

I(1) = I(0) + ∆I = 10 + 2 = 12
R(1) = R(0) + ∆R = 0 + 1 = 1

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 23 / 88

Time Step 2 (t = 2)

Change in Susceptible (S):

12
∆S = −0.3 · 987 · = −3.56 ≈ −4
1000
Change in Infected (I):
12
∆I = 0.3 · 987 · − 0.1 · 12 = 2.36 ≈ 2
1000
Change in Recovered (R):

∆R = 0.1 · 12 = 1.2 ≈ 1

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 24 / 88

Updated Values at Time Step 2

S(2) = S(1) + ∆S = 987 − 4 = 983

I(2) = I(1) + ∆I = 12 + 2 = 14
R(2) = R(1) + ∆R = 1 + 1 = 2

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 25 / 88

Real-Time SIR Model Extension

Real-Time Data Integration:

Continuously collecting data from network monitoring systems.
Monitoring the number of susceptible, infected, and recovered
computers in real-time.
Dynamic Parameter Adjustment:
Adjusting parameters like the infection rate (β) and recovery rate (γ)
based on real-time observations.
Adapting to changing network conditions and worm behavior.
Feedback Mechanisms:
Implementing feedback loops for immediate action based on model
predictions.
Actions include isolating infected computers or updating security
policies.
Prediction and Control:
Using the model to predict future worm propagation trends.
Controlling the spread by applying appropriate security measures.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 26 / 88

Example 2: Initial Setup

Network Size: 1000 computers

Initial Conditions: S(0) = 980, I(0) = 20, R(0) = 0
Infection Rate: β = 0.3
Recovery Rate: γ = 0.1

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 27 / 88

Dynamic Update at t = 1 Minute

Observations indicate increased infection rate.

Updated Infection Rate: β = 0.35
Updated Recovery Rate: γ = 0.1
Calculations:
∆S = −7, ∆I = 5, ∆R = 2
Updated Values: S(1) = 973, I(1) = 25, R(1) = 2

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 28 / 88

Dynamic Update at t = 2 Minutes

Recovery efforts improve, reducing infection rate.

Updated Infection Rate: β = 0.3
Updated Recovery Rate: γ = 0.2
Calculations:
∆S = −7, ∆I = 2, ∆R = 5
Updated Values: S(2) = 966, I(2) = 27, R(2) = 7

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 29 / 88

SIR Model Results

Day (t) S(t) I(t) R(t)

0 980.00 20.00 0.00
1 974.12 24.44 1.44
2 966.99 29.75 3.26
3 958.17 35.88 5.95
4 947.94 42.80 9.26
5 936.56 50.41 13.03
6 924.16 58.63 17.21
7 910.86 67.27 21.87
8 896.70 76.12 27.17
9 881.67 84.92 33.41
10 865.75 93.35 40.90
11 848.88 101.06 49.26
12 830.95 107.64 58.41

Table: SIR model simulation results until S(t) approaches zero

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 30 / 88

Patch Management

Patch Management Process

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 31 / 88

Introduction to Patch Management

Patch management is the process of applying updates to software,

drivers, and firmware to protect against vulnerabilities. Effective patch
management also helps ensure the best operating performance of sys-
tems, boosting productivity.
Patch management involves the process of distributing and applying
updates to software to correct vulnerabilities.
Patches are crucial in preventing worms and other malware from ex-
ploiting known security flaws.
Regular patching helps maintain the integrity, confidentiality, and avail-
ability of systems.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 32 / 88

Importance of Patch Management

Vulnerability Fixes: Patches close security gaps that worms and

malware exploit.
Compliance: Helps organizations meet regulatory requirements (e.g.,
GDPR, HIPAA).
Performance Improvements: Patches can also improve software
stability and performance.
Minimized Downtime: Regular patching can prevent major system
outages due to exploits.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 33 / 88

Comparison of Patch Management Methods for Worm Prevention

Patch Management Performance Advantages Disadvantages Use Case

Method
Automated Patch Manage- High Reduces manual effort, ensures Requires setup and mainte- Large organizations
ment Tools consistency, fast deployment nance; potential deployment of needing consistent
faulty patches patch deployment
Centralized Patch Manage- High Better control, reduced band- Potential single point of failure, Organizations with
ment width usage, efficient manage- complex setup many devices in multi-
ment ple locations
Regular Patch Testing and Medium Reduces patch-related issues, Slower deployment, requires ad- Environments where up-
Validation ensures compatibility and stabil- ditional resources time and stability are
ity critical
Patch Prioritization and Variable Focuses on critical vulnerabili- Less critical patches might be Security-sensitive envi-
Risk Assessment ties, optimized resource use delayed, potential exposure ronments
Patch Management Policy Medium Establishes clear procedures, en- Requires audits and adherence, All organizations, partic-
and Compliance hances accountability, ensures challenging to enforce ularly regulated indus-
regular updates tries
Vulnerability Scanning and High Early detection of vulnerabilities, False positives/negatives, un- Dynamic and evolving
Patch Monitoring ensures patch compliance necessary work or missed threats IT environments
Third-Party Patch Manage- High Comprehensive security cover- Complexity in managing patches Organizations using a
ment age, reduces attack surface for various software vendors wide range of third-
party software
Emergency Patch Deploy- High (criti- Quick response to critical vulner- Potential disruption, high ur- High exposure to zero-
ment Protocol cal) abilities, reduces exposure win- gency requires readiness day vulnerabilities
dow
Cloud-Based Patch Man- High Scalability, remote management, Dependence on internet connec- Remote or geographi-
agement Solutions reduced on-prem infrastructure tivity, potential latency issues cally dispersed infras-
tructure
End-User Awareness and Low (di- Enhances security culture, re- Relies on user participation, in- Any organization aiming
Training rectly) duces risk of delayed updates direct impact on patch perfor- for holistic security
mance

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 34 / 88

Patch Management Methods and Example Tools

Patch Management Method Example Tools

Automated Patch Management Tools Microsoft SCCM, SolarWinds Patch Manager,
Ivanti Patch Management
Centralized Patch Management IBM BigFix, ManageEngine Patch Manager
Plus, Windows Server Update Services (WSUS)
Regular Patch Testing and Validation Qualys Patch Management, GFI LanGuard,
Ivanti Security Controls
Patch Prioritization and Risk Assessment Rapid7 InsightVM, Nessus, Tenable.sc
Patch Management Policy and Compli- Microsoft SCCM, Symantec Endpoint Manage-
ance ment, Qualys Patch Management
Vulnerability Scanning and Patch Moni- Qualys Vulnerability Management, Nessus,
toring OpenVAS
Third-Party Patch Management SolarWinds Patch Manager, GFI LanGuard,
ManageEngine Patch Manager Plus
Emergency Patch Deployment Protocol IBM BigFix, Automox, Symantec Endpoint Man-
agement
Cloud-Based Patch Management Solu- Automox, Qualys Cloud Platform, Microsoft In-
tions tune
End-User
Adarsh Kumar Awareness and Training KnowBe4, Infosec IQ, SANS
Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in FebruarySecurity
21, 2025 Awareness
35 / 88
Scenario Setup

Network Size: 1000 computers

Initial Worm Infection: 10 computers
Patch Availability: A patch is available to fix the vulnerability
Patch Deployment Rate: 50 computers per day from susceptible
computers category
Infection Rate: Each infected computer can infect 2 new computers
per day
Timeframe: Analysis over 10 days

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 36 / 88

Initial Conditions

Susceptible Computers (S): 990

Infected Computers (I): 10
Recovered/Patched Computers (R): 0

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 37 / 88

Day 1: Patch Management and Infection Spread

Infection Spread: I=10 infected computers infect 10x2= 20 new

computers

S = 990 − 20 = 970, I = 10 + 20 = 30

Patch Deployment: 50 computers patched

S = 970 − 50 = 920, R = 0 + 50 = 50

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 38 / 88

Day 2: Patch Management and Infection Spread

Infection Spread: I=30 infected computers infect 30x2= 60 new

computers

S = 920 − 60 = 860, I = 30 + 60 = 90

Patch Deployment: 50 more computers patched

S = 860 − 50 = 810, R = 50 + 50 = 100

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 39 / 88

Day 3: Patch Management and Infection Spread

Infection Spread: I=90 infected computers infect 180 new

computers

S = 810 − 180 = 630, I = 90 + 180 = 270

Patch Deployment: 50 more computers patched

S = 630 − 50 = 580, R = 100 + 50 = 150

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 40 / 88

Day 4: Patch Management and Infection Spread

Infection Spread: 270 infected computers infect 540 new computers

S = 580 − 540 = 40, I = 270 + 540 = 810

Patch Deployment: 50 more computers patched

S = 40 − 50 = −10 (No more susceptible left), R = 150 + 50 = 200

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 41 / 88

Day 5: Patch Management and Infection Spread

Infection Spread: All remaining 40 computers get infected

S = 0, I = 810 + 40 = 850

Patch Deployment: No more susceptible computers left to patch

S = 0, R = 200

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 42 / 88

Analysis of Results

By Day 5, all susceptible computers are either infected or patched.

Total infected computers: 850
Total patched computers: 200
Patch management initially slowed the spread of the worm but was
not enough to prevent widespread infection due to the high infection
rate.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 43 / 88

Example 1: Automated Patch Management Tools

Scenario
An organization with 1,000 computers is at risk of infection from a newly
discovered worm exploiting a zero-day vulnerability in a commonly used
software application.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 44 / 88

Example 1: Automated Patch Management Tools

Scenario
An organization with 1,000 computers is at risk of infection from a newly
discovered worm exploiting a zero-day vulnerability in a commonly used
software application.

Initial Vulnerability: All 1,000 computers are initially vulnerable.

Patch Availability: A patch is released by the software vendor.
Automated Patch Deployment Rate: Using automated tools like
Microsoft SCCM, patches are deployed to 200 computers per hour.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 44 / 88

Example 1: Automated Patch Management Tools

Scenario
An organization with 1,000 computers is at risk of infection from a newly
discovered worm exploiting a zero-day vulnerability in a commonly used
software application.

Initial Vulnerability: All 1,000 computers are initially vulnerable.

Patch Availability: A patch is released by the software vendor.
Automated Patch Deployment Rate: Using automated tools like
Microsoft SCCM, patches are deployed to 200 computers per hour.

Impact
After 1 hour: 200 computers patched, 800 computers still vulnerable.
After 2 hours: 400 computers patched, 600 computers still vulnerable.
After 3 hours: 600 computers patched, 400 computers still vulnerable.
After 5 hours: All 1,000 computers patched, no computers vulnerable.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 44 / 88

Example 2: Centralized Patch Management

Scenario
A multinational organization with 5,000 devices distributed across five locations worldwide faces
a threat from a worm exploiting a known vulnerability in its email client.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 45 / 88

Example 2: Centralized Patch Management

Scenario
A multinational organization with 5,000 devices distributed across five locations worldwide faces
a threat from a worm exploiting a known vulnerability in its email client.

Initial Vulnerability: All 5,000 devices are vulnerable.

Patch Availability: A patch is available and needs to be deployed.
Centralized Patch Deployment Rate: Using tools like IBM BigFix, patches are deployed
to 500 devices per location per hour.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 45 / 88

Example 2: Centralized Patch Management

Scenario
A multinational organization with 5,000 devices distributed across five locations worldwide faces
a threat from a worm exploiting a known vulnerability in its email client.

Initial Vulnerability: All 5,000 devices are vulnerable.

Patch Availability: A patch is available and needs to be deployed.
Centralized Patch Deployment Rate: Using tools like IBM BigFix, patches are deployed
to 500 devices per location per hour.

Calculation
Total Devices Patched per Hour:

500 devices/location × 5 locations = 2, 500 devices/hour

After 1 hour: 2,500 devices patched, 2,500 vulnerable.

After 2 hours: 5,000 devices patched, 0 vulnerable.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 45 / 88

Example 2: Centralized Patch Management

Scenario
A multinational organization with 5,000 devices distributed across five locations worldwide faces
a threat from a worm exploiting a known vulnerability in its email client.

Initial Vulnerability: All 5,000 devices are vulnerable.

Patch Availability: A patch is available and needs to be deployed.
Centralized Patch Deployment Rate: Using tools like IBM BigFix, patches are deployed
to 500 devices per location per hour.

Calculation
Total Devices Patched per Hour:

500 devices/location × 5 locations = 2, 500 devices/hour

After 1 hour: 2,500 devices patched, 2,500 vulnerable.

After 2 hours: 5,000 devices patched, 0 vulnerable.

Outcome
Using centralized patch management, all devices across the organization are patched within 2
hours, minimizing the risk of a worm infection.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 45 / 88

Example 3: Patch Prioritization and Risk Assessment

Scenario
A healthcare organization with 2,000 devices has a critical vulnerability affecting its patient
management software. The organization decides to prioritize patching high-risk devices first.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 46 / 88

Example 3: Patch Prioritization and Risk Assessment

Scenario
A healthcare organization with 2,000 devices has a critical vulnerability affecting its patient
management software. The organization decides to prioritize patching high-risk devices first.

Initial Vulnerability: 2,000 devices are vulnerable.

Patch Deployment Plan:
High-risk devices (e.g., those connected to critical patient systems):
800 devices, patched within 1 day.
Medium-risk devices: 700 devices, patched within 2 days.
Low-risk devices: 500 devices, patched within 3 days.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 46 / 88

Example 3: Patch Prioritization and Risk Assessment

Scenario
A healthcare organization with 2,000 devices has a critical vulnerability affecting its patient
management software. The organization decides to prioritize patching high-risk devices first.

Initial Vulnerability: 2,000 devices are vulnerable.

Patch Deployment Plan:
High-risk devices (e.g., those connected to critical patient systems):
800 devices, patched within 1 day.
Medium-risk devices: 700 devices, patched within 2 days.
Low-risk devices: 500 devices, patched within 3 days.
Calculation
Day 1: 800 high-risk devices patched, 1,200 devices remain vulnerable.
Day 2: Additional 700 medium-risk devices patched, 500 devices remain vulnerable.
Day 3: All 500 low-risk devices patched, 0 devices remain vulnerable.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 46 / 88

Example 3: Patch Prioritization and Risk Assessment

Scenario
A healthcare organization with 2,000 devices has a critical vulnerability affecting its patient
management software. The organization decides to prioritize patching high-risk devices first.

Initial Vulnerability: 2,000 devices are vulnerable.

Patch Deployment Plan:
High-risk devices (e.g., those connected to critical patient systems):
800 devices, patched within 1 day.
Medium-risk devices: 700 devices, patched within 2 days.
Low-risk devices: 500 devices, patched within 3 days.
Calculation
Day 1: 800 high-risk devices patched, 1,200 devices remain vulnerable.
Day 2: Additional 700 medium-risk devices patched, 500 devices remain vulnerable.
Day 3: All 500 low-risk devices patched, 0 devices remain vulnerable.

Outcome
By prioritizing patch deployment based on risk, the healthcare organization reduces the risk of a
worm infection impacting critical systems within 24 hours while fully securing all devices within
3 days.
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 46 / 88
Example 4: Emergency Patch Deployment Protocol

Scenario
A financial institution with 10,000 endpoints detects a worm exploiting a
zero-day vulnerability. An emergency patch deployment is initiated.

Initial Vulnerability: All 10,000 endpoints are vulnerable.

Emergency Deployment Rate: Using emergency protocols and
tools like Automox, patches are deployed to 1,000 endpoints per hour.
Calculation
After 1 hour: 1,000 endpoints patched, 9,000 vulnerable.
After 5 hours: 5,000 endpoints patched, 5,000 vulnerable.
After 10 hours: 10,000 endpoints patched, 0 vulnerable.

Outcome
The emergency patch deployment protocol patches all endpoints within 10
hours, drastically reducing the potential impact of the worm.
Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 47 / 88
Example 5: Cloud-Based Patch Management Solutions

Scenario
A tech company with a distributed workforce (remote) has 3,000 devices connected via the
cloud. A critical security patch is required for a newly identified worm threat.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 48 / 88

Example 5: Cloud-Based Patch Management Solutions

Scenario
A tech company with a distributed workforce (remote) has 3,000 devices connected via the
cloud. A critical security patch is required for a newly identified worm threat.

Initial Vulnerability: All 3,000 devices are vulnerable.

Patch Deployment via Cloud Management: Using a cloud-based solution like Microsoft
Intune, patches are pushed remotely.
Deployment Rate: 500 devices per hour.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 48 / 88

Example 5: Cloud-Based Patch Management Solutions

Scenario
A tech company with a distributed workforce (remote) has 3,000 devices connected via the
cloud. A critical security patch is required for a newly identified worm threat.

Initial Vulnerability: All 3,000 devices are vulnerable.

Patch Deployment via Cloud Management: Using a cloud-based solution like Microsoft
Intune, patches are pushed remotely.
Deployment Rate: 500 devices per hour.

Calculation
After 1 hour: 500 devices patched, 2,500 vulnerable.
After 3 hours: 1,500 devices patched, 1,500 vulnerable.
After 6 hours: 3,000 devices patched, 0 vulnerable.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 48 / 88

Example 5: Cloud-Based Patch Management Solutions

Scenario
A tech company with a distributed workforce (remote) has 3,000 devices connected via the
cloud. A critical security patch is required for a newly identified worm threat.

Initial Vulnerability: All 3,000 devices are vulnerable.

Patch Deployment via Cloud Management: Using a cloud-based solution like Microsoft
Intune, patches are pushed remotely.
Deployment Rate: 500 devices per hour.

Calculation
After 1 hour: 500 devices patched, 2,500 vulnerable.
After 3 hours: 1,500 devices patched, 1,500 vulnerable.
After 6 hours: 3,000 devices patched, 0 vulnerable.

Outcome
The cloud-based patch management system ensures that all remote devices are patched within 6
hours, providing effective and quick mitigation against the worm threat.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 48 / 88

Example 6: Third-Party Patch Management

Scenario
Initial Vulnerability: 2,000 workstations are potentially vulnerable to worm infections due to
outdated third-party applications. Patch Deployment Rate: ManageEngine Patch Manager
Plus can patch 200 workstations per hour. Patching Schedule: Patches are applied overnight to
minimize disruption.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 49 / 88

Example 6: Third-Party Patch Management

Scenario
Initial Vulnerability: 2,000 workstations are potentially vulnerable to worm infections due to
outdated third-party applications. Patch Deployment Rate: ManageEngine Patch Manager
Plus can patch 200 workstations per hour. Patching Schedule: Patches are applied overnight to
minimize disruption.

Calculation
After 1 hour: 200 workstations patched, 1,800 vulnerable.
After 5 hours: 1,000 workstations patched, 1,000 vulnerable.
After 10 hours: 2,000 workstations patched, 0 vulnerable.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 49 / 88

Example 6: Third-Party Patch Management

Scenario
Initial Vulnerability: 2,000 workstations are potentially vulnerable to worm infections due to
outdated third-party applications. Patch Deployment Rate: ManageEngine Patch Manager
Plus can patch 200 workstations per hour. Patching Schedule: Patches are applied overnight to
minimize disruption.

Calculation
After 1 hour: 200 workstations patched, 1,800 vulnerable.
After 5 hours: 1,000 workstations patched, 1,000 vulnerable.
After 10 hours: 2,000 workstations patched, 0 vulnerable.

Outcome
By using ManageEngine Patch Manager Plus, the company can ensure that all third-party
applications across its 2,000 workstations are patched within 10 hours, reducing the risk of worm
infections exploiting known vulnerabilities.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 49 / 88

Key Insights

Patch Deployment Rate: Must match or exceed infection rate to

control worm spread.
Infection Rate: High infection rates lead to exponential growth;
quick response is critical.
Early Patch Deployment: Patching early can significantly reduce
infection spread.
Dynamic Response: Real-time monitoring and adaptive patching
strategies can improve worm prevention.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 50 / 88

Patch Management Lifecycle

1 Detection: Identify vulnerabilities and available patches.

2 Assessment: Evaluate the relevance and impact of patches.
3 Prioritization: Prioritize patches based on severity and potential risk.
4 Deployment: Apply patches to systems in a controlled manner.
5 Verification: Ensure patches are applied correctly and monitor for
issues.
6 Documentation: Record patching activities for future reference and
compliance.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 51 / 88

Patch Management Algorithm

Algorithm Steps
Input: List of vulnerabilities V = {v1 , v2 , . . . , vn }, Patch database
P = {p1 , p2 , . . . , pm }.
Output: Successfully patched systems.
1 Initialization: Set S = ∅, where S is the set of patched systems.
2 For each vulnerability vi in V :
Find corresponding patch pj in P such that pj addresses vi .
If pj is not already applied:
Apply pj to affected systems.
Add affected systems to S.
3 End For
4 Verification: Check that all systems in S have been patched
correctly.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 52 / 88

Examples of Patches for Worm Prevention

MS17-010 (EternalBlue):
Released by Microsoft in March 2017.
Addressed vulnerabilities in the SMBv1 protocol exploited by the WannaCry ransomware worm.
Importance: Prevented the spread of WannaCry, which affected over 200,000 computers worldwide, by patching
the exploit.

MS08-067 (Conficker Worm):

Released by Microsoft in October 2008.
Fixed a vulnerability in the Windows Server service used by the Conficker worm to spread.
Importance: Essential in mitigating the spread of Conficker, one of the most widespread network worms,
affecting millions of systems globally.

MS04-011 (Sasser Worm):

Released by Microsoft in April 2004.
Addressed a vulnerability in the Local Security Authority Subsystem Service (LSASS) exploited by the Sasser
worm.
Importance: Helped prevent the Sasser worm from infecting millions of computers by exploiting the LSASS
vulnerability, causing widespread network disruptions.

MS03-026 (Blaster Worm):

Released by Microsoft in July 2003.
Addressed a critical vulnerability in the Windows DCOM RPC interface exploited by the Blaster worm.
Importance: Critical in stopping the spread of the Blaster worm, which affected hundreds of thousands of
computers, causing network congestion and system reboots.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 53 / 88

Best Practices in Patch Management

Best Practices:
Regularly scan systems for vulnerabilities.
Test patches in a non-production environment before deployment.
Automate the patching process where possible to ensure consistency.
Keep a backup before applying critical patches.
Educate users about the importance of security updates.
Advantages:
Patch management is a critical component of cybersecurity.
A well-defined patch management process helps in mitigating the
risks posed by worms and other malware.
Regular updates and adherence to best practices ensure the security
and reliability of systems.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 54 / 88

Introduction to Access Control Management

Access control determines who is allowed to access or modify

information in a system.
It is a critical component of cybersecurity, preventing unauthorized
access.
Helps in reducing the spread of worms by limiting access based on
user roles and permissions.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 55 / 88

Importance of Access Control in Worm Prevention

Minimizes Attack Surface

Restricting access to sensitive parts of the system reduces the number of potential entry points
for worms, minimizing the overall attack surface.

Ensures Accountability
Access control mechanisms often include logging and monitoring features that track user
activities, helping to quickly identify and isolate compromised accounts.

Enforces Least Privilege Principle

Ensures that users and applications have only the minimal access necessary to perform their
tasks, limiting the ability of worms to exploit privileges to spread across systems.

Segmentation of Network Resources

Access control can segment network resources, creating isolated environments where worms
cannot easily propagate across different segments of the network.

Supports Incident Response

Access control can be used to quickly revoke or modify access rights during a worm infection,
helping to contain and mitigate the impact.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 56 / 88

Types of Access Control Models

Discretionary Access Control (DAC):

Access is based on the identity of users and groups.
Each resource has an Access Control List (ACL) specifying which users
can access it.
Mandatory Access Control (MAC):
Access decisions are based on predefined policies and security labels.
Typically used in government and military applications.
Role-Based Access Control (RBAC):
Access is granted based on user roles within an organization.
Simplifies management by assigning permissions to roles rather than
individuals.
Attribute-Based Access Control (ABAC):
Access is determined by evaluating attributes (e.g., user attributes,
resource attributes).
Offers flexibility and fine-grained access control.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 57 / 88

Access Control Algorithm for Worm Prevention

Algorithm Steps
Input: User request R, Access Control Policy P , User attributes U ,
Resource attributes Res.
Output: Access granted or denied.
1 Step 1: Validate the user identity U and resource Res.
2 Step 2: Check the access control policy P for user role R and
corresponding permissions.
3 Step 3: Evaluate conditions based on attributes (ABAC model):

If (U.role = P.role) ∧ (Res.type = P.resource type) ⇒ Grant Access

4 Step 4: Log the access request and outcome.

5 Step 5: If access is denied, alert the system administrator.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 58 / 88

Scenario Setup

User Request (R): Alice attempts to access a critical server.

User Attributes (U):
Name: Alice
Role: System Administrator
Department: IT
Resource Attributes (Res):
Resource Name: critical server 01
Resource Type: Critical Server
Department: IT
Access Control Policy (P):
Role required: System Administrator
Resource type: Critical Server
Department: IT
Permissions: Read, Write, Execute

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 59 / 88

Algorithm Execution

Step-by-Step Execution
1 Validate User and Resource: Alice and critical server 01 are valid.
2 Check Access Control Policy:
Alice’s Role: System Administrator (Matches)
Resource Type: Critical Server (Matches)
Department: IT (Matches)
3 Evaluate Conditions:

(U.role = P.role) ∧ (Res.type = P.resource type) ∧ (U.department = P.department) ⇒ Grant Access

4 Log Outcome: ”Access request by Alice to critical server 01 granted.”

5 Alert: Not required, access was granted.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 60 / 88

Result

Access granted to Alice for read, write, and execute operations on

critical server 01.
Access request and outcome are logged for audit purposes.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 61 / 88

Access Control Algorithm Example

Example Scenario
User Request: Alice requests access to the financial report R.
Access Control Policy: Policy P requires that only users with the role ”Manager” can access financial reports.
User Attributes: Alice’s role U.role = ”Manager”.
Resource Attributes: The resource type Res.type = ”Financial Report”.
Output: Access granted.

1 Step 1: Validate Alice’s identity U and the requested resource Res.

2 Step 2: Check the access control policy P for Alice’s role U.role = ”Manager” and corresponding permissions.
3 Step 3: Evaluate the following condition:

If (U.role = ”Manager”) ∧ (Res.type = ”Financial Report”) ⇒ Grant Access

Since Alice’s role is ”Manager” and the resource type is ”Financial Report”, the condition is true.
4 Step 4: Log Alice’s access request and the outcome (Access granted).
5 Step 5: No alert is necessary as access is granted.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 62 / 88

Detailed ABAC Algorithm for Worm Prevention

Algorithm Steps
Input: User request R, ABAC Policy Pabac , User attributes U , Resource attributes Res.
Output: Access granted or denied.

1 Step 1: Extract attributes: {U.role, U.department, U.security level, . . .} and {Res.type, Res.sensitivity level, . . .}.
2 Step 2: Match user attributes against policy:

If (U.department = Pabac .department) ∧ (U.security level ≥ Res.sensitivity level) ⇒ Grant Access

3 Step 3: Evaluate any additional conditions defined in Pabac :

If ∀i (U.attributei = Pabac .attributei ) ⇒ Grant Access

4 Step 4: Log access request and decision.

5 Step 5: If denied, notify security monitoring system.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 63 / 88

Scenario Setup

User Request (R): Bob attempts to access a confidential file.

User Attributes (U):
Name: Bob
Role: Manager
Department: IT
Security Level: 6
Resource Attributes (Res):
Resource Name: confidential file.txt
Resource Type: File
Sensitivity Level: 5
Location: Internal Server
ABAC Policy (Pabac ):
Required Department: IT
Minimum Security Level: 5
Additional Condition: User role must be Manager or above

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 64 / 88

Algorithm Execution

Step-by-Step Execution
1 Extract Attributes:

U = {Manager, IT, 6}, Res = {File, 5}

2 Match User Attributes Against Policy:

U.department = Pabac .department (IT matches IT)

U.security level ≥ Res.sensitivity level (6 ≥ 5)

3 Evaluate Additional Conditions:

User role = Manager ≥ Manager (Condition met)

4 Log Outcome: ”Access request by Bob for confidential file.txt was granted.”
5 Notify if Denied: Not required, access was granted.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 65 / 88

Result

Access is granted to Bob for the confidential file.

The access request and outcome are logged.
No notification sent to the security monitoring system.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 66 / 88

Detailed ABAC Algorithm Example

Example Scenario
User Request: Bob requests access to a classified project file R.
ABAC Policy: Policy Pabac requires that the user must be in the ”Research” department and have a security level of 5
or higher to access classified project files.

User Attributes:
U.role = ”Researcher”
U.department = ”Research”
U.security level = 5

Resource Attributes:
Res.type = ”Classified Project File”
Res.sensitivity level = 4
Output: Access granted.

1 Step 1: Extract attributes:

{U.role = ”Researcher”, U.department = ”Research”, U.security level = 5}

{Res.type = ”Classified Project File”, Res.sensitivity level = 4}

2 Step 2: Match user attributes against policy:

If (U.department = Pabac .department = ”Research”)

∧ (U.security level = 5 ≥ Res.sensitivity level = 4)
⇒ Grant Access

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 67 / 88

Detailed ABAC Algorithm Example

Example Scenario
3 Step 3: Evaluate any additional conditions defined in Pabac :

No additional conditions apply, so Grant Access

4 Step 4: Log Bob’s access request and the decision (Access granted).
5 Step 5: Since access is granted, no notification to the security monitoring system is needed.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 68 / 88

Detailed RBAC Algorithm for Worm Prevention

Algorithm Steps
Input: User role U.role, RBAC Policy Prbac .
Output: Access granted or denied.
1 Step 1: Identify user’s role U.role.
2 Step 2: Retrieve permissions associated with U.role from Prbac .
3 Step 3: Check if the requested action is within the permissions:

If R.action ∈ Prbac .permissions ⇒ Grant Access

4 Step 4: Log the access request and outcome.

5 Step 5: If access is denied, generate a security incident report.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 69 / 88

Detailed RBAC Algorithm Example

Example Scenario
User Role: John is assigned the role of ”Network Administrator” U.role = ”Network Admin”.
RBAC Policy: The RBAC Policy Prbac specifies that the ”Network Admin” role has permissions to ”Monitor Traffic”
and ”Configure Routers.”
Output: Access granted or denied based on John’s role and the requested action.

1 Step 1: Identify John’s role U.role = ”Network Admin”.

2 Step 2: Retrieve permissions associated with the ”Network Admin” role from Prbac .
Permissions retrieved: ”Monitor Traffic,” ”Configure Routers.”
3 Step 3: Check if the requested action is within the permissions:

Requested action: ”Monitor Traffic”

If R.action = ”Monitor Traffic” ∈ Prbac .permissions ⇒ Grant Access

Since ”Monitor Traffic” is within the permissions, access is granted.

4 Step 4: Log the access request and outcome (Access granted).
5 Step 5: No security incident report is generated as access is granted.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 70 / 88

Detailed DAC Algorithm for Worm Prevention

Algorithm Steps
Input: User U , Resource Res, DAC Policy Pdac .
Output: Access granted or denied.

1 Step 1: Check if user U is the owner of the resource Res.

2 Step 2: Evaluate access rights from Pdac :

If (U = Res.owner) ∨ (U.role = admin) ⇒ Grant Access

3 Step 3: If no explicit permission is found, deny access.

4 Step 4: Log the access request and outcome.
5 Step 5: If denied, escalate to owner review.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 71 / 88

Detailed DAC Algorithm Example

Example Scenario
User: Alice requests access to a proprietary design document Res.
Resource Owner: The document is owned by Bob Res.owner = ”Bob”.
DAC Policy: The policy Pdac specifies that access is granted if the user is the owner or an admin.
Output: Access granted or denied.

1 Step 1: Check if Alice U is the owner of the resource Res:

U = ”Alice”
Res.owner = ”Bob”
Alice is not the owner.
2 Step 2: Evaluate access rights from Pdac :

If (U = ”Alice” ̸= ”Bob”) ∨ (U.role = admin)

⇒ Grant Access

Since Alice is neither the owner nor an admin, access is denied.

3 Step 3: No explicit permission is found for Alice. Access is denied.
4 Step 4: Log Alice’s access request and the outcome (Access denied).
5 Step 5: Since access is denied, escalate the request to the resource owner, Bob, for review.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 72 / 88

Best Practices for Implementing Access Control

Regularly update access control policies to adapt to new threats.

Use the principle of least privilege: grant minimum necessary
permissions.
Implement multi-factor authentication (MFA) for sensitive operations.
Conduct periodic audits and reviews of access control settings.
Educate users about the importance of secure access practices.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 73 / 88

Important Notes

Effective access control is essential to prevent unauthorized access

and reduce worm propagation.
Different models (DAC, MAC, RBAC, ABAC) offer varying levels of
control and flexibility.
Implementing best practices ensures the security and integrity of
sensitive information.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 74 / 88

Network Segmentation for Worm Prevention

Overview
Network segmentation involves dividing a network into smaller, isolated segments to limit the spread of worms and other
malicious activities. This approach enhances security by controlling traffic flow and reducing the attack surface.

Algorithm Steps
Input: Network topology N , Segmentation policy S, Traffic rules T , Security requirements R.
Output: Segmented network with defined security zones.

1 Step 1: Analyze the network topology N .

Identify all network nodes, devices, and connections.

N = {Node1 , Node2 , . . . , Noden }

2 Step 2: Define segmentation policy S.

Determine the criteria for segmenting the network, such as based on departments, functions, or sensitivity of
data.

S = {Segment1 , Segment2 , . . . , Segmentk }

3 Step 3: Implement traffic rules T between segments.

Define access controls and communication rules for traffic between segments.
(
Allowed if Segmenti and Segmentj are permitted to communicate
Tij =
Denied otherwise

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 75 / 88

Network Segmentation for Worm Prevention

Overview
1 Step 4: Apply security controls R within each segment.
Implement security measures such as firewalls, intrusion detection systems, and access controls tailored to each
segment’s requirements.

R = {Firewall Rules, IDS, Access Controls}

2 Step 5: Monitor and maintain segmented network.

Continuously monitor traffic and enforce policies to ensure the effectiveness of segmentation.

Monitor(N, S, T, R)

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 76 / 88

Network Segmentation for Worm Prevention

Example Scenario
A company implements network segmentation to prevent the spread of a
worm infection. The network is divided into four segments:
Development
Marketing
Finance
HR

The aim is to contain any worm infection within a single segment and
prevent it from spreading to others.

Implementation Steps
Input: Network topology N , Segmentation policy S, Traffic rules T , Security controls C.
Output: Secured and isolated network segments.

1 Step 1: Segment the network N .

Define segments based on departments.

N = {Dev, Mkt, Fin, HR}

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 77 / 88

Network Segmentation for Worm Prevention

Implementation Steps
1 Step 2: Define access rules T between segments.
Control which segments can communicate with each other.
(
Allowed if Segmenti and Segmentj are permitted to communicate
Tij =
Denied otherwise

Example:
TDev, Mkt = Allowed, TDev, Fin = Denied

2 Step 3: Implement security controls C for each segment.

Apply firewalls, IDS, and access controls.

C = {Firewall for Dev, IDS for Mkt, Access Controls for HR}

3 Step 4: Monitor traffic between segments.

Track and analyze traffic to detect any anomalies or attempts to breach segmentation.

Monitor(N, T, C)

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 78 / 88

Network Segmentation for Worm Prevention

Numerical Example
Consider a network with the following topology and segmentation policy:
Network Topology N :
N = {A, B, C, D, E}

Segmentation Policy S:

S = {Segment1 = {A, B}, Segment2 = {C}, Segment3 = {D, E}}

Traffic Rules T :

(
Allowed if Segmenti and Segmentj are permitted to communicate
Tij =
Denied otherwise

For example:
T12 = Allowed, T13 = Denied, T23 = Allowed, T24 = Denied

Security Controls R:
R = {Firewalls, IDS, Access Controls}

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 79 / 88

Network Segmentation for Worm Prevention

Numerical Example (continued)

Applying the policy and rules:
For Segment 1 (Nodes A, B):

Traffic Rules: T12 = Allowed, Firewalls:Allow internal segment communication.

For Segment 2 (Node C):

Traffic Rules: T13 = Denied, IDS: Monitor traffic to/from Segments 1 and 3.

For Segment 3 (Nodes D, E):

Traffic Rules: T24 = Denied, Access Controls: Restrict external access to segment.

Monitoring:
Monitor(N, S, T, R) = Evaluate effectiveness of segmentation and security controls.

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 80 / 88

Least Privilege Principle for Worm Prevention

Overview
The Least Privilege Principle dictates that users and systems should be granted the minimum level of access necessary to
perform their functions. This principle helps to limit the spread of worms and other malicious threats by minimizing the
potential damage that can be caused by compromised accounts or systems.

Implementation Steps
Input: User roles R, Resource access requirements A, Security policy P , Current access levels C.
Output: Restricted access permissions.

1 Step 1: Identify user roles R and their required access levels.

Define roles based on job functions and responsibilities.

R = {Role1 , Role2 , . . . , Rolek }

2 Step 2: Assess access requirements A for each role.

Determine the minimum access needed for each role to perform its duties.

Ai = {Resource1 , Resource2 , . . . , Resourcem }

3 Step 3: Define security policy P based on least privilege.

Implement access controls to enforce the least privilege principle.
(
Allowed if Rolei requires access to Resourcej
Pij =
Denied otherwise

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 81 / 88

Least Privilege Principle for Worm Prevention

Implementation Steps
5 Step 4: Review and adjust current access levels C.
Audit existing permissions and adjust to align with the least privilege policy.

Ci = {Access1 , Access2 , . . . , Accessn }

6 Step 5: Monitor and enforce compliance with the least privilege policy.
Continuously review access levels and adjust as necessary to maintain minimal access.

Monitor(R, A, C, P )

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 82 / 88

Example: Least Privilege Principle for Worm Prevention

Implementation Steps

Input: User roles R, Resource access requirements A, Security policy P , Current access levels C.
Output: Restricted access permissions.
1 Step 1: Identify user roles R and their required access levels.
Define roles based on job functions and responsibilities.

R = {Admin, Developer, Analyst}

2 Step 2: Assess access requirements A for each role.

Determine the minimum access needed for each role to perform its duties.

AAdmin = {Database, Server, Configuration}

ADeveloper = {Source Code, Development Environment}

AAnalyst = {Reports, Analytics Tools}

3 Step 3: Define security policy P based on least privilege.

Implement access controls to enforce the least privilege principle.

PAdmin, Database = Allowed

PDeveloper, Database = Denied

PAnalyst, Reports = Allowed

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 83 / 88

Least Privilege Principle for Worm Prevention

Implementation Steps
5 Step 4: Review and adjust current access levels C.
Audit existing permissions and adjust to align with the least privilege policy.

CAdmin = {Database, Server, Configuration}

CDeveloper = {Source Code, Development Environment}

CAnalyst = {Reports, Analytics Tools}

6 Step 5: Monitor and enforce compliance with the least privilege policy.
Continuously review access levels and adjust as necessary to maintain minimal access.

Monitor(R, A, C, P ) → Regularly review and update access permissions

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 84 / 88

Example : Least Privilege Principle for Worm Prevention

Implementation Steps
Input: User roles R, Resource access requirements A, Security policy P , Current access levels C.
Output: Restricted access permissions.

1 Step 1: Identify user roles R and their required access levels.

Define roles based on job functions and responsibilities.

R = {Admin, Developer, Analyst}

Example Roles and Responsibilities:

Admin: Full access to system configuration and databases
Developer: Access to source code and development tools
Analyst: Access to reports and analytical tools
2 Step 2: Assess access requirements A for each role.
Determine the minimum access needed for each role.

AAdmin = {Database, Server, Configuration}

ADeveloper = {Source Code, Development Environment}

AAnalyst = {Reports, Analytics Tools}

Example Access Requirements:

Admin: Required access to all critical resources
Developer: Required access to only development-related resources
Analyst: Required access to only report-related resources

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 85 / 88

Example : Least Privilege Principle for Worm Prevention

Implementation Steps
3 Step 3: Define security policy P based on least privilege.
Implement access controls to enforce the least privilege principle.

PAdmin, Database = Allowed

PDeveloper, Database = Denied

PAnalyst, Reports = Allowed

Example Policy Rules:

Admin can access all critical resources
Developer cannot access the database or server configurations
Analyst can access only the reports

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 86 / 88

Example : Least Privilege Principle for Worm Prevention

Implementation Steps
4 Step 4: Review and adjust current access levels C.
Audit existing permissions and adjust to align with the least privilege policy.

CAdmin = {Database, Server, Configuration}

CDeveloper = {Source Code, Development Environment}

CAnalyst = {Reports, Analytics Tools}

Example Current Access Levels:

Admin: Access to all resources as required
Developer: Access to development-related resources only
Analyst: Access to report-related resources only

5 Step 5: Monitor and enforce compliance with the least privilege policy.
Continuously review access levels and adjust as necessary to maintain minimal access.

Monitor(R, A, C, P ) → Regularly review and update access permissions

Example Monitoring Actions:

Perform regular audits of access permissions
Update permissions based on changes in job roles or responsibilities

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 87 / 88

Thank You

Thank You!

For your attention and participation

Adarsh Kumar Adarsh[dot]Kumar[at]ddn[dot]upes[dot]ac[dot]in February 21, 2025 88 / 88