Log4j Vulnerability, Threat Analysis, And Risk Assessment In A University Case Study

Stage One

Task 1: Log4j Vulnerability

Log4j is a ubiquitous piece of software found in several software and other applications. It is a third-party open-source software developed and distributed by the Apache Software Foundation. Log4j is among the several building elements used in contemporary software development. Many organizations utilize it to perform a common but crucial task (National Cyber Security Center, 2022). The job of Log4j is to record user events and errors; whenever people use resources such as networks, mail, or other software, for example, they are routinely required to log in. Whenever the log in credentials is incorrect, error messages are generated. Log4j gathers and stores these error messages and activities in servers for administrators to use for monitoring user activity (National Cyber Security Center, 2022). When people access online services such as cloud computing services, they are often required to log in, and error messages such as 404 for bad web addresses are generated. These log messages must be formatted into user readable and machine-readable language, and this is done through third party code. Log4j allows third party code to be executed and this is what is routinely exploited by malicious users such as hackers. Logging in to a cloud application, for instance, requires the user to type their username and password (Center for Internet Security, 2022). In many cases, there is a server with a directory of real names, and so during error message formatting, the real names can be linked to the usernames, making it possible to steal personally identifiable information (PII) because Log4j must interface with the server containing the real names.

Log4j is used widely around the world, in online and software services, and to exploit its internet vulnerability, minimal or just basic technical skills and knowledge is required. As a result, Log4 Shell could be the most serious computer vulnerability in contemporary times. This role of error and activity reporting can be used for other nefarious purposes. This is because Log4j does accept various third-party code and its work is to execute any submitted code. It lacks the ability to check or test code to determine if it is malicious or normal code (Tan, 2022). The third-party codes can be intended to perform several tasks, and Log4j executes them without any security verification. Considering the vast numbers of available software, it means there is a huge attack surface to be exploited. This allows for illicit operations like seizing remote control of the target machine, stealing sensitive data or information such as passwords, and spreading malware to other users interacting with a targeted or already infected server (Goel, 2022). For most software, logging is a fundamental feature and by default means Log4j is spread widely, given its use in online games such as FIFA to accessing Amazon Web Services or logging in to secure cloud services. While large corporations like Microsoft can fix their web services much quicker, preventing malicious entities from abusing them; however, several organizations such as the university will take longer to do so, and some may not even be aware that they need to.

Task 1: Log4j Vulnerability

  Malicious entities are searching the web for unprotected servers and configuring devices to send malicious payloads. They query services form the target system/ servers (for instance, web servers) and attempt to set-off a log message to carry out an attack such as the common 404 errors. The query contains code that is maliciously designed, and Log4j interprets as commands. These malicious code can either generate a reverse-shell, allowing the attacker server to remotely gain control of the targeted server remotely, or convert the target into a botnet. Lookups are a new feature that was introduced with the release of Log4J 2.0. Lookups can be used to add more information to log entries (Goel, 2022). The JNDI (Java Names and Directory Interface) lookup, a Java API for directory services communicating, is one of these lookups. Internal user identifiers can be resolved to real user names using this tool. Because one data type that can be returned from the LDAP server is a URI linking to a Java class, which is subsequently loaded into memory and run by the Log4J instance, this lookup is the key to the newly found RCE vulnerability (Samanta, 2021). Due to faulty input validation in the Log4J library, making it possible to insert an arbitrary LDAP server from a source that is untrusted.

Task 2: Threat Analysis and Risk Assessment of a University Case

The first step in evaluating security vulnerability is threat assessment. The goal of a threat assessment work is to evaluate the numerous security threats connected with a certain area. Natural hazards (hurricanes, tornadoes, earthquakes, and floods), criminal threats (violence against workers, theft from site), terrorism threats (explosive devices that are person-borne, vehicle borne, and active shooter incidents), and probable accidents are all covered (Luo et al., 2021). The figure 1 below shows the high level IT infrastructure of a university and its assets, and the specific areas of Log4j vulnerability. 

 

Fig 1

The university has a number of assets, that include its databases and network protocols, and the data contained within them. To access resources within the university system, users have to log-in using provided credentials. They use a password and authentication manager to access resources such as student performance (Luo et al., 2021). The Log4j software performs monitoring and recording of events and logs, including errors using third party codes that it executes as instructions, without any security. The university IT assets are vulnerable to Log4j attacks through its external-facing assets, such as the mail server, public web server, extra-net server, or DNS server, all that link externally to the internet via a router. A Log4j attack is propagated as follows (based on Fig 1);

Task 2: Threat Analysis and Risk Assessment of a University Case

Step 1: Attacker Scans web for vulnerable servers using JNDI lookup

Step 2: Request sent to university server with attacker LDAP server link

Step 3: Log4j logs the JNDI string, parses string and triggers query to attacker LDAP server through JNDI lookup without verification

Step 4: JAVA class is loaded by vulnerable application and the malicious code is executed

Step 5: Injected payload triggers second phase and the attacker is able to execute arbitrary code and launch further attacks

Task 3: Threat Analysis- Various Vulnerabilities Other Than Log4j Vulnerability

The university, based on its architecture, still has some significant risks and vulnerabilities apart from the Log4j vulnerability. These include:

DDoS (Distributed Denial of Service) and (DoS) Denial of Service – This is a network-based attack in which hackers or malicious entities flood the university’s network with thousands of data packets. This is done by gaining access to the network when these packets are from several diverse (distributed) sources, the attack is known as DDoS and when from a single source, it is DoS.

Human error or deliberate human action (internal risk)- this is one of the most significant risks the university faces and accounts for the largest percentage of cyber incidents and attacks. Acts or commission or omission by staff, such as failing to have secure passwords, leaving machines open without shutting down, or using an infected external storage device that then infects the entire university IT infrastructure (Wangen et al., 2016). Considering the Log4j risk vulnerability, the diagram below is developed to illustrate the risk assessment for the university, indicating and explaining the sources of threats, the actors in the threats.

Router risks- Routers are part of the university network infrastructure and are particularly vulnerable to attacks.  These devices provide a connection point between users and the Internet, making them essential components in the university IT infrastructure. When routers are not password protected, or encrypted and the firmware updated, they become points for injecting malware, insertion of eavesdropping devices, or re-engineering to direct users to spam sites (Jang-Jaccard & Nepal, 2014). The routers can also be taken over for use in DDoS attacks to overwhelm targets’ networks with Web traffic.

Data loss/ Theft- this is when data is lost due to a number of factors, including poor data migration, hardware (disk) failure, or disasters such as fires. Human factors can also cause data loss, either as deliberate actions or accidentally such as data theft.

Stage Two

Hardware and software failure- hardware failure is physical, whereas software failure is due to difficult to identify and analyze factors, such as bugs due to software quality or infections to software. Incompatibilities can also cause software failure.

Malicious attacks- these pertain to attacks such as phishing and other social engineering attacks where malicious entities trick users into installing or clicking links that cause infection or lead to suspicious false sites meant to give private data (Jang-Jaccard & Nepal, 2014).

Malware risks- Malware, which stands for malicious software, is a general term that refers to trojans, worms, viruses, and a myriad other malicious software that malicious entities utilize for nefarious purposes such as getting access to sensitive data. Malware can also be installed remotely, such as through phishing or exploiting existing vulnerabilities, or “manually” on a computer or the university enterprise IT system by the attackers, either through privilege escalation or physical access to gain remote administrator access (Jang-Jaccard & Nepal, 2014). These are serious risks, for instance ransom-ware that can deny the university access to its IT resources until a ransom is paid.

Disasters, including natural disasters- these refer to incidents such as fires that can destroy server rooms or natural disasters such as flooding or earthquakes that cause the data centers and server destruction, destroying the contained data.

Threat Analysis 

	University Asset
Risk	University Network	Databases (offline and cloud)	Applications	Data
Dos/ DDoS	(5 x 4) =20	(3 x 4) =12	(4 x 4 ) =16	(2 x 4) =8
Human error/ factors	(5 x 5) =25	(5 x 4) =26	(4 x 4 ) =16	(5 x 5) =28
Router risks	(5 x 5) =25	(3 x 3) =9	(2 x 4) =8	(4 x 4 ) =16
Data loss/ theft	(2 x 4) =8	(4 x 4 ) =16	(4 x 4 ) =16	(5 x 5) =25
hardware/ software failure	(5 x 4) =20	(5 x 4) =20	(4 x 4 ) =16	(5 x 5) =25
Malicious attacks	4.5 x 5) = 22.5	(5 x 4) =20	(5 x 4) =20	(5 x 5) =25
Malware risks	(4 x4) =16	4.5 x 5) = 22.5	(5 x 5) =25	(5 x 5) =25
Disasters such as fires, earthquakes	(5 x 5) =25	(5 x 5) =25	(4.5 x 4) = 18	(5 x 5) =25
	Rank	Color code	Risk Scores
	Very High		20-25
	High		15-20
	Medium		10-15
	Low		5-10
	Very Low		>5

Task 4: Recommendations recommendations that would have prevented Log4j Vulnerability exploitation

Log4j is a critical and easy to exploit vulnerability; while there is no permanent fix as yet, the following measures are recommended for mitigating its vulnerability and prevent or make exploitation difficult.

Disabling or Removing the Java Naming Directory Interface (JNDI)

The JNDI is a feature that makes it possible for additional Java objects to be loaded during runtime execution. Such objects can be remotely loaded from naming services over several protocols (Constantin, 2021). The exploits used include LDAP (Lightweight Directory Access Protocol), NDS (Novel Directory Services), DNS (Domain Name System), RMI (Remote Method Invocation), among others. Log4j performs JNDI lookups, inherently creating a vulnerability that can easily be exploited. By removing the JndiLookup class completely, the JndiLookup class implements the lookup function, and by modifying a vulnerable package instance and patching it (Constantin, 2021), the Log4j vulnerability is reduced or eliminated altogether.

Certain changes are made to the affected servers by exploiting the Log4j vulnerability itself in the applications and live system as a way of preventing further exploitation. This can be targeted to third party products from vendors such as packaged applications, and devices and appliances that are embedded that as-yet remain vulnerable or lack patches. Or those that have reached the end of life (Constantin, 2021); this is a form of ‘immunization’ to mitigate any future or inherent attacks. However, this protection is transient because exploits are based on Java and whenever JVM restarts, the changes will revert.

Task 3: Threat Analysis- Various Vulnerabilities Other Than Log4j Vulnerability

This entails the identification of all systems and applications that could be vulnerable to the exploits of Log4j. This also creates a limitation due to the overwhelming number of third-party applications that use Log4j.

The hot patching process entails deploying a patch to a process that is already running without having to restart the process. This relies on making use of JAVA’s ability to support byte-code modification on the fly when the code is already running in JVM (Java Virtual Machine). This is made possible through Java agents which are instrumentation API’s. Essentially, Java agents are just Java archive files (JAR) that can be attached dynamically during runtime to JVM. This can be done by patching all instances of log4j.org lookup, Apache logging core and JndiLookup instances lookup () methods (Constantin, 2021). This is achieved through returning a patched jndi lookup rather than making a connection to a remote server. Such an agent can be obtained from GitHub and be deployed to an existing Kubernetes pod as an ephemeral container to patch all applications already running in containers.

There are specific versions of Java that are vulnerable to the Log4j exploits and new patched versions have been developed that will help prevent known Java vulnerabilities. There are also patched versions of Log4j that have been developed as a response to known vulnerabilities, such as version 2.16.0 that has been patched. This helps eliminate code execution risk because earlier versions of Log4j remain vulnerable (University of Michigan, 2021). However, in the event updating to the latest version remains impossible, earlier mitigation measures can be used, such as disabling lookups.

Stage 3: Psychological Motivations and Insider Threat for A University Case Study

Task 5: Insider Threats

Insider threats refer to hostile actions committed against an organization by insiders that could be employees, contractors, or partners that have access to the organization’s assets and networks, resources, databases, or applications. These insiders could be past or present staff that can access the digital or physical assets and resources of the organization. In many cases, malicious attacks by insiders are well thought-out and deliberate acts, although there are instances where insiders unwittingly become malicious insiders and cause damage to the university. The motivations for insiders  to target their organizations vary, even though most breaches have financial and/ or material gain as the underlying motivator (Nurse et al., 2014). Breach can be caused by retaliation, espionage or a vendetta against the university or an employee of the institution, or simply through negligence. Insider threats are more widespread in certain areas, such as finance, healthcare, and government institutions, but they can damage any company’s information security, least of which is the university.

There are various types of insider threats:

Malicious insider- this is a contractor or employee at the university willfully looking to steal information or cause disruptions to the operations of the university. The malicious insider can be an opportunist deliberately seeking assets such as information or data to use for advancing their careers or to sell for monetary gain, or any other personal gain. A malicious insider can also be an employee that is a disenfranchised employee seeking for a way to inflict harm to the organization, penalize, or cause embarrassment to their superiors (Nurse et al., 2014).

Compromised insider- this is a staff or university contractor that has their machines or devices ‘compromised’ such as being infected with a worm or Trojan. Usually, this is achieved through social engineering and phishing scams, or where a user clicks an attachment or link that installs malware on their computer (Nurse et al., 2014). The compromised machine becomes the cyber criminal’s entry point as it is a loophole from which they can launch further attacks onto the university including infecting the entire network or escalate privileges.

Negligent insider- This is staff or contractor that fails to follow or adhere to laid down procedures such as vacating their work stations without logging out, clicking links or suspicious attachments to email even if they have been asked not to do so (Matthews, 2022). This does not only happen with regular staff, but is even more common among IT administrators and security experts. They know the risks but for some reason can forget to update router firmware, conduct deep network scans, change old passwords, encrypt databases, backup data or update the university security policies as regards information technology and associated resources (Nurse et al., 2014).

Possible Insider Threat that Could be at Work with Rationale

Having reviewed the various types of insiders at the university, the most serious risk is that of a negligent insider. This is because while there are malicious insiders and compromised insiders, often, the major IT security incidents originate from actions of omission or commission, without necessarily having the motive to actively cause damage and possibly loss to the organization. This threat has also been chosen because it tends to affect many people at the university, from the senior most executive, to the IT manager, and also the most junior staff at the university.  The IT staff are also guilty of being negligent, despite being charged with the role of ensuring security and integrity to the university IT resources and infrastructure. Research data indicates that almost two thirds (60%) or organizations globally experienced over 30 incidents of incidents relating to insiders every year (Matthews, 2022). Negligence accounts for most of the insider threats and incidents at 62% while under a quarter (23%) are attributed to criminal intent (malicious insider); compromised insiders that had their information or credentials stolen account for just 14% of insider incidents (Matthews, 2022). Due to the fact that insiders enjoy legitimate access to an organization, insider threats are very difficult to detect and deter. The employees still need to access various resources and services at the organization. Due to having privileged and authorized access, security products and systems will consider even suspicious activities as being. normal. As the insider threats become increasingly intertwined. For instance, to access sensitive and highly classified information, a user can employ lateral movement to hide their footprint and remain anonymous and protect their skin.

Stage 4: Security Assurance Architecture of A University Case Study

Task 6: Security Assurance Architecture Design

With respect to information technology, security architecture is a unified design for IT-assets security that incorporates the risks and requirements associated with a specific environment or scenario. The security architecture as well defines where and when the implementation of security controls should be undertaken. Usually, it is possible to replicate the security architecture design process. Such a framework attempts to provide an all-around security technology improvement, along with management capabilities for integration of control, management, and defense purposes by transferring ICS protection from security deployment rules to deployment security capabilities deployment. The security architecture below is developed to assure security for the university, and is premised on the security policy. 

The security assurance architecture is premised on cloud computing with a hybrid cloud, complete encryption for data at rest and in motion, and even the networks where SDN (software defined networking) is used in a cloud environment. SDN refers to a network architecture method that allows software programs to govern and design the network centrally and intelligently (Shin et al., 2016). Regardless of the underlying network technology, this enables operators to manage the whole network uniformly and holistically. The security policy is deployed organization-wide and includes training and awareness, and strict controls on what data each user can access. Access credentials are encrypted such that even if a malicious entity accesses the credentials, they cannot use the data because it is encrypted. The Cloud framework is used to ensure business process continuity, maintain data integrity, availability, and provide automated backups. Using SDN, the network is separated so that isolation can be done easily to handle issues like DDoS and DoS attacks on the network. Data security in the cloud is enhanced through data protection tools and limited external access. Data protection technologies that can be used in cloud computing include access control, authentication and identification, secure deletion, encryption, masking, and integrity checking. Even the admin server is incorporated into the hybrid cloud, so a hacker does not find it easy to access the server. Here is a firewall that has both software and hardware components for better threat detection and prevention. The security policy is strictly followed so that activities reviewing login credentials, updating hardware firmware, such as for routers, using anti-malware and updating them regularly, and reviewing the overall security policy are incorporated.

Comparison of New Proposed Architecture to the one in Task 2

Compared to the architecture in task 2, there is a huge difference (and improvement), the secured network used SDN to separate networks and guard against DoS and DdoS or any other network attacks, including malware (stop from spreading to other networks). Data is also fully encrypted at rest and in transit so even if an attacker gets access to the data, they cannot make out what it is or use it. The new architecture improves on the old one (in task 2) by having an organization-wide security policy that among others, defines when assessments and administrative actions like updating firmware, software, antiviruses, user access, and security policies. A physical firewall as well as software firewall is also added for enhanced safety, with a user credential manager, greatly improving on the architecture in task 2. A hybrid cloud architecture is also implemented in the new design to enhance security while ensuring business process continuity through using SaaS, PaaS, and IaaS models of cloud computing. This also cuts costs and greatly reduces hardware failure risks, compared to the task 2 architecture.

Task 7:  Information Security Policies

The ISP (Information Security Policy) sets processes and rules for members of an organization and develops a standard on acceptable use of the informational technology resources of an organization, including applications and networks to ensure data protection, integrity, availability, confidentiality, and fair use of IT resources (Alqahtani, 2017). The ISP is the first step towards ensuring security risks and breaches are mitigated and prevented, it is part a new cloud-based enterprise IS architecture that uses SDN (software defined networking), encryption, and secured hybrid cloud architecture with a dedicated firewall (physical and hardware). The ISP includes practices against Log4j vulnerabilities such as Disabling the JNDI, Temporary exploitation prevention by exploiting the vulnerability itself, Vulnerable Systems Identification, Hot-Patching through the use of a JAVA agent, and upgrading the version of Java and/ or Log4j. In addition, it entails following the ISP; the following is the security policy for the university;

University InfoSec (Information Security Policy)
Purpose	The purpose of this security policy is to create awareness and an overall approach to ensuring the university information security. It is also developed to aid in the detection and preempting of security breaches, for instance, misuse of data, resources, networks, computer systems, and applications. It also aims to maintain the university’s reputation and uphold legal and ethical responsibilities. It also aims at protecting the rights of all staff, students, partners, and associates and provides a basis for dealing with non-compliance.
Audience	This security policy is directed to the university administration, staff, both teaching and non-teaching, students, research partners, contractors, and alumni. External partners are out of the scope of this policy though.
Objectives of the information security	The following form the main objectives of the security policy; Confidentiality- Only authorized persons can and are allowed to access information assets, resources, and data. Availability- It is expected that users can access needed information, whenever they need such information. Integrity- Organization information, assets, and data should be accurate, complete, accessible, intact, while information technology systems must be in an operational state
Authority and policy on access control	Network security policy- Access to the university servers and networks by users is only possible via unique login credentials that must be authenticated, using such approaches as biometrics, smart identity cards, passwords, tokens, as defined by the network security policy. All attempts at log-in must be monitored and logged securely, ensuring vulnerabilities are not exploited; all systems should as well be tracked. Vulnerabilities in the Log4j, a software that executes third party codes for logging events and errors, but which predisposes it to security breaches should be secured as well. Hierarchy- The decision on what kind of data may be shared, with the entities the data can be shared with also being clearly defined; this decision rests with senior managers.  The security policy for senior managers may be different from those of junior staff, however, the level of authority for every organizational role’ over IT systems/ resources and data should be clearly defined by security policy.
Classification of data	The objective of classifying the data is to ensure persons having lower levels of clearance are not able to gain access to information that is classified as top secret, secret, or confidential. Further, unnecessary security procedures must be avoided at all costs for data that is less critical, such as public data, even while critical data is safeguarded. Data is classified according to categories as public, confidential, secret, and top secret. Data such as research information done with industry partners are classified as top secret, as are student academic information and data. Information such as remuneration or compensation for staff is secret, while departmental research documents, including student theses that are being undertaken are confidential. Sponsored research findings, completed research papers and theses are classified as public.
Operations and data support	Regulations for protecting data- organizational standards, requirements for compliance by the industry, best practices, and associated directives  must be adhered to strictly in handling sensitive and personal data. Encryption, anti-malware protection, and a firewall, are all requirements as stipulated by a number of IT-security standards. Data backups- All backed up data should be encrypted as per industry standards (AES 256) and the backup media stored securely; further, it is highly recommended for backup to be moved to the cloud. Physical backup devices should have the disks set to RAID level-6. Movement of Data- Only the most secure protocols should be employed during data transport. Any copied data or information transmitted over public networks or those stored in portable/ mobile devices should be encrypted fully. Data to be secured at rest as well as in transit.
Security awareness behavior	Training sessions to be undertaken with staff, along with sharing security information and soliciting input from staff. Mechanisms for security, including measures for protecting access, measures for protecting data, and classification of data that is sensitive. Social engineering attack threats (for example phishing) should be given special consideration and detection, prevention, and reporting such assaults should be the responsibility of employees. Clean desk policy—To safeguard computers and laptops, use cable locks. Shredding documents that are no longer needed is a good idea. Keep the printer area clean to avoid documents being accessed by the wrong (malicious) people Acceptable Internet Use policy – How users access the Internet should be clearly defined and restricted. Access and use of such sites as social media, YouTube, or similar websites must be defined in the policy, and should include blocking access such as using proxies.
Rights, responsibilities, and personnel duties	Staff to be appointed to undertake reviews of user access, change management, education and training, management of incidents, and periodic updating of the university security policy. Responsibilities and roles are defined clearly as part of the university security policy

The framework below indicates the developed InfoSec policy for the university.

Based on the ISP, the an improved security assurance architecture is developed as shown below;

References

Alqahtani, F. (2017). Developing an Information Security Policy: A Case Study Approach. Procedia Computer Science, 124, 691-697. https://doi.org/10.1016/j.procs.2017.12.206

Center for Internet Security. (2022). Alert: Log4j Zero-Day Vulnerability Response. CIS. Retrieved 9 March 2022, from https://www.cisecurity.org/log4j-zero-day-vulnerability-response.

Constantin, L. (2021). 4 ways to properly mitigate the Log4j vulnerabilities (and 4 to skip). CSO Online. Retrieved 9 March 2022, from https://www.google.com/amp/s/www.csoonline.com/article/3645348/how-to-properly-mitigate-the-log4j-vulnerabilities.amp.html.

Goel, S. (2022). 7 Detection Tips for the Log4j2 Vulnerability. Exabeam. Retrieved 9 March 2022, from https://www.exabeam.com/incident-response/7-detection-tips-for-the-log4j2-vulnerability/.

Jang-Jaccard, J., & Nepal, S. (2014). A survey of emerging threats in cybersecurity. Journal Of Computer And System Sciences, 80(5), 973-993. https://doi.org/10.1016/j.jcss.2014.02.005

Luo, F., Jiang, Y., Zhang, Z., Ren, Y., & Hou, S. (2021). Threat Analysis and Risk Assessment for Connected Vehicles: A Survey. Security And Communication Networks, 2021, 1-19. https://doi.org/10.1155/2021/1263820

Matthews, T. (2022). What is an Insider Threat? Definition, Detection & Prevention. Exabeam. Retrieved 9 March 2022, from https://www.exabeam.com/ueba/insider-threats/.

National Cyber Security Center. (2022). Log4j vulnerability – what everyone needs to know. National Cyber Security Center. Retrieved 9 March 2022, from https://www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone-needs-to-know#:~:text=Last%20week%2C%20a%20vulnerability%20was,infect%20networks%20with%20malicious%20software.

Nurse, J., Buckley, O., Legg, P., Goldsmith, M., Creese, S., Wright, G., & Whitty, M. (2014). Understanding Insider Threat: A Framework for Characterising Attacks. 2014 IEEE Security And Privacy Workshops. https://doi.org/10.1109/spw.2014.38

Samanta, S. (2021). Log4J vulnerability in detail and the bigger picture. Medium. Retrieved 9 March 2022, from https://medium.com/geekculture/log4j-vulnerability-in-detail-and-the-bigger-picture-db49f749009.

Shin, S., Xu, L., Hong, S., & Gu, G. (2016). Enhancing Network Security through Software Defined Networking (SDN). 2016 25Th International Conference On Computer Communication And Networks (ICCCN). https://doi.org/10.1109/icccn.2016.7568520

Tan, A. (2022). Top three questions about the Log4j vulnerability. ComputerWeekly.com. Retrieved 9 March 2022, from https://www.computerweekly.com/news/252512071/Top-three-questions-about-the-Log4j-vulnerability.

Torres-Arias, S. (2021). What is Log4j? A cybersecurity expert explains the latest internet vulnerability, how bad it is and what’s at stake. The Conversation. Retrieved 9 March 2022, from https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896.

University of Michigan. (2021). Update Apache Log4j utility to address zero-day vulnerability / safecomputing.umich.edu. Safecomputing.umich.edu. Retrieved 9 March 2022, from https://safecomputing.umich.edu/security-alerts/update-apache-log4j-utility-address-zero-day-vulnerability.

Wangen, G., Shalaginov, A., & Hallstensen, C. (2016). Cyber Security Risk Assessment of a DDoS Attack. Lecture Notes In Computer Science, 2, 183-202. https://doi.org/10.1007/978-3-319-45871-7_12