TimeSheets:

Threat Report

T Gopi
06 June 2024
Purpose of this Report:

This is a threat model report for TimeSheets. The report will

describe the threats facing TimeSheets. The model will cover the
following:
● Threat Assessment
○ Scoping out Asset Inventory
○ Architecture Audit
○ Threat Model Diagram
○ Threats to the Organization
○ Identifying Threat Actors
● Vulnerability Analysis
● Risk Analysis
● Mitigation Plan

Remove this slide

 Section 1
Initial Threat
Assessment
Completed Asset Inventory
Components and Functions

● TimeSheets Web Server: The web server's primary role is

to serve static content to a requesting client through the

http protocol.

● TimeSheets Application Server: The application server

handles all the business logic process and serves dynamic

content.

● TimeSheetsDB: The database server stores employee data

and will be queried from the application server.

● AuthDB: Stores user authentication data (credentials) and

will be queried from the application server.

Remove this slide

Completed Asset Inventory
Overview of Application Functionality

TimeSheets is used by employees to track their hours worked.

Users will login to the TimeSheets application from their device.

Data Flow

Request is generated from the client via the Internet. The request
arrives at the TimeSheets web server which serves static content
to the user (HTML, images, etc). Dynamic data is retrieved from
the database and served to the client.
Completed Architecture Audit
Flaws

● There is a lack of encryption at rest - database servers are

storing data on unencrypted disks.

● There is lack of redundancy.

● There is no firewall that is filtering traffic coming from the

Internet
Completed Threat Model

● Employee Data Unencrypted at Rest

● Authentication data is using reversible encryption

● Authentication requests are not encrypted in transit

● Sensitive data is encrypted using DES algorithm

Completed Threat Analysis
What Type of Attack Caused the Login Alerts?

Man in the Middle (MitM)

What Proves Your Theory?

There is lack of encryption between the client and the

application. A malicious actor is sniffing traffic and intercepting
the requests with a valid username/password in the request.
Additionally, the logs show successful login attempts from the
expected IP, but also a different location at the same time.
Completed Threat Actor Analysis

Who is the Most Likely Threat Actor?

Internal User

What Proves Your Theory?

The IP address of the unexpected login matches that of an

internal user. Additionally, there was no data leaked from the
company, and no data changed. Just data accessed that the
legitimate user typically doesn’t access.
 Section 2
Vulnerability Analysis
2.1 Employee Data
Unencrypted at Rest
Discovery:

During the threat model the SRE team confirmed that the
database is on a server that does not have encryption at rest.

Why is this an issue?

Having a database on a server that does not have encryption at

rest is a significant security concern for several reasons:

Data Breach Risk: Without encryption at rest, if an attacker gains

physical or administrative access to the server, they can easily
access the raw data stored in the database. This could lead to
unauthorized access to sensitive information, such as personal
data, financial records, or intellectual property.

Compliance Issues: Many industries are subject to regulations

and standards that require encryption of sensitive data at rest.
Examples include GDPR (General Data Protection Regulation) in
Europe, HIPAA (Health Insurance Portability and Accountability
Act) in the United States, and PCI-DSS (Payment Card Industry
Data Security Standard) for companies handling credit card
information. Failure to comply with these regulations can result
in heavy fines and legal consequences.
Mitigating Data Theft: Encryption at rest protects data even if
physical security measures are compromised. If hard drives or other
storage media are stolen, the data remains encrypted and
unreadable without the appropriate decryption keys.

Data Integrity and Confidentiality: Encryption ensures that the data

remains confidential and maintains its integrity. It prevents
unauthorized users from reading or tampering with the data, thus
ensuring that only authorized personnel can access and modify the
information.

Reducing Risk of Internal Threats: Even within an organization, not all

personnel should have access to sensitive data. Encryption at rest
adds an additional layer of security, reducing the risk of internal
threats from employees who might have access to the physical
server but should not have access to the data itself.

Trust and Reputation: Protecting data with encryption at rest helps

maintain the trust of customers, partners, and stakeholders. Data
breaches can severely damage an organization’s reputation, leading
to loss of business and credibility.

To mitigate these risks, it is recommended to implement encryption

at rest on all servers hosting databases containing sensitive
information. This ensures that data remains secure and compliant
with relevant regulations and industry standards.
2.2 Authentication Data
Stored Using Reversible
Encryption
Discovery:

During the threat model the DBA team confirmed that the
database is storing authentication data (credentials) encrypted.

Why is this an issue?

Storing authentication data (credentials) using reversible

encryption is a significant security issue for several reasons:

Increased Risk of Credential Theft : Reversible encryption means

that the encrypted data can be decrypted back to its original
form. If an attacker gains access to the encryption keys or
exploits a vulnerability in the system, they can decrypt the
credentials and gain unauthorized access to user accounts and
systems.

Non-Compliance with Security Best Practices : Security best

practices and standards, such as those recommended by NIST
and OWASP (Open Web Application Security Project), advocate
for hashing credentials instead of using reversible encryption.
Hashing is a one-way function, meaning it cannot be easily
reversed, which enhances security.
Exposure to Insider Threats : Even authorized personnel with access
to the encryption keys can potentially misuse their access to decrypt
and steal credentials. Hashing credentials minimizes this risk, as
even authorized users cannot reverse the hash to obtain the original
password.

Higher Vulnerability to Data Breaches : In the event of a data breach,

if credentials are stored using reversible encryption, attackers can
decrypt and use the credentials. This can lead to further
exploitation, including privilege escalation and lateral movement
within the network. Hashing, on the other hand, ensures that even if
hashes are stolen, they cannot be easily reversed to obtain the
original passwords.

Weakness Against Brute Force Attacks : If reversible encryption is

used, the encryption keys can become a target for brute force
attacks. If the encryption algorithm or implementation has
weaknesses, attackers can potentially break the encryption and
access the credentials. With proper hashing algorithms (such as
bcrypt, scrypt, or Argon2), the process is computationally expensive,
making brute force attacks less feasible.

Regulatory and Compliance Issues : Many regulatory frameworks

and industry standards require secure storage of authentication
data. Storing credentials using reversible encryption may not meet
these requirements, leading to potential legal and financial
repercussions.
2.3 Authentication Requests
are Unencrypted in Transit
Discovery:

During the threat model the security team confirmed that

authentication requests are being transmitted in plaintext.

Why is this an issue?

Eavesdropping and Interception : Plaintext transmission means

that anyone who can intercept the communication can read the
authentication data, including usernames and passwords.
Attackers can use various techniques, such as packet sniffing or
man-in-the-middle (MITM) attacks, to capture this information.

Credential Theft : If authentication data is intercepted, attackers

can use the captured credentials to gain unauthorized access to
user accounts and systems. This can lead to further exploitation,
including accessing sensitive data, executing transactions, and
escalating privileges within the network.

Replay Attacks : In a replay attack, an attacker intercepts the

authentication request and resends it to the server to gain
unauthorized access. Without encryption, there is no way to
prevent or detect such attacks.
Data Integrity Compromise : Without encryption, there is no
guarantee that the data has not been tampered with during
transmission. Attackers could alter the authentication data in transit,
potentially gaining unauthorized access or causing disruptions.

Non-Compliance with Security Standards : Many industry standards

and regulations, such as GDPR, HIPAA, and PCI-DSS, require the
encryption of sensitive data in transit. Transmitting authentication
data in plaintext violates these standards, leading to potential legal
and financial repercussions.

Trust and Reputation Damage : If a security breach occurs due to

plaintext transmission of authentication data, it can severely damage
the trust and reputation of the organization. Users expect their
credentials to be handled securely, and any compromise can lead to
loss of business and credibility.
2.DES Algorithm in Use
Discovery:

During the threat model the security team identified sensitive

data being stored using the DES algorithm.

Why is this an issue?

DES uses a 56-bit key, which is considered very weak by modern

cryptographic standards. This limited key length makes DES
susceptible to brute-force attacks, where an attacker
systematically tries all possible keys until the correct one is
found. Given the current computational power available, brute-
forcing DES keys is feasible in a relatively short amount of time.

Many industry regulations and standards, such as PCI-DSS, NIST,

and GDPR, mandate the use of strong encryption methods to
protect sensitive data. DES does not meet the current
requirements set by these regulations, and using it can lead to
non-compliance issues, resulting in potential fines and legal
consequences.
Optional Task:
Examine the threat model diagram from Section 1 and
answer:

What non-encryption issues can you identify?

What recommendation would you give to solve those

issues?

Why do you recommend those solutions?

Issue 1: User request to web server transmitting via plain Text.

Solution: We have to use SSL certificate for CA to make the

request through HTTPS.
 Section 3
Risk Analysis
3.1 Scoring Risks

Risk Score
(1 is most dangerous, 4 is least dangerous)

Unencrypted at Rest 4

Reversible Encryption 2

Unencrypted in 1
Transit
Outdated Algorithm 3

Remove this slide

3.2 Risk Rationale
Why Did You Choose That Ranking? Make sure to include
your risk ranking methodology.
I used threat*vulnerabilty*imact to calculate the risk.
Risk Likely Impact Risk Reason
wood score
Unencrypte Low Low Low(4) Because this database not containing
d at Rest any sensitive information. If it
compromise no impact on the company.
Also, this database is in internal
network. Attacker needs to gain the multi
level access.
Reversible Low High Medium( Auth DB also internal network. Attackers
Encryption 2) need to gain the multilevel access. But
one achieved reversible encryption it will
affect other service using admin
credentials
Unencrypte High High High(1) Unencrypted Transit high risk because
d in Transit attackers easily able run the Man In the
middle attack to get the data.
Outdated High High Medium( Still outdated algorithms also having
Algorithm 3) enough encryption techniques. Bit
difficult to exploit it.
 Section 4
Mitigation Plan
4.1 Employee Data
Unencrypted at Rest
What is Your Recommended Mitigation Plan?

it is recommended to implement encryption at rest on DB

hosting databases containing sensitive information. This ensures
that data remains secure and compliant with relevant regulations
and industry standards.

Why Did you Recommend This Course of Action?

Encryption is coversion of plan text into cyber text. Latest

encryption algorithms using higher key value. If need to crack the
key we need more computainal power. So encrytption requried
data at rest.
4.2 Authentication Data
Stored Using Reversible
Encryption
What is Your Recommended Mitigation Plan?

Use Strong Hashing Algorithms: Employ hashing algorithms

designed for password storage, such as bcrypt, scrypt, or Argon2.
These algorithms include mechanisms to slow down brute force
attacks.

Salt the Hashes: Use a unique salt for each password before
hashing it. This ensures that identical passwords have different
hashes, preventing precomputed attacks like rainbow tables.

Why Did you Recommend This Course of Action?

Only hashing the rainbow table attack is possible. If we add salt

on each hashing it is diffcult to find the salt. Because salt is
company specific.
4.3 Authentication Requests
are Not Encrypted in Transit
What is Your Recommended Mitigation Plan?

We have implement strong TLS encryption between apps and

DB. Also need to us certifcate management.

Why Did you Recommend This Course of Action?

TLS provides encryption, integrity, and authentication, ensuring

that data cannot be intercepted or tampered with during
transmission.
4.4 DES Algorithm in Use
What is Your Recommended Mitigation Plan?

We have to use AES NIST approvied algorithm like AES 128, 192
and 256.

Why Did you Recommend This Course of Action?

AES is not easible breakable it needs more time and

computational power. Also it industry approved algorithm. Its
using symmentric cipher to encrypt and decrypt the data.
4.5 Security Audit
The audit team has been made aware of the systemic
issue and wants to ensure your recommendations are
followed. What steps can the audit team take?

Need to create the policies and procedure document and need

to send the communication mail to all user about the new
policies.

Regular internal audits required to monitor policies and

procedures are followed correctly.

Audit team will audit the Design ,architecture then codes.

In the design audit will ask following questions

1. What type of data it stroing? Is there any senstive data?

2. Where the system is hosted?

3. Encryption algorithms used?

In the Architecuture review phase will ask below questions.

1. How data is stroed?

2. Is data encrypted and used algorithm?

3. Is there any API used?

In the Code Review Phase will ask below questions.

1. Is there any third party libararys are used?

2. Is there any hardcoded secret are stroed?

Optional Task:
Create an architecture diagram of a secure system.

Image of your secure architecture:

Optional Task (Continued):
Additional Steps Would You Recommend to Prevent the
Attack as well as Future Issues:

We have use WAF to prevent the web application for the

OSWAP 10 attackes and need to user the internal firewall and
stroed access contorl mechanisam to prevent the insider
threats. Also need to monitor the continusoly to prevent and
detect the attackes.