Posted: June 13th, 2022

Project Final Report

DO THE FILE CALLED ” PROJECT FINAL ”
USE THE PROJECT DESIGN TO KNOW ABOUT WHAT TO WRITE
com
ATTACHED FILE(S)
Cyber Security Department
Graduation Project(407422)
Project Title Here ….
Advisor: Dr. Ahmed Ali Otoom
Submitted By:

Student Name

Student ID

Name 1

Id1

Term:

Date:
23 | Page
Table of Contents
1.

Introduction

5
2.

Problem Statement

5
3.

Background

5
4.

Requirements and specification

5
4.1.

User

Groups

5
4.2.

Functional Requirements

6
4.3.

Non-Functional Requirements (NFRs)

7
5.

System Design

10
5.1.

Solution

Concept

10
5.2.

Proposed System Architecture

11
5.2.1

Alternative 1

11
5.2.2

Aternative 2

11
5.2.3

etc

11
5.2.4

Production and Staging Environments

13
5.3.

Component Design

13
5.3.1

Hardware Components

13
5.3.2

Software Components

13
5.3.2.1

User Interface – Web client

13
5.3.2.2.

Use

Case

Description

13
5.3.2.3.

Back-End Database

14
4.4.

Design Evaluation

15
6.

Implementation

16
6.1

System Implemented Architecture

16
6.1.1.

Tier Two – Application Server and Web-Server

16
6.1.1.1.

The Web-Server

16
<>

16
6.2

Access Levels

16
6.3

System Services or Functionalities

16
7.

Testing, Analysis and Evaluation

17
7.1

Testing Methodology

17
7.2

System Analysis and Evaluation

17
7.3

Test Execution and Test Results

17
7.3.1

Integration Testing

17
7.3.2

Functional Testing

17
7.4

Examples on testing

18
7.4.1

Check password Strength

18
<< this might be an example of testing password strength>>

18
8.

Issues, Engineering Tools and Standards

18
8.1.

Issues

18
8.2.

Engineering Tools and Standards

18
9.

Teamwork

18
10.

Conclusion

20
10.1.

Conclusion

20
10.2.

Future Work

20
Appendix A: Test Plan

21
Appendix B: Progress Report-Teamwork

22
Appendix C- Attachments and Source Code

24
References

25
19 | Page
List of Figures
Figure 5Use-Case Diagram

12
Figure 7 High Level Implementation Architecture

15
Figure 14 Security Domains Access Levels

15
Figure 59 Password Complexity

17
List of Tables
Table 1 User Groups

5
Table 2 Non Functional Requirements

7
Table 3 System Use Case Description

12
Table 4 Comparing On-Cloud and On-Site Options

14
Table 7 Team responsiblites, Contributions, and expertise

18
1.
Introduction
<>
2.
Problem Statement
<>
3.
Background
<>
4.
Requirements and specification
4.1.
User Groups
Table 1 lists the Users or groups of Users who will be interested in using thesystem
Table 1 User Groups

Ser

Name ( user or group of
users)

Role
4.2.
Functional Requirements
The functional requirements are features or functions that we are going to implement in the solution …
4.3.
Non-Functional Requirements (NFRs)
The non-functional requirements define the quality and performance attributes of the solution
Table 2 Non Functional Requirements

NFR Type

Requirements

Implications on Design
and/or operation

Example Availability

· The solution will be accessed by users during business hours and outside of business hours.
· The system must be available up and running 24/7 * 365. In all cases, availability should be at least equal to 0.999
·

Possible solution or workaround

Scalability

·

Possible solution or workaround
·

5.
System Design
5.1.
Solution Concept
< The major solution concept for solution is having it built and deployed as a web-based application.etc

5.2.
Proposed System Architecture
<< proposed architecture>>
5.2.1
Alternative 1
5.2.2
Aternative 2
5.2.3 etc
Which alternative your team has chosen and why? Performance, cost, simplicity , other factors

5.2.4
Production and Staging Environments
Example << explain if you need this staging environment or not >>
5.3.
Component Design
The system will consists of << off-the-shelf hardware component>> <> self developed << explain>>
5.3

5.3.1 Hardware Components
1.

2.

3.

4.

4.1.

4.2.

4.3.

4.3.1.

5.3.2
Software Components
5.3.2.1 User Interface – Web client
· Based on the system requirements listed in the previous sections, we present the system use case diagram as shown inFigure x
Figure 5Use-Case Diagram
5.3.2.2. Use Case Description
For each of the identified use cases, we provide, in Table 3, a more detailed description. Use case description shows how users will interact with the solution. It describes, from a user’s point of view, the solution’s behavior as it responds to user requests.
Table 3 System Use Case Description
5.3.2.3.
Back-End Database
Does the system use a back-end database, file system explain and provide the required data models
4.4.
Design Evaluation
Table 4 shows a comparison between the On-Cloud Option and the On-Site Option
Where do you want to host your system << on-cloud vs on-site and why>>
Table 4 Comparing On-Cloud and On-Site Options
6.
Implementation
In order to facilitate the understanding of the system that contains several major components, we start with high level architecture. The source code for this project is provided in Appendix C.
6.1 System Implemented Architecture
Figure 7 shows the major components of the system.
Figure 7 High Level Implementation Architecture
2

3

4

5

6

6.1

6.1.1

6.2
Access Levels
6.2

6.3

6.1.
The solution pays attention to security. The solutioncategories the users into << how many>> different categories.
<< explain >>.
Figure 14 Security Domains Access Levels
6.3
System Services or Functionalities
<>

7.

Testing, Analysis and Evaluation
7.1Testing Methodology
<< the following is an example of a testing methodology you can use your own>>
Our team has developed the test plan shown in Appendix A. We have built acceptance test scenarios for the system features that we have already identified in the project design phase. For each feature, we have provided the test description and expected outcome for all of the success and alternate scenarios. After we completed the development phase, the test plan is executed. We record and resolve each test outcome for each test case.
· Target System: <>
· Features and functions:
· Test approach:.
· Key process: if bugs are discovered we will
· Bookkeeping and Documentation: We are going to use.
· Test Schedule:
· Exit criteria: The test will be considered complete
7.2
System Analysis and Evaluation
<< how to test non-functional requirements>>
.
7.3Test Execution and Test Results
The execution performed according to the already identified methodology and carried against the test plan.
<>
7.3.1
Integration Testing
After modular testing, we moved to the integration testing.
<< explain how you performed integration testing>>
7.3.2
Functional Testing
<< provide examples on function testing>>
We identified the features of the system in the design document so we have went through each feature to make sure it is already satisfied by the delivered solution. The functional testing used manual exploratory testing in which we run each required scenario and evaluate the results.

7.4
Examples on testing
7.4.1
Check password Strength
<< this might be an example of testing password strength>>
The system is programmed to check for password strength. We have decided to have the password strength fair; that is being longer than 8 characters.
Figure 59 Password Complexity
8. Issues, Engineering Tools and Standards
8.1.Issues
<>

8.2.Engineering Tools and Standards
<>
9. Teamwork
Without teamwork we would not be able to fulfill the requirements of this demanding project. Our team was able to work well together.
<>
Appendix B. For each task listed in the appendix, we, we show owner, description, timespan, and status. Status will have the following values: in progress, completed, waiting for another task or delayed.
Table 7shows the responsiblites, Contributions, and expertise of each of the team members.
Table 7 Team responsiblites, Contributions, and expertise

Student

Responsiblities

Contribution

Expertise

Student 1

·

Student 2

·

Student 3

·

Student 4

·
10.
Conclusion
In this section, we list the conclusion and future work respectively.
10.1. Conclusion
We have reached the following conclusions
10.2.
Future Work
We believe there are still rooms for future advancements of this proposed solution. We list few hints of what can be done differently in a similar project.
Appendix A: Test Plan

Solution Name

Team Leader:

Student 1

Student 2

Student 3

Test
No. ID

Related Feature

Pre-conditions

Test Description (steps)

Expected Outcome

Test Outcome

1

Register

Not Applicable

1. user clicks on the “Register” button
2. user Fills valid data for all of:Id, name, email, phone number, and password.
3. user submit the form

System Database will create a record for the user with the entered data

20 | Page
Appendix B: Progress Report-Teamwork
Table 5 Progress Report
<< This is an example>> use your own>>

ID Task Name / Owner Timespan – Week # Status Mitigation Action
Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Risk Likelihood Impact Severity
of the Risk if the based on Occurring Risk Impact
occurs and likelihood

1.0

Project Plan

Team

X

X

X

Completed

5.1

ER Diagram

Project ERD is incomplete

Low

High

Moderate

Completed

Make Team review session
Cross check with Proj. Requirements

5.2

Use Case Diagram

Use cases do not reflect
actual requirements

Low

Moderate

Low

Completed

Review with someone that can represent stakeholders
22 | Page

8.3

Final Report

Team

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Do not complete the report on time

Moderate

High

High

Completed

Team will reflect changes to the Final Report as we go. By the deadline Team should have the major parts of the final report already
in place
Appendix C- Attachments and Source Code
In this appendix we list the source code of different pieces of the solution where applicable.
References
[1] M. A. Gottfried, “Chronic Absenteeism and Its Effects on Students’ Academic and Socioemotional Outcomes,” J. Educ. Students Placed Risk, vol. 19, no. 2, pp. 53–75, Apr. 2014, doi: 10.1080/10824669.2014.962696.
24 | Page
Cyber Security Department
Project DESIGN(407422)
Protection against ‘EternalBlue’ vulnerability
Advisor: Dr. Ahmed Ali Otoom
Submitted By:

Student Name

Student ID

Name 1

Term:

Date:
Page 3 of 14
Table of Contents
1.

Introduction

3
1.1

Statistics on Cyber Vulnerabilities

4
1.2 Project Impact

5
2.

Problem Statement

6
3.

Background

6
4.

Requirements and Specifications

7
5.

System Design

9
5.1.

Solution Concept

9
5.2.

Architecture

10
5.3.

Component Design

11
5.4.

System Integration

11
6.

Progress

12
1. Introduction
Cybersecurity vulnerability is any weakness within an organization’s information systems, internal controls, or system processes that can be exploited by cybercriminals. Through points of vulnerability, cyber adversaries are able to gain access to your system and collect data. With regard to your organization’s overall security posture, Cybersecurity vulnerabilities are extremely important to monitor as gaps in a network can lead to a full-scale breach of a system.
Vulnerabilities differ from cyber threats in that they are not introduced on a system; they are there from the beginning. Very rarely are cyber vulnerabilities created as a result of actions taken by cybercriminals, instead, they are usually caused by operating system flaws or network misconfigurations. Conversely, cyber threats are introduced as a result of an outside event such as an employee downloading a virus or a social engineering attack.
There is a huge range of possible vulnerabilities and potential consequences to their exploits. The US government’s National Vulnerability Database (NVD) which is fed by the Common Vulnerabilities and Exposures (CVE) list currently has over 150,000 entries. One well-known example of Cybersecurity vulnerability is the CVE-2017-0144 Windows weakness that opened the door for WannaCry ransom ware attacks via the EternalBlue exploit. Another infamous case is the Mirai botnet that spread through the exploitation of multiple flaws.
Once vulnerabilities are discovered, developers typically work fast to release an update, or “patch.” Ideally, all users install the update before attackers have a chance to exploit the vulnerability. But the reality is that in many cases, attackers strike quickly to take advantage of a known weakness. Plus, even when a patch is released, slow implementation of updates means that attackers can exploit vulnerabilities years after they have been discovered.
Unpatched vulnerabilities can be exploited by cybercriminals to carry out attacks and steal valuable data. Similar to system misconfigurations, cyber adversaries will probe networks looking for unpatched systems they can compromise. To limit this risk, it is important to establish a patch management schedule so that all new system patches are implemented as soon as they are released. Eternal Blue is a common type of unpatched vulnerability.
1.1Statistics on Cyber Vulnerabilities
The following statistics are derived from National Vulnerability Database (NVD) analysis on vulnerabilities.
i. Almost 22,000 vulnerabilities were published in 2021
The NVD database holds 21,957 vulnerabilities published in 2021. This is a higher number than in previous years (18,362 in 2020, 17,382 in 2019, and 17,252 in 2018).
ii. Half of internal-facing web application vulnerabilities are considered high risk
Edgescan’s 2021 Vulnerability Statistics Report analyzed the severity of web application vulnerabilities. It found that 50 percent of internal application vulnerabilities are considered high or critical risk. It also found that 32 percent of vulnerabilities in internet-facing applications are considered high or critical risk.
iii. Organizations with more than 100 staff see more high or critical-risk vulnerabilities
Edgescan’s report also broke down the severity of vulnerabilities according to company size. Smaller companies with 100 employees or fewer saw the lowest portion of medium, high, or critical-risk vulnerabilities (five percent total). Companies with 10,000+ employees see the largest portion of medium and critical-risk vulnerabilities while medium-sized organizations with 101–1,000 employees saw the largest portion of high-risk vulnerabilities.
iv. 31% of companies detected attempts to exploit software vulnerabilities
A 2020 report from Positive Technologies found that almost one-third of detected threats involve software exploit attempts. According to the report, “More than half of attempts involved vulnerability CVE2017-0144 in the implementation of the SMBv1 protocol. This is the same vulnerability leveraged by the infamous WannaCry ransom ware, and for which a patch was released back in 2017. But attackers have kept it in their arsenals as they search for computers that have not been updated in the last 3.5 years.”
1.2 Project Impact
The project seeks to research, define and recommend measures towards protection of computers and systems against cyber vulnerabilities with focus on eternal blue. The project is anticipated to have the following positive impact both locally and globally.
i. Protection from theft of corporate information
ii. Protection of financial information such as bank details or payment card details which could rather be stolen without knowledge on eternal blue prevention.
iii. Prevents theft of money
iv. Prevents disruption to trading. This may include inability to carry out transactions online.
v. Prevention from loss of business or contract.
The project might have some negative impact to the society. While some measure are meant to prevent eternal blue, they may be misused. For instance, antivirus programs purchased by organization to be installed on organization computers may be used on personal computers. Rights and privileges may be abused by staff as granted by the system administrators with advice from line management.
2. Problem Statement
The project seeks to increase awareness amongst users on this exploit – eternalblue and recommend measures on how they can protect their data and information from data breach through eternalblue. A detailed description of how the vulnerability can be exposed will be done with remedies on how to counter and protect devices and systems.
3. Background
Many researchers have broadly examined each contributor’s role in the construction and spread of the virus that contributed to such a destructive cyber-attack. A wide net of blame can be cast on Microsoft’s unsecure protocol, Russia’s use of the malware, and the business I.T. professionals within organizations that failed to apply the available patch to all of their compromised systems, but when analyzing the role of the NSA, journalists mainly focus on what factors contributed to the data breach and what measures could be taken to prevent future leaks. They conclude that the NSA’s failure to retain its secrets, including its hacking tools, is the area of root concern where the organization must be held accountable.
Greenberg details the hypocrisy in how the United States redirects the blame on previous administrations and other foreign nation-state actors, as with attributing the WannaCry ransom ware attack to North Korea, without looking introspectively. He calls attention to the workplace procedures that allowed two NSA staffers to carry home large collections of highly classified hacking tools. Antivirus software developed by Kaspersky, a Russian security firm, was reportedly used on one of the staffers’ personal computers, meaning the malware crafted by the NSA was uploaded to the corporation’s servers and remained there for some unknown duration of time. The reporter also mentions the vagueness in wording and the lack of transparency in the implementation of the White House’s Vulnerabilities and Equities Process, a document meant to guide which vulnerabilities are reported to the associated vendors and which are kept secret to gather foreign intelligence (Greenberg, 2017).
Shane, Perlroth, and Sanger’s reporting covers the NSA as a victim within this network robbed entirely of any sense of morale, with the Shadow Brokers as the perpetrators responsible. This framing is apparent while referring to the case as “one of the worst security debacles ever to befall American intelligence” and far exceeding the damage caused by Edward Snowden. They look at how members of the NSA’s internal hacking group, Tailored Access Operations (T.A.O), have been impacted by the revelations, with some members leaving the organization and others having to cancel trips abroad out of fear. The reporting then continues to describe a hostile workplace now plagued by polygraphs and suspensions with difficulty retaining talent. The journalists also cover additional victims of the Shadow Broker’s actions that led to the disruption of business internationally including the millions of computers locked by ransom ware, companies that experienced complete data loss, and hospitals in Indonesia, Britain, and even Pennsylvania that were forced to reject patients (Shane et al., 2017).
4. Requirements and Specifications
Functional requirements describe a particular behavior of function of the system when certain conditions are met. The solutions functional requirements are;
i. Adherence to administrative rules – users will need administrator password to install any program to the system.
ii. Authentication – access to any system will require two-factor authentication (2FA).
iii. Authorization level – an authorization hierarchy will be established to guide on rights and privileges for system users.
iv. Legal and regulatory requirements – all programs used will need to be authentic. No cracked programs to be installed in the system.
v. Audit tracking – the system will be able to keep audit trail for all users.
Non-functional requirement essentially specifies how the system should behave and that it is a constraint upon the systems behavior. The system non-functional requirement will include;
i. Reliability – up to 97% uptime.
ii. Security – high ability to prevent security breaches.
iii. Data integrity – data access will be on need to know basis.
iv. Usability – ease to use among staff
Technical specification document provides developers with clearly defined goals and direction, and ultimately allows for better management of stakeholder expectations. They will be categorized into hardware and operating system.
i. Hardware
a. 4 Cores, 2.8-3.0 GHz each (2.8 GHz minimum speed)
b. 4 GB RAM per core
c. Standard hard drive, 100 GB free
d. Network connectivity
ii. Operating System
a. Oracle Enterprise Linux 4 Update 7 or greater, 64-bit
b. Oracle Enterprise Linux 5 Update 3 or greater, 64-bit
c. Oracle Enterprise Linux 6 64-bit
d. Oracle Solaris 10 (x86)
e. Red Hat Enterprise Linux 4.0 Update 7 or greater, 64-bit
f. Red Hat Enterprise Linux 5.0 Update 3 or greater, 64-bit
5. System Design
The purpose of System Design is to create a technical solution that satisfies the functional requirements for the system. At this point in the project lifecycle there should be a Functional Specification, written primarily in business terminology, containing a complete description of the operational needs of the various organizational entities that will use the new system. The challenge is to translate all of this information into Technical Specifications that accurately describe the design of the system, and that can be used as input to System Construction.
5.1. Solution Concept
The following chart illustrates all of the processes and deliverables of this phase in the context of the system development lifecycle. The Functional Specification produced during System Requirements Analysis is transformed into a physical architecture. System components are distributed across the physical architecture, usable interfaces are designed and prototyped, and Technical Specifications are created for the Application Developers, enabling them to build and test the system.
5.2. Architecture
The architecture of a system describes its major components, their relationships (structures), and how they interact with each other. Architecture serves as a blueprint for a system. It provides an abstraction to manage the system complexity and establish a communication and coordination mechanism among components. It defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security.

5.3. Component Design

Component

Off shelf/Custom

Justification/Alternative

Processor – 2.8-3.0 GHz

Off the Shelf

Ryzen 5, 7

RAM – 4 GB per core

Off the Shelf

n/a

Standard Hard drive

Off the Shelf

256 GB Solid State Drive

Oracle Enterprise Linux 4

Custom

To be able to autonomously work with the specified hardware requirements

Oracle Enterprise Linux 7

Off the Shelf

Oracle Solaris 10 (x86)

Custom

To be able to autonomously work with the specified hardware requirements
5.4. System Integration
System integration (SI) connects multiple subsystems so they can function together and share information. From internal operations to communicating with third parties, data transparency is essential for efficient execution. In other words, businesses with several software systems can use an integrator to create a centralized sharing network that gives users access to all information.
Implementing an integration solution eliminates the need to manually enter data across various software, saving time, labor costs, and reducing the risk of human error. This open network of data sharing enhances communication throughout a company’s departments, optimizing operational efficiency.
The system will use standard interfaces between components. Top down integration will be used in roll out process. Implemented elements or aggregates will be integrated in their activation or utilization order.
i. Availability of a sequence diagrams and early detection of architectural faults, definition of test cases close to reality, and the re-use of test data sets possible.
ii. Many stubs/caps will be created; difficult to define test cases of the leaf-implemented elements (lowest level).
iii. Start from the implemented element of higher level; implemented elements of lower level are added until leaf-implemented elements.
6. Progress

Task

Owner

Description

Timespan

Status

Initial meetings- Prepare for system design

Project Manager

Established Team and
Environment for System
Design. This will be done through interviews and side walk through.

The whole of first week
4th April 2022 to 8th April 2022

Complete

Project plan – define Technical Architecture

Technical Lead/Architect

Technical set up through Document Gathering and Reviews
Role/Authorization Analysis

6th April 2022 to 11th April 2022

Completed

Product and technical specifications

Technical Lead/Business representatives/Business Analyst

Function decomposition Expressing Logic: Pseudo Code,
Structured English, Object
Oriented Logic
Operational Requirements
Assessment
System Load Analysis
Business Impact Analysis
Potential Problem Analysis
Training Needs Decomposition

11th April 2022 to 15th April 2022

Ongoing – team did work on 15th to observe Easter holidays.

Implementation – prototype system components

Data/Process Modeler

Iterative Prototypes/Reviews
Presentations
GUI/Report Development Tools to design prototype and proof of concept results.

18th April 2022 to 21st April 2022

Pending

Implementation – creating physical database

Developers

Develop Databases and System Files

23rd April 2022 to 4th May 2022

Awaiting for prototype s

References
Blanchard, B. & Fabrycky, W. (2010). Systems Engineering and Analysis (5th Ed.), New Jersey: Prentice Hall.
Ding, A., De Jesus, G., & Janssen, M. (2019). Ethical hacking for boosting IoT vulnerability management: a first look into bug bounty programs and responsible disclosure. Proceedings of the Eighth International Conference on Telecommunications and Remote Sensing – ICTRS ’19
Warren, Tom (April 15, 2017). Microsoft has already patched the NSA’s leaked Windows hacks. The Verge.
Greenberg, A. (2017, December 19). Hold North Korea accountable for WannaCry—And the NSA, too. Wired. Retrieved March 1, 2020, from https://www.wired.com/story/koreaaccountable-wannacry-nsa-eternal-blue/.
Greenberg, A. (2018, August 22). The untold story of Not Petya, the most devastating cyber-attack in history. Wired. Retrieved March 1, 2020, from https://www.wired.com/story/notpetyacyberattack-ukraine-russia-code-crashed-the-world/.
Shane, S., Perlroth, N., & Sanger, D. E. (2017, November 12). Security breach and spilled secrets have shaken the N.S.A. to its core. The New York Times. Retrieved March 1, 2020, from https://www.nytimes.com/2017/11/12/us/nsa-shadow-brokers.html.
Prepared by Dr. Muhammad AkhlaAKHLAQ@uohb.edu.sa Page 2 of 14

Expert paper writers are just a few clicks away

Place an order in 3 easy steps. Takes less than 5 mins.

Calculate the price of your order

You will get a personal manager and a discount.
We'll send you the first draft for approval by at
Total price:
$0.00