0% found this document useful (0 votes)
17 views8 pages

Risk Management in Information Security

The document presents an analysis of risk management decisions regarding the launch of a product with a security vulnerability, weighing the options of delaying the launch versus launching and patching later. It includes calculations for Annual Rate of Occurrence (ARO) and Annual Loss Expectancy (ALE) for various threat categories, as well as a post-control assessment and cost-benefit analysis. The author ultimately decides to delay the launch to prioritize user data security and outlines communication strategies for stakeholders.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views8 pages

Risk Management in Information Security

The document presents an analysis of risk management decisions regarding the launch of a product with a security vulnerability, weighing the options of delaying the launch versus launching and patching later. It includes calculations for Annual Rate of Occurrence (ARO) and Annual Loss Expectancy (ALE) for various threat categories, as well as a post-control assessment and cost-benefit analysis. The author ultimately decides to delay the launch to prioritize user data security and outlines communication strategies for stakeholders.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Assignment 2

Reg No: FA22-BCS-062


Name: Muhammad Ibrahim
Course: Information Security
Instructor: Ms Sara Ali
Date: 17 October 2024
Question 1:

If I were in this situation as a risk manager, I would carefully evaluate both


options by considering the risks and the impact on the company and its
stakeholders. Here's how I would make my decision:
Option 1: Delay the Launch to Fix the Vulnerability
Delaying the launch would give the development team time to address the
security issue, ensuring that the application is safe for users. This option might
lead to some financial losses because the product launch would be postponed,
but in the long term, it could prevent much bigger problems.
• Financial Impact: While delaying the launch could cost the company
some revenue or investor confidence in the short term, a data breach
would likely result in even bigger financial losses due to potential fines,
legal costs, and damage control.
• Legal and Regulatory Risks: Data protection laws, like GDPR, are very
strict about handling user information. If we launch with a known
vulnerability and user data gets compromised, we could face huge fines,
lawsuits, and potentially irreversible harm to our reputation.
• Reputational Risks: Although delaying the launch might disappoint
investors and users, launching with a security vulnerability could damage
the company's image more severely. It’s better to have a delay and
ensure security than to face a loss of trust in the company, which might
be difficult to rebuild.

Option 2: Launch and Patch Later


Launching on time while fixing the security issue later could meet short-term
expectations, but it carries significant risks. Releasing an insecure product could
expose user data, and even though the vulnerability might be fixed later, the
damage could already be done.
• Exposure Risk: There's a possibility that unauthorized access to user data
could occur in the time between the launch and the patch. This could
lead to significant financial, legal, and reputational damage.
• Legal and Regulatory Risks: If any user data gets compromised, we
would likely face lawsuits or fines from regulatory bodies, which could
hurt the company’s financial health even more than delaying the launch.
• Reputation: If a data breach occurs, it could tarnish the company’s
reputation early on. Users might lose trust in our product and might not
return, even after the issue is fixed.

My Decision: Delay the Launch


After thinking about both options, I would decide to delay the launch and fix
the security vulnerability first. Even though it may cause some financial
setbacks in the short term, it’s safer to prioritize the security of user data. This
way, we avoid the legal risks, fines, and reputational damage that could result
from launching a vulnerable product. By delaying, we also demonstrate that we
take data protection seriously, which will help build trust in the long run.

Communicating the Decision:


• To Investors: I would explain that delaying the launch is a responsible
choice to avoid the much larger risks of fines, legal issues, and
reputational damage that could occur if we launch with the vulnerability.
I would also share a plan for how we’ll fix the issue and the updated
launch timeline.
• To Team Members: I would emphasize that fixing this issue is critical to
ensuring the product’s success and maintaining user trust. I would
encourage the team to stay focused on resolving the problem as quickly
as possible.
• To Users: I would communicate that the delay is necessary to ensure that
their data is fully protected. I’d assure them that we are committed to
delivering a secure, high-quality product, even if it means waiting a little
longer.
Question 2:

To calculate the Annual Rate of Occurrence (ARO) and the Annual Loss
Expectancy (ALE) for each threat category, I use the following formulas:
• ARO (Annualized Rate of Occurrence):
The frequency of occurrence converted to an annual rate. For example,
if a threat occurs "1 per week," the ARO is 52 (since there are 52 weeks
in a year). For "1 per year," the ARO is [Link] so on.
• ALE (Annualized Loss Expectancy):
The expected annual loss from a threat.
ALE = SLE (Single Loss Expectancy) × ARO

Threat Cost per Frequency of ALE (SLE x


ARO
Category Incident (SLE) Occurrence ARO)
Programmer $5,000 × 52 =
$5,000 1 per week 52
mistakes $260,000
Loss of
$75,000 × 1 =
intellectual $75,000 1 per year 1
$75,000
property
Software $500 × 52 =
$500 1 per week 52
piracy $26,000
Theft of
$2,500 × 4 =
information $2,500 1 per quarter 4
$10,000
(hacker)
Theft of
1 per six $5,000 × 2 =
information $5,000 2
months $10,000
(employee)
Web $500 × 12 =
$500 1 per month 12
defacement $6,000
Theft of $5,000 × 1 =
$5,000 1 per year 1
equipment $5,000
Viruses,
$1,500 × 52 =
worms, $1,500 1 per week 52
$78,000
Trojan horses
Denial-of-
$2,500 × 4 =
service $2,500 1 per quarter 4
$10,000
attacks
$250,000 ×
1 per 20
Earthquake $250,000 0.05 0.05 =
years
$12,500
1 per 10 $250,000 ×
Flood $250,000 0.1
years 0.1 = $25,000
1 per 10 $500,000 ×
Fire $500,000 0.1
years 0.1 = $50,000

QUESTION 3:

Post-control ARO and ALE

Threat Category Cost per Frequency of Post- Post-control


Incident Occurrence control ALE (SLE ×
(Post- (Post-control) ARO ARO)
control)

Programmer $5,000 1 per month 12 $5,000 × 12


mistakes = $60,000

Loss of $75,000 1 per 2 years 0.5 $75,000 ×


intellectual 0.5 =
property $37,500

Software piracy $500 1 per month 12 $500 × 12 =


$6,000

Theft of $2,500 1 per 6 months 2 $2,500 × 2 =


information $5,000
(hacker)

Theft of $5,000 1 per year 1 $5,000 × 1 =


information $5,000
(employee)
Web $500 1 per quarter 4 $500 × 4 =
defacement $2,000

Theft of $5,000 1 per 2 years 0.5 $5,000 × 0.5


equipment = $2,500

Viruses, worms, $1,500 1 per month 12 $1,500 × 12


Trojan horses = $18,000

Denial-of- $2,500 1 per 6 months 2 $2,500 × 2 =


service attacks $5,000

Earthquake $250,000 1 per 20 years 0.05 $250,000 ×


0.05 =
$12,500

Flood $50,000 1 per 10 years 0.1 $50,000 ×


0.1 = $5,000

Fire $100,000 1 per 10 years 0.1 $100,000 ×


0.1 =
$10,000

Some values in the Cost per Incident and Frequency of Occurrence columns
have changed after control because controls can impact one or both aspects:
• Cost per Incident: Controls like insurance or backups can reduce the
financial impact of an event when it happens (e.g., fire, flood). The cost
goes down because the business is better prepared to recover.
• Frequency of Occurrence: Controls like firewalls, antivirus, or physical
security lower the chance of an incident happening (e.g., hacker attacks,
viruses). These controls make events less frequent but don’t always
reduce the cost if they still happen.
In some cases, controls affect only one aspect:
• Frequency but not Cost: Antivirus software might reduce how often
malware attacks occur, but the cost stays the same when an attack is
successful.
• Cost but not Frequency: Insurance reduces the cost of a flood or fire, but
these natural disasters still happen at the same frequency.

Cost-Benefit Analysis (CBA)

Threat Category ALE Before Post- Cost of CBA (ALE Before −


Control control Control ALE After − Cost of
ALE Control)

Programmer $260,000 $60,000 $20,000 $260,000 −


mistakes $60,000 − $20,000
= $180,000

Loss of $75,000 $37,500 $15,000 $75,000 − $37,500


intellectual − $15,000 =
property $22,500

Software piracy $26,000 $6,000 $30,000 $26,000 − $6,000 −


$30,000 =
−$10,000

Theft of $10,000 $5,000 $15,000 $10,000 − $5,000 −


information $15,000 =
(hacker) −$10,000

Theft of $10,000 $5,000 $15,000 $10,000 − $5,000 −


information $15,000 =
(employee) −$10,000

Web defacement $6,000 $2,000 $10,000 $6,000 − $2,000 −


$10,000 = −$6,000
Theft of $5,000 $2,500 $15,000 $5,000 − $2,500 −
equipment $15,000 =
−$12,500

Viruses, worms, $78,000 $18,000 $15,000 $78,000 − $18,000


Trojan horses − $15,000 =
$45,000

Denial-of-service $10,000 $5,000 $10,000 $10,000 − $5,000 −


attacks $10,000 = −$5,000

Earthquake $12,500 $12,500 $5,000 $12,500 − $12,500


− $5,000 = −$5,000

Flood $25,000 $5,000 $10,000 $25,000 − $5,000 −


$10,000 = $10,000

Fire $50,000 $10,000 $10,000 $50,000 − $10,000


− $10,000 =
$30,000

Control Effectiveness for each Threat:

Positive CBA (worth it): Programmer mistakes, Loss of intellectual property,


Viruses, Flood, Fire.
Negative CBA (not cost-effective): Software piracy, Theft of information (both
hacker and employee), Web defacement, Theft of equipment, Denial-of-service
attacks, Earthquake.

You might also like