University of London

Assessment Submission Document

Complete the sections below and read the instructions below carefully.

Candidate Number:
Refer to your Admission Notice

Degree Title:
e.g. BSc Marketing

Course/Module Title:
As it appears on the question paper

Course/Module Code:
This is in the top right corner of the question paper. If there is more than one
code, use the first code.

Enter the numbers, and sub-sections, of the questions in the order in which
you have attempted them:

Date:

Instructions to Candidates

1. Complete this assessment submission document and begin

typing your answers on the page below.
2. Clearly state the question number, and any sub-sections, at the
beginning of each answer and also note them in the space
provided above.
3. For typed answers, use a plain font such as Arial or Calibri and font
size 11 or larger.
4. Handwritten answers (including diagrams or mathematical
formulae) must be done on light coloured paper using blue or
black ink.
5. Reference your diagrams in your typed answers. Label diagrams clearly.
6. Remember to upload the final version of your completed assessment
submission document as a Microsoft Word file before the deadline.
You are strongly advised to upload your document as a Microsoft
Word file. If you are unable to do this you may submit your work in
PDF format.

The Examiners will attach great importance to legibility, accuracy and

clarity of expression.

◻
Begin your answers on this page
Question 1 (Compulsory question)
(a) The Von Neumann architecture introduced more flexibility in programming. Briefly
explain how this flexibility is also a security threat. (5 Marks)
Von Neumann architecture is one of the earliest architectural models that has remained
paramount to most modern computing systems. It provided optimisable flexibility because
instructions and data were located in a single memory space, which made it easier to write
software. Von Neumann architecture offers significant leverage for software expansion and
execution. On the other hand, this design presents broader security risks, which hackers are
quick to identify and exploit.
1. Executable Data Manipulation (Code Injection Vulnerabilities)
When implementing an operating system (OS) in assembly language, the issue of weak code-
data separation is a significant problem. Since instructions and data persist in memory, an
attacker can exploit code with data and cause it to execute instructions that contain the same
data. This makes systems vulnerable to code injection and attacks that exploit program flaws to
insert and execute malicious code. If this injected code is executed on the system by mistake,
the attacker would gain complete control of the system. For instance, in a buffer overflow attack,
the attacker writes more data into a memory buffer than what it can contain and alters the flow
of the program by overwriting it with buffer contents. A buffer overflow attack is a type of
memory corruption in which an application writes more information into a buffer, and this
overruns another region of memory, enabling code execution (Sharma & Mittal, 2019).
2. Self-Modifying Code and Malware Proliferation
The flexibility in program instructions is also part of the features found in the models of Von
Neumann architecture. This is mainly because they are developed in a way that makes viruses,
worms, and trojan horses able to modify system behaviors dynamically and hence difficult to
detect. Concerns might also be raised about the recursive function as the code may change
during the process of execution, and system behavior becomes an issue when dealing with
security threats (Shettigar et al., 2024). Malware can enter systems through code injection,
where the malware code is inserted into any of the legitimate programs and can easily change
code that is executable in the memory. This is much more subtle and, therefore, insidious and
harder to identify and disentangle.
3. Unintended Execution of Malicious Payloads
It has no protection against malicious instructions, so an attacker can force the system to run
scripts. This is particularly true in remote code execution (RCE), a type of cyberattack where
hackers exploit flaws in an application to execute arbitrary code on a specific machine.
4. Side-Channel Attacks
Certain types of attacks can be launched against the shared memory architecture, including
timing attacks, cache-based attacks, and side-channel attacks. They exploit microarchitectural
states such as those observed in Spectre and Meltdown attacks. In addition, Von Neumann
bottlenecks also create performance issues where these bottlenecks are leveraged to perform
side-channel attacks from the leakage of execution time or power usage. Although newer
generations of machines have incorporated TEEs and DEPs to restrict unauthorised
execution, the architecture problem remains a key security threat (Naik et al., 2022).
5. Unprotected Memory Execution
Execution control in Von Neumann systems is not rigid, implying that any memory area can be
executed, provided it has been designated as such. This is achieved by modifying the
execution rights of memory, allowing code to be executed in areas that are generally not
intended for code execution. Therefore, while the stored-program concept that characterises
Von Neumann architecture provides superior software programmability, it lacks built-in
security boundaries, which are proven to be crucial in contemporary computer systems. This
renders systems vulnerable to memory corruption, where systems fail to manage memory
allocation, resulting in improper exploitation. Since both legitimate applications and malware run
in the same environment, it is possible to exploit techniques such as Return-Oriented
Programming (ROP) to manipulate the system’s execution flow (Grassi et al., 2017). This
fundamental weakness makes it easier for malware and ransomware attacks to occur, as
arbitrary code can be inserted and executed without restriction.

(b) “The only system which is truly secure is switched off and unplugged, locked in a
titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very
highly paid armed guards. Even then, I would not stake my life on it," is a quote
attributed to Gene Spafford, a security researcher. While there is hyperbole in this
statement, briefly explain why no system can ever be deemed to be entirely secure. (5
marks)
This quote by Gene Spafford hyperbolically sums up what many security experts now
acknowledge, that fully secure systems do not exist. It is essential to remember that risks are
present in every situation. The following reasons put forth why no system can be entirely
secure:
1. The Complexity of Software
Contemporary systems consist of tens of millions of lines of code, which means it is impossible
to achieve methods of 100% security. Software can always contain hidden flaws no matter how
reliable and secure it has been developed and tested. This is because as its complexity
increases, so does the number of potential security issues. Today’s operating systems
contain millions of lines of code, and therefore, they can easily have bugs and security
vulnerabilities. However, challenging testing and diverse formal verification methodologies prove
inadequate in solving problems such as zero-day attacks (Grassi et al., 2017).
2. Human Factor (Social Engineering & Insider Threats)
In many systems, the most vulnerable element is the user because they have a positive or
negative impact on the situation. No system is completely safe, regardless of how well-protected
it is, if users fall victim to fake strategies (Microsoft Security, 2019). Attack vectors exploit
human errors and utilise human behavior, including phishing, impersonation, credential theft,
and the creation of fake accounts, creating gaps in cybersecurity systems rather than actual
vulnerabilities. Notably, security threats are not limited to physical intrusions; they also include
malicious insiders and disgruntled employees, who pose a significant danger as well.
3. Supply Chain Attacks
Systems rely on dependencies, which can include default credentials, backdoors, malware, or
firmware that has been compromised. Both hardware and software have exploitable
dependencies, allowing a malicious actor to inject a component that introduces insecurity. As
revealed by the SolarWinds cyberattack, nation-state actors can infiltrate and exploit the
supply chains of organisations worldwide (Shettigar et al., 2024). Thus, even if a system is as
secure as possible, there may still be problems with suppliers, both for hardware and software,
which can compromise it.
4. Zero-Day Vulnerabilities
Some weaknesses are hidden and come to light only after a hacker targets them.
In truth, as security measures depend on known threats, attackers can always probe for
vulnerabilities that have yet to be discovered.
5. Physical and Environmental Threats
A heavily protected system is not immune to physical damage, such as fire outbreaks, floods,
electromagnetic pulse attacks, power outages, and hardware degradation, among others.
The following are some possible scenarios involving physical attacks: cold attacks, hardware
implants, and side-channel attacks.
6. Resource Constraints and Trade-offs
As is often the case, security compromises usability and performance sometimes.
Unlike other commercial sites, organisations face an inherently unavoidable trade-off between
accessibility, usability, and security. Although it is possible to minimise risks through the
implementation of security measures, total security can never be achieved due to factors such
as complexity, human error, constant change, and limited resources in software development.
7. Advanced Persistent Threats (APTs)
Furthermore, there are advanced persistent threats (APTs), which also employ more complex
tactics, such as Living Off the Land (LOTL), where the adversary leverages local programs and
utilities. Security measures, such as Zero Trust Architecture (ZTA) and behavior-based anomaly
detection, can only reduce risks; they are not foolproof (Naik et al., 2022). As such, air-gapped
systems remain vulnerable, even to side-channel attacks, electromagnetic interference, or
infected removable media. The Stuxnet worm, which targeted Iranian nuclear facilities, is a
prime example of how offline systems remain vulnerable to attack (Sharma & Mittal, 2019).
Therefore, security risks cannot be eliminated by security measures, emphasising the
importance of risk management, threat detection, and effective security management.
(c) Read the following text taken from the UK NCSC website. Envision yourself as a
computer security analyst responsible for incident response within a company. Identify
and justify the key steps you would take when vulnerabilities and patches are known and
made available. Be sure to state and explain any assumptions you make, if deemed
necessary. You are not expected to know anything else about the Log4j vulnerability
apart from the text description above. (10 marks)
When responding to the Log4Shell vulnerability as a computer security analyst in charge of
incident handling, I will quickly and carefully develop a structured incident response plan. The
key steps include:
1. Identification and Assessment
• Conduct an asset discovery to determine whether the specific vulnerability is relevant in the
company’s systems and whether any applications or services have been affected by Log4j.
Identify which versions are affected and whether the vulnerability is currently being exploited.
• Evaluate the exploitability by employing frameworks such as CVE to identify which systems of
the target are vulnerable (Grassi et al., 2017). Use Vulnerability scanning tools (such as
Nessus, Qualys, and OpenVAS) to identify Log4Shell exposure.
• Some of the logs to look for include those related to exploits, HTTP patterns, or other features
that may attempt Remote Code Execution (RCE), as highlighted by Sharma and Mittal (2019).
2. Urgent Containment Measures
• Immediately apply temporary mitigations and put systems with running vulnerable Log4j
instances on and off the internet to block unauthorised remote access. Some recommendations
include updating firewall rules and Web Application Firewalls (WAFs) to address contingencies
related to the attack vector.
• Shut down or limit the use of the affected system if it cannot be patched immediately. Utilise
workarounds such as JVM flags to mitigate the vulnerability (Shettigar et al., 2024). Then,
monitor network traffic for signs of exploitation.
3. Patch Deployment and Remediation
• Promptly install all official security updates to fix vulnerable systems as soon as they are
released. The formulation of a patch management structure enables the rapid deployment of
patches. Ensure that every application is updated, including any additional software that utilises
Log4j.
• Ensure patch effectiveness by frequently conducting vulnerability assessments and
penetration tests after applying the patch.
• Update security policies to include daily patch monitoring and vulnerability scanning (Grassi et
al., 2017).
4. Forensic Investigation, Recovery, and Post-Incident Review
• Sweep for residual threats to check for any IoCs that may still be present in the network. This
involves deploying Endpoint Detection and Response (EDR) solutions for better threat
monitoring (Microsoft Security, 2019).
• Perform a post-emergency check with the load to verify that hackers were able to enter
networks before patching
• Sustain future security by enhancing SDLC security strategies and implementing robust
logging techniques to prevent similar issues (Sharma & Mittal, 2019). Also, conduct a memory
and disk analysis to identify persistent threats. This approach helps reduce the risk of other
attacks and data exploitation while maintaining business continuity and ensuring compliance
with regulatory standards.
5. Strengthen Detection and Prevention Measures
• Update IDS & IPS to mitigate Log4Shell exploitation attempts.
• Install and configure Web Application Firewalls (WAFs) to mitigate issues caused by malicious
payloads.
6. Security Awareness and Communication
• Inform stakeholders (management, users, IT teams) about risks and response actions.
• Suggest measures that employees should follow to avoid falling prey to phishing and
credential theft attacks.
7. Long-term security improvements
• They need to evaluate current security policies and develop new protocols for responding to
incidents and attacks.
• Conduct a vulnerability assessment through penetration testing to identify and mitigate
vulnerabilities.
• Improve the security of the supply chain for software in order to avoid such a scenario:

(d) Briefly explain the key differences between CVSS and CVE and how these two metrics
complement each other. (5 marks)
1. Common Vulnerabilities and Exposures (CVE)
CVE is an owned list of known security vulnerabilities. CVE is a permanent, unique dictionary of
publicly known identified vulnerabilities. This means that every weakness has a specific
assigned number, known as a CVE ID. However, there is no reference to the level of threat
posed by the vulnerability. Each CVE entry contains:
• A unique CVE ID (e.g., CVE-2021-44228 for Log4Shell).
• A brief description of the vulnerability and affected systems.
• References to security advisories (Grassi et al., 2017).
2. Common Vulnerability Scoring System (CVSS)
CVSS rates vulnerabilities on a scale of 0 to 10 according to the associated risk. Scores are
classified into four categories: low (0.1-3.9), moderate (4.0-6.9), high (7.0-8.9), and critical (9.0-
10.0).
CVSS and CVE are two standards used in the field of security to evaluate vulnerabilities and
codify them, respectively. However, CVE alone cannot explain the severity of a particular
vulnerability or the extent to which it could be exploited. This is one area where CVSS
supplements CVE.
CVSS uses a 0-10+ scale to calculate exploit and impact and sorts vulnerabilities into low,
medium, high, or critical threats. The CVSS framework takes into account aspects such as:
• Attack vector (local, adjacent network, remote).
• Attack complexity (low or high).
• Privileges required and user interaction.
• Confidentiality, integrity, and availability are impacted (Naik et al., 2022).
How CVSS and CVE Complement Each Other
CVE categorises them, while CVSS provides a measure of their severity.
CVSS is helpful for security teams when it comes to prioritisation of CVEs for patching.
While CVSS is a metric that assesses risk independently of a CVE score, CVE, in turn, requires
CVSS to provide the corresponding numbers.
CVE is used for classification, while CVSS is used for ranking and determining the priority of risk
management; this way, organisations can address the most severe threats first.
In practice, organisations use CVE to assess threats and CVSS to prioritise risk management.
For instance, a CVE with a CVSS score of 9.8, which falls under the critical category, would be
considered more necessary than a CVE with a score of 5.5, which falls under the medium
category.

Question 2 (Compulsory question)

(a) Four rings exist to manage privilege levels in modern OSs. In practice, only rings 0
and 3 are used. Briefly explain why this is the case, using drivers as an example. (5
marks)
Privilege levels are defined in modern operating systems (OSs) using a ring-based security
model, where the OS runs in a high privilege ring. In contrast, user applications run in a
restricted ring to isolate them from potentially threatening processes. There are four privilege
rings numbered from 0 (highest privilege) to 3 (lowest privilege), but in practice, only Rings 0
and 3 are fully implemented. The OSs employ a ring structure that provides a virtual boundary
around areas of the system to reduce their access and increase protection. These privilege
rings, especially in x86 architecture, are the following: Ring 0 or Kernel mode, Ring 1, Ring 2,
and Ring 3 or the User mode. However, only Ring 0 and Ring 3 are employed heavily, while
Ring 1 and Ring 2 are rarely used.
Understanding privilege levels and their usage
1. Ring 0: This is the innermost and most privileged level (Kernel Mode), where the OS
kernel, device drivers and core system services operate. It has direct hardware access, can
execute privileged CPU instructions, and can control the memory, processes, and drivers. This
ring holds the OS kernel, the device drivers and other fundamental system processes.
2. Ring 1: It was first targeted for intermediate-level privileges like device Drivers or
system Services. However, modern OSs perform most of these functions in Ring 0 (Kernel
Mode). OS services of lesser importance can run here, such as low-level system drivers.
3. Ring 2: Intended for device drivers and I/O management, it allows controlled access to
hardware without full kernel permission.
4. Ring 3 (User Mode): This is the lowest form of circuits, which is reserved for users and
their applications such as web browser and text editor. It is also a highly privileged ring which
runs at this level, isolated from system critical operations. Programs are executed here to
protect the hardware from direct access to enhance the stability and security of the system.
Why Only Rings 0 and 3 Are Used
1. Reduced Number of Execution Levels: Transitioning between Kernel Mode and User
Mode only minimises the complexity of implementing OS architecture and the disadvantage of
the frequent switch between modes.
2. Increased Efficiency: This is due to the limited privilege checks required when
switching from user mode to kernel mode or vice versa, thus leading to better performance.
3. Convenience and Control: Rings 1 and 2 may pose a significant issue of complexity to
access control, thus causing security issues. An example is the case of device drivers, as they
are in closer touch with the system hardware and, as such, they will need Ring 0.
4. Compatability with Modern Hardware: Many of the current processors and operating
systems like the Windows and the Linux-based systems do not include the rings 1 and 2 at all
as the concept has been integrated into the ring 0.
Rings 1 and 2 are not often used in recent OS implementations because:
1. Simplification; Having only two privilege levels (kernel and user) removes significant
complexity in CPU mode switching due to the reduction to two modes as well as
simplifying OS design where the necessity of having several levels is eliminated.
2. Switching between multiple rings comes at the cost of increased CPU overhead.
System performance is optimised by keeping only two active rings (Ring 0 and Ring 3).
3. Memory and Security Management: Controlled user and kernel space access is
enforced by mechanisms like virtual memory, which uses only one ring; other rings are
not necessary.
4. Modern Hardware Design: Nowadays, CPUs and OS architectures like Windows,
Linux, or macOS are primarily based on a two-ring model (Kernel and User Mode, which
provides better correspondence with modern security needs.
Example – Device Drivers
Kernel-mode device drivers need direct control over some of the computer’s resources, such
as memory and I/O ports. Rather than being executed in the intermediate privilege level of
Ring 1 or 2, they are instead executed within the Ring 0 privilege level. This makes it easier in
inter and intra hardware communication and also enhances security by limiting access. On
the other hand, facilities like browsers and word processors are kept on the third ring and do not
threaten the stability of the operating system. Drivers assigned to Ring 2 would not be able to
avoid context switching to Ring 0, imposing unnecessary performance bottlenecks. Instead,
OSs either:
1. They run critical drivers, including GPU and disk controllers in Ring 0, to maximise
performance.
2. Restrict drivers’ direct access to hardware by moving nonessential drivers to Ring 3 via user-
mode drivers.
The modern two-ring system is a design choice that strikes a balance between security,
stability, and performance, thus justifying the two-ring system.

(b) Briefly explain what root can and cannot do in Linux. (5 marks)
The Root User in Linux
Linux utilises a root account that is the administrator or super user with complete control over
system processes and files. The root user (aka superuser) is the highest level user allowed
system control in a Linux-based system. Root has unrestricted access to all commands, files
and system configurations, unlike regular users.
What Root Can Do
1. Root has Full System Access: Root can read, write, edit, or execute most system files and
directories in Linux that regular users are restricted from.
2. User and Group Management: The Root can install or delete software packages and user
accounts and grant rights, including software that changes the way the system works.
3. Privileges: The Root can perform operations like starting, stopping, or even terminating a
process in the system, including critical system processes.
4. Networking capability: Root is able to control different networking aspects such as Firewall
and iptables configuration.
5. Change system configurations: The root can change configuration files, specifying how the
system will behave. Using commands such as chmod and chown, the root can modify file
permissions and ownership.
6. Software installation and System update: Root can install, uninstall, or update the system
using a package manager, including APT of Debian and YUM of Redhat.
7. Root can open ports, configure network interfaces, and modify firewall settings to access all
network services.
8. Root may turn off security mechanisms such as SELinux or App Armour.

What Root Cannot Do

1. Access Limitations for Hardware: The Root cannot and will not override or get beyond the
physical barriers imposed by the hardware of the particular machine, like the BIOS/UEFI
password lock.
2. Bypass Security Systems: Some security frameworks, including SELinux and App Armour,
limit what the root can do to avoid exploitation.
3. Encryption Cannot be Altered Without Keys: Even if the Root user tries to access files,
they cannot open them unless he has the correct encryption key.
4. Some Kernels forbid the root as well: Modern Linux distributions employ Kernel Page-Table
Isolation (KPTI) that does not allow even the root to access specific memory regions.
5. Change the Kernel While Running: Root can modify kernel parameters, though some
changes must specify a reboot.
Consequently, though consequential, the root is still limited by hardware restrictions, encryption
constraints, and permanent errors.
(c) Modern OSs make use of reference monitors. Explain objects, subjects and principles
and how they relate to the reference monitor while also showing where the reference
monitor can exist in the OS. Explain how Linux implements the reference monitors using
Access Control Lists (ACLs). (10 marks)
Reference Monitor in OS Security
A reference monitor is an essential component of the security solution that supports the
provision of access control because it acts as a mediator between the agents-of-change
(subjects) and the objects-of-change (files, devices, resources).
Key Components:
• Subjects: These are active entities including users, applications, and processes that request
access.
• Objects: These are databases that need to be safeguarded, including files, memory
segments, devices, data, and databases.
• Access Control principles: Security principles like least privilege and separation of duties,
ensuring only the relevant subjects have access to necessary objects. The reference monitor
employs three principles:;
1. Full Mediation: Subject to certain conditions, entry control is conducted with the assistance
of cards containing appropriate encoded data, which is checked in the identification centre.
2. Tamper-proof: The reference monitor must be resistant to external override.
3. Accountable: It must be measurable, and people should be able to verify its operations
quickly.
Where the Reference Monitor Exists in OSs
In Linux, the reference monitor performs at;
• Kernel Mode: Security policies are enforced through reference monitors at the kernel level
that intercept system calls.
• Hypervisors (Virtualized Environments): The reference monitors between the host OS and the
virtual machines.
They comprise the Access Control Systems: Consist the Access Control Lists (ACLs) and
Mandatory Access Controls (MAC) systems enforcing user permissions, compliance, and
system security policies.
Linux Implementation via ACLs
As for permissions, Linux go further than the conventional user-group-other (UGO) model and
employs reference monitors in the form of Access Control Lists (ACLs).
1. ACLs provide finer-grained permissions beyond the standard UNIX permission model.
2. File access policies can be modified using commands such as getfacl and setfacl.
3. Linux security is strengthened with mandatory access controls (MAC) such as SELinux and
App Armour.
Linux Implementation – ACLs
As for permissions, Linux implements firm access control, enabling access to protected objects
only by subjects permitted to do so via ACLs. ACLs allow:
• Fine-grained control over file access.
• Multiple user permissions per object.
• Data rights at detailed access, ensuring limited security concerns.
(d) Compare ACLs and Capabilities – what does each do well and poorly? (5 marks)
Access Control Lists (ACLs):
Advantages:
• Fine-grained access control: ACLs define access in terms of users and groups.
• Multiple user-specific permissions: Permissions can be quickly reviewed explicitly using tools
like getfacl.
• Broad Compatibility: Works across various file systems.
Disadvantages:
Lateness: Checking ACL entries for every access request slows the system down. This is
because it is complex for large systems to manage.
There is a risk of privilege creep if it is not regularly checked.
Capabilities:
Advantages:
Enables process administrators to grant unique permissions to PIDs, thereby avoiding the
granting of overly broad permissions.
Better security model: Follows least privilege principle, increasing security and eliminating
privilege escalation risks.
Granular: assigning specific rights, including network access, as opposed to a role such as
being a manager to an entity.
Disadvantages:
More complex than ACLs.
It may be challenging to audit and manage as admins must painstakingly assign each capability,
which creates workload.
Thus, capabilities provide more secure, least privilege enforcement, whereas ACLs provide
structured access control.

Question 3
(a) What is a system’s attack surface? Provide a brief example of how secure design can
reduce a system’s attack surface. (5 marks)
A system’s attack surface is the total number of points of interaction for a system where an
attacker can try to exploit vulnerabilities. It encompasses all entry points to the system,
intentionally including APIs and authentication systems and unintentionally including software
bugs and unpatched security flaws.
There are three key areas of the attack surface:
1. Network Attack Surface
Scannable and exploitable open ports, including SSH, RDP, and HTTP.
Exposed services, such as public-facing web servers and databases.
Remote access mechanisms include VPN and cloud services.
2. Software Attack Surface
Application vulnerabilities, including SQL injection and buffer overflow.
Unpatched software with known exploits.
Third-party libraries with security flaws.
3. Human Attack Surface
Weak authentication mechanisms like default passwords.
Social engineering vectors like phishing attacks.
Sensitive data that is exposed due to user misconfigurations.
Having a large attack surface means that attackers have more potential entry points, while
having a small attack surface means that there are fewer opportunities to exploit.
Reducing an Attack Surface via Secure Design
For a corporate web app that lets users do the following;
1. Support multiple authentication methods, including username/password, social media
login, or single sign-on.
2. No restrictions on upload files (any file type, any size).
3. All API endpoints can be accessed without authentication.
Security Improvements to Reduce Attack Surface:
• Reducing Authentication Methods: Removing weak authentication methods (such as social
media login) and forcing multi-factor authentication (MFA) for increased security.
• Restricting File Uploads: Allowing only specific file types (e.g., PDFs, JPEGs), with content
filtering and malware scanning applied before accepting uploads.
• Securing APIs:
Implementing OAuth 2.0 authentication for access control.
Only expose API to authenticated and authorised users.
Adding rate limiting and request validation to prevent abuse.
These measures harden the system against common threats, such as brute force attacks,
malware injection, and API abuse, by reducing the number of potential attack vectors.
(b) Usability and security are often regarded as opposing forces in secure design. Briefly
explain why this is the case and give an example. (5 Marks)
The Security-Usability Tradeoff
Stronger security controls often conflict with security and usability because they introduce
complexity to a system, making it more difficult to use. Usability emphasises making the
product convenient and efficient for the user, whereas security aims to limit access to
unauthorised users and prevent potential threats.
This tradeoff arises because:
1. Stronger Security = Increased Complexity
Authentication mechanisms are complex, such as long passwords and multi-factor
authentication (MFA), which can slow down user interactions.
User compliance is needed for frequent security updates and patching.
2. Higher Usability = Increased Risk
Systems are vulnerable to simplified login methods, including weak passwords and single-click
logins.
If a device is compromised, it can be used to exploit auto-login and session persistence
features.
Example: Two-factor authentication (2FA) in Online Banking
Without 2FA: Users enter a username and password, a fast and easy login, but one that is
highly susceptible to credential theft.
With 2FA, users must enter a one-time code sent via SMS or an authentication app.
Prevents unauthorised logins to enhance security.
It reduces usability because users have to do an extra step, which can lead to frustration or
reluctance to enable the feature.
Real-world Implication:
Ironically, some users may turn off security features (e.g., two-factor authentication) due to
usability concerns, which ironically makes their accounts less secure.
Balancing Security and Usability
Organisations can implement to maintain usability and security.
• Seamless but secure logins using biometric authentication (e.g., Face ID, fingerprint
scanning).
• 2FA only when conditions are suspicious (e.g., logging in from a new device).
Security measures can be more widely adopted without sacrificing protection by reducing
friction.
(c) Summarise and then critique the Microsoft Software Development Lifecycle
framework. Identify the advantages and limitations of the framework. Be sure to justify
the claims you make. (10 Marks)
Summary of the Microsoft Software Development Lifecycle (SDL) Framework
The Microsoft SDL is a security-focused software development methodology that embeds
security into every phase of software development. The idea is to reduce vulnerabilities before
deployment, not reactively.
Key Phases of SDL:
1. Security training that equips developers with best practices knowledge.
2. Security policies, compliance requirements, and risk assessments are defined.
3. Secure design principles (e.g., least privilege, threat modeling) are applied.
4. Secure coding guidelines and automated tools are used for implementation.
5. Penetration testing, static analysis, and security audits are verification.
6. Release and Response: The software is released and monitored for updates.
Advantages of the Microsoft SDL
Proactive Security Approach
• Unlike traditional models that address security late in development, SDL identifies and
mitigates risks early, thereby reducing security flaws before deployment.
Threat Modeling Enhances Security Awareness
• With SDL, teams must systematically identify potential attack vectors before coding, allowing
them to design against threats proactively.
Integration with Modern DevSecOps Practices
• Automated security tools, including static code analysis, are integrated into Microsoft SDL,
making it compatible with modern Continuous Integration/Continuous Deployment (CI/CD)
pipelines.
Regulatory Compliance
• It is aligned with ISO 27001, GDPR, and NIST standards to ensure compliance with industry
regulations.
Limitations of the Microsoft SDL
Time and Cost Overhead
• Additional training, security testing, and documentation are added with SDL, slowing down
development cycles and increasing costs.
Not Fully Compatible with Agile Development
• Traditional SDL phases are rigid and structured, which makes them less suitable for fast-
paced Agile and DevOps workflows.
High Learning Curve for Developers
• Developers must undergo extensive security training, which can be challenging for smaller
teams with limited expertise.
Thus, Microsoft SDL is a robust framework for secure software development; however, it needs
to be adjusted to accommodate modern Agile workflows. Lightweight security controls could be
implemented in iterative cycles to improve their adoption in fast-paced development
environments.
(d) Briefly explain why “Security by Obscurity” is considered poor security. Provide an
example to demonstrate your point. (5 Marks)
Definition of Security by Obscurity
Security by Obscurity (SBO) relies on secrecy as the primary means of protection. SBO
attempts to conceal security mechanisms from attackers rather than implementing robust
cryptographic defenses or access controls.
Why SBO Is Poor Security
• Attackers can reverse engineer systems: If given enough time, attackers can look at,
decompile, or brute-force hidden implementations.
• It Fails When Exposed: If the security mechanism is compromised, the entire system is
vulnerable.
• It Does Not Provide Layered Security: It lacks defense-in-depth, as it is a single point of
failure.
Example: Proprietary Encryption without Peer Review
Instead of using industry-standard encryption algorithms (e.g., AES, RSA), a company creates
its custom encryption algorithm. All encrypted data is compromised if an attacker analyses
the algorithm and finds flaws. Proper security is about strong, tested defenses, not secrecy.
 References
Grassi, P.A., Fenton, J.L., Newton, E.M., Perlner, R.A., Regenscheid, A.R., Burr, W.E., Richer,
J.P., Lefkovitz, N.B., Danker, J.M., Choong, Y.Y. and Greene, K.K., 2017. Nist special
publication 800-63b. digital identity guidelines: authentication and lifecycle
management. Bericht, NIST.
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-63b.pdf
Sharma, A.K. and Mittal, S.K., 2019, January. Cryptography & network security hash function
applications, attacks and advances: A review. In 2019 Third International Conference on
Inventive Systems and Control (ICISC) (pp. 177-188). IEEE.
https://ieeexplore.ieee.org//document/9036448
Microsoft Security (Aug 20, 2019). One simple action you can take to prevent 99.9 percent of
attacks on your accounts. Melanie Maynes, Senior Product Marketing Manager.
https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-
take-to-prevent-99-9-percent-of-account-attacks/
Naik, N., Jenkins, P., Grace, P. and Song, J., 2022, October. Comparing attack models for it
systems: Lockheed martin’s cyber kill chain, mitre att&ck framework and diamond
model. In 2022 IEEE International Symposium on Systems Engineering (ISSE) (pp. 1-7).
IEEE. https://ieeexplore.ieee.org//document/10005490
Shettigar, P., Mendonca, T. and Radhakrishnan, S., 2024, August. NETWORK SECURITY AND
CRYPTOGRAPHY. In Emerging Trends in Information Technology (ETIT)(Proceedings
of Conference) Volume-II (p. 84).
https://pim.ac.in/wp-content/uploads/2025/02/Emerging-Trends-in-IT-Conference-
Proceedings.pdf#page=89