The document provides an overview of a computer security course. The course aims to teach students to examine and apply fundamental computer security techniques, identify security issues, and mitigate threats. The course objectives cover managing security, foundations of computer security, identification and authentication, access control, and network security. Key concepts discussed include security policies, risk analysis, threats, vulnerabilities, and security metrics. The document provides details on these topics to outline the content students will learn throughout the course.

1. ELECTRICAL & ELECTRONICS ENGINEERING, FOURAH BAY COLLEGE,
UNIVERSITY OF SIERRA LEONE
Lecture-01
EENG-524 Second Semester 2023
May 12, 2023

2. COURSE OBECTIVES
Course Aim:
❑ The overall aim of this course, is to teach student to examine and apply the fundamental
techniques of computer security, identify and explain potential security issues and how to
mitigate the threats.
Course Objectives:
❑ Upon successful completion of this course, students should be able to meet the program
outcomes listed below:
1. Managing Security:
▪ On Security
▪ Attacks and Attackers
▪ Security Management
o Security Policies
o Measuring Security
o Standards
▪ Risk and Threat Analysis
o Assets
o Vulnerabilities
o Threats
o Risks
o Countermeasures
2. Foundations of Computer Security:
▪ Definitions
o Security
o Computer Security
o Confidentiality
o Integrity
o Availability
o Accountability
o Non-repudiation
▪ Fundamental Dilemma
▪ Data vs. Information
▪ Principles of Computer Security
▪ The Layer Below

3. COURSE OBECTIVES
3. Identification and Authentication
▪ Username and Password
▪ Bootstrapping Password Protection
▪ Guessing Passwords
▪ Phishing, Spoofing, and Social Engineering
▪ Password Caching
▪ Protecting the Password File
▪ Single Sign-on
▪ Alternative Approaches
4. Access Control:
▪ Authentication and Authorization
▪ Access Operations
▪ Ownership
▪ Access Control Structures
o Access Control Matrix
o Capabilities
o Access Control Lists
▪ Intermediate Controls
5. Network Security:
▪ Threat Models
▪ Communication Models
▪ Protocol Design Principles
▪ IPSec
▪ SSL/TLS
▪ DNS
▪ Firewalls
▪ IDS
▪ Honeypots

4. On Security
❑ New security challenges arise when new or old technologies are put to new use.
❑ Security is a journey, not a destination. Computer security has been travelling
for several decades, and counting. On this journey, the challenges faced have kept
changing, as have the answers to familiar challenges.
❑ A secure system is one which does not exist.
▪ An almost secure system is one which is locked up in a nuclear bunker within
an air locked titanium safe and disconnected from anything else in the
world……and even such a system is not 100% secure!
❑ It is not about achieving complete security but it is about minimising risk to systems
both from a technical as well as social point of view
❑ Communications security, however, only solves the easy problem, i.e. protecting
data in transit. It should have been clear from the start that the real problems resided
elsewhere
❑ The typical end system was a PC, no longer stand-alone or connected to a LAN, but
connected to the Internet.

5. On Security
❑ Connecting a machine to the Internet has two major ramifications.
▪ The system owner no longer controls who can send inputs to this machine;
▪ the system owner no longer controls what input is sent to the machine.
❑ Original focus on multiuser systems but today focus on ubiquitous end systems.
❑ Systems interconnected by networks danger of possible attacks from ‘un-trusted’
nodes.
❑ The deployment of security measures (and of information technology-IT in general)
is a management decision.
❑ Technical security measures have to work hand in hand with organizational measures
to be effective.
❑ Management decisions should be underpinned by some analysis of current risks and
threats.

6. Attacks and Attackers
❑ When credit card payments over the Internet were first considered, it was thought essential that
the traffic between customer and merchant should be protected.
❑ Basic Internet protocols offer no confidentiality so parties located between customer and
merchant could capture card numbers and use them later for fraudulent purchases.
❑ SSL was developed by Netscape to deal with this very problem in the mid 1990s. However,
the real danger may lurk elsewhere.
❑ Identity theft, i.e. using somebody else’s ‘identity’ (name, social security number, bank
account number, etc.) to gain access to a resource or service, exploits a weakness inherent
in services that use non-secret information to authenticate requests
❑ Vulnerabilities in software processing external user input, such as Internet browsers or mail
software, may allow external parties to take control of a device. Attackers may corrupt data on
the device itself or use it as a stepping stone for attacks against third parties.
❑ Worms and viruses make use of overgenerous features or vulnerabilities to spread widely and
overload networks and end systems with the traffic they generate. The Internet worm of
November 1988 is an early well-documented example of this species
❑ Denial-of-service attacks (DOS) against specific targets have started to occur since
the late 1990s
❑ Resilience against DoS attacks has become a new criterion in the design of security
protocols.

7. Attacks and Attackers
❑ In the scenarios above the attacks came from the outside. Keeping the enemy outside the castle
walls is a traditional paradigm in computer security.
❑ However, statistics on the sources of attacks often show that attacks from insiders account for a
majority of incidents and the largest proportion of damage.
❑ Insider fraud remains a considerable concern in organizations and in electronic commerce
transactions.
❑ Not every attacker is motivated by a desire for money.
▪ Redundant Employees may want to exact revenge on their former employer.
▪ Hackers demonstrate their technical expertise and draw particular satisfaction from
defeating security mechanisms that have been put in their way.
▪ Political activists may deface the websites of organizations they dislike.
❑ There is similar variance in the expertise required to break into a system. In some cases insider
knowledge will be required to put together a successful plan of attack. In this respect, social
engineering may be more important than technical wizardry.
❑ Hassling mobile operators on the phone to give the caller the password to a user account is a
favourite ploy.
❑ Some attacks require deep technical understanding. Other attacks have been automated and can
be downloaded from websites so that they may be executed by script kiddies who have little
insight into the vulnerabilities or features the attacks they are exploiting.

8. Security Management
❑ Security practitioners know that ‘security is a people problem’ that cannot be solved by
technology alone.
❑ The legal system has to define the boundaries of acceptable behaviour through data protection
and computer misuse laws.
❑ Responsibility for security within organizations, be they companies or universities, resides
ultimately with management.
❑ Users have to cooperate and comply with the security rules laid down in their organization.
❑ Correct deployment and operation of technical measures is also part of the overall solution.
❑ Protecting the assets of an organization is the responsibility of management. Assets include
sensitive information such as product plans, customer records, financial data, and the IT
infrastructure of the organization.
❑ At the same time, security measures often restrict members of the organization in their
working patterns and there may be a potential temptation to flout security rules. This is
particularly likely to happen if security instructions do not come from a superior authority but
from some other branch of the organization.
❑ It is strongly recommended to organize security responsibilities in an organization in a way that
makes it clear that security measures have the full support of senior management.
❑ A brief policy document signed by the chief executive that lays down the ground rules can
serve as a starting point.

9. Security Management
Security Policies
❑ Security policies are a core concept in computer security, it is a statement that
defines the security objectives of an organization; it has to state what needs to be
protected; it may also indicate how this is to be done. For example,
▪ A policy may regulate access to company premises and documents;
▪ A policy may stipulate who is authorized to approve commercial transactions on
behalf of the company, or stipulate that certain transactions must be signed off by
more than one person.
▪ A policy may define to what extent employees are allowed to use the company IT
system for private purposes (web surfing, email),
▪ A policy may declare that senders of offensive emails will face disciplinary
action.
▪ A policy may state which user actions the employer is allowed to monitor.
▪ A policy may define password formats and renewal intervals.
▪ A policy may state that sensitive emails must be encrypted.
▪ It may state that users have to give consent when personal data are collected.

10. Security Management
❑ A policy also has to explain how the objectives are to be met. This can be done at various levels
including.
Measuring Security
❑ Measuring security is difficult and measures only exist for some aspects of security.
❑ To convince management of the benefits of a new security mechanism, it is important to measur
the security of the system before and after introducing the mechanism
❑ The terms security measurement and security metric are used in this context, but there is no
common agreement on their exact meaning.
1. Organizational security policy: The set of laws, rules, and practices that regulate how an
organization manages, protects, and distributes resources to achieve specified security
policy objectives.
❑ Within an IT system, organizational policies can be supported by technical means.
2. Automated security policy: The set of restrictions and properties that specify how a computing
system prevents information and computing resources from being used to violate an
organizational security policy.
❑ Automated policies define access control lists and firewall settings, stipulate the services
that may be run on user devices, and prescribe the security protocols for protecting
network traffic.

11. Security Management
❑ There are two defined phases for measuring security
1. Values for various security-relevant factors can be obtained. According to SANS
(SysAdmin, Audit, Network, and Security), obtaining a value for such a factor is a
security measurement. Some values can be established:
o Objectively, e.g. the number of open network ports, whether the latest patch has
been installed for a software product, or the privilege level under which a service
program is running.
o Other values are subjective, e.g. the reputation of a company or the security
awareness of its employees.
2. A set of measurements may be consolidated into a single value that is used for
comparing the current security state against a baseline or a past state. According to
SANS, the values used by management for making security comparisons are called
security metrics.
❑ Ideally, security metric gives a quantitative result that can be compared to other results,
not just a qualitative statement about the security of the product or system being
analyzed.
▪ A product is a package of IT software, firmware and/or hardware, providing
functionality designed for use or incorporation within a multiplicity of systems.
▪ A system is a specific IT installation, with a particular purpose and operational
environment.

12. Security Management
❑ Security metrics for a system could look at the actual configurations of the products
deployed.
❑ In a system with access control features, look at the number of accounts with system privileges
or the number of accounts with weak passwords.
❑ In a networked system, look at the number of open ports or at the services accessible from
outside and whether the currently running versions have known vulnerabilities. Such attributes
certainly give valuable status information but do not really give the quantitative results desired
from a metric.
❑ Specifically for computer networks, you may measure the connectivity of nodes in a network to
assess how quickly and how far attacks could spread.
❑ You may also measure the time services are unavailable after an attack, or predict recovery times
and cost of recovery for a given configuration and class of attacks.
❑ Alternatively, you may try to measure security by measuring the cost of mounting attacks given
the following consideration:
▪ The time an attacker has to invest in the attack, e.g. analyzing software products,
▪ The expenses the attacker has to incur, e.g. computing cycles or special equipment,
▪ The knowledge necessary to conduct the attack.

13. Security Management
Standards
❑ The most prominent management standards described as codes of best practice for security
management is ISO 27002.
❑ ISO 27002 is not a technical standard for security products or a set of evaluation criteria for
products or systems. The major security consideration in ISO 27002 are:
▪ Security policy: Organizational security policies provide management direction and
support on security matters.
▪ Organization of information security: Responsibilities for security within an enterprise
have to be properly organized.
▪ Asset management: To know what is worth protecting, and how much to spend on
protection,
▪ Human resources security: Your own personnel or contract personnel can be a source
of insecurity.
▪ Physical and environmental security: Physical security measures (fences, locked doors,
etc.) protect access to business premises or to sensitive areas (rooms) within a building.
▪ Communications and operations management: The day-to-day management of IT
systems and of business processes has to ensure that security is maintained
▪ Access control: Access control can apply to data, services, and computers. Particular
attention must be applied to remote access, e.g. through Internet or WLAN connections.

14. Security Management
▪ Information systems acquisition: development, and maintenance. Security issues have to be
considered when an IT system is being developed.
▪ Information security incident management: Organizations have to be prepared to deal
promptly with security incidents.
▪ Business continuity management: Put measures in place so that your business can cope
with major failures or disasters.
▪ Compliance: Organizations have to comply with legal, regulatory, and contractual obligations,
as well as with standards and their own organizational security policy.

15. Risk and Threat Analysis
❑ Risk is associated with the consequences of uncertain events, i.e the possibility of an incident
or attack to cause damage to your enterprise
❑ Hazard risks relate to damaging events, IT risk analysis looks at hazard risks. It can be
conducted during the design phase of a system, during the implementation phase, and during
operations. It can be applied
▪ During the development of new components, e.g. in the area of software security,
▪ Specifically for the IT infrastructure of an enterprise,
▪ Comprehensively for all information assets of an enterprise
❑ Opportunity risks to events that might also have a positive outcome, e.g. to a financial
investment on the stock exchange.
Fig. (1): Applying Risk Analysis During a System Life Cycle

16. Risk and Threat Analysis
❑ The literature on risk analysis uses terms such as threat, vulnerability, impact, asset, and attack
These terms are related.
❑ An attack exploits a vulnerability to have a negative impact on an asset.
❑ Damage to an asset, e.g. a captured password, may facilitate a next attack step and cause
damage to a further asset.
❑ Without a structured and systematic approach to risk analysis you are in danger of getting lost in
the details of particular security problems but failing to establish a comprehensive overview of
your risks.
Fig. (2): Factors in Risk Analysis

17. Risk and Threat Analysis
❑ An attack against an IT system consists of a sequence of actions, exploiting vulnerabilities in th
system, until the attacker’s goals have been achieved.
❑ To assess the risk posed by the attack you have to evaluate the impact of the attack and the
likelihood of the attack occurring as shown in the figure.
❑ This likelihood will depend on the exposure of your system to potential attackers and how easil
the attack can be mounted (exploitability of vulnerabilities). In turn, this will further depend on
the security configuration of the system under attack.
Assets
As a first step assets have to be identified and valued. In an IT system, assets include:
❑ Hardware: laptops, servers, routers, mobile phones, netbooks, smart cards, etc.;
❑ Software: applications, operating systems, database management systems, source code, object
code, etc.;
❑ Data and information: essential data for running and planning your business, design
documents, digital content, data about your customers, etc.;
❑ reputation.

18. Risk and Threat Analysis
❑ Identification of assets should be a relatively straightforward systematic exercise. Measurement
of asset values is more of a challenge.
❑ Some assets, such as hardware, can be valued according to their monetary replacement costs.
For other assets, such as data and information, this is more difficult. If your business plans are
leaked to the competition or private information about your customers is leaked to the public
you have to account for indirect losses due to lost business opportunities.
❑ Assets can be valued according to their importance. As a good metric for importance, ask
yourself how long your business could survive when a given asset has been damaged: a day, a
week, a month
Threats
❑ A threat is an undesirable negative impact on your assets. You can categorize threats by their
impact on assets and agents. For example, Microsoft’s STRIDE threat model for software
security lists the following categories:
▪ Spoofing identities: an agent pretends to be somebody else; this can be done to avoid
responsibility or to misuse authority given to someone else.
▪ Tampering with data: violates the integrity of an asset; e.g. security settings are
changed to give the attacker more privileges.

19. Risk and Threat Analysis
▪ Repudiation: an agent denies having performed an action to escape responsibility
▪ Information disclosure: violates the confidentiality of an asset; information disclosed to
the wrong parties may lose its value (e.g. trade secrets); your organization may face
penalties if it does not properly protect information (e.g. personal information about
individuals).
▪ Denial of service: violates the availability of an asset; denial-of-service attacks can make
websites temporarily unavailable; the media have reported that such attacks have been
used for blackmail.
▪ Elevation of privilege: an agent gains more privileges beyond its entitlement.
Vulnerabilities
❑ Vulnerabilities are weaknesses of a system that could be accidentally or intentionally exploited
to damage assets. In an IT system, typical vulnerabilities are:
▪ Accounts with system privileges where the default password, such as ‘MANAGER’,
has not been changed;
▪ Programs with unnecessary privileges;
▪ Programs with known flaws;
▪ Weak access control settings on resources, e.g. having kernel memory world-writable;
▪ Weak firewall configurations that allow access to vulnerable services.

20. Risk and Threat Analysis
Attacks
❑ An attack is a sequence of steps, and a threat materializes when an attack succeeds.
❑ It may start innocuously, gathering information needed to move on to gain privileges on one
machine, from there jump to another machine, until the final target is reached. To get a full
picture of its potential impact, a forest of attack trees can be constructed as shown in Fig. (3).
❑ The root of an attack tree is a threat.
Fig. (3): Attack Tree for Obtaining Another User’s Password
❑ Attack trees are a formalized and structured method for analyzing threats.
❑ For threat assessments, if the final result appears implausible, the tree can be consulted to see
which subgoals were most critical for the final result, and those individual valuations may be
adjusted to more ‘sensible’ values.

21. Risk and Threat Analysis
❑ For threat assessments, if the final result appears implausible, the tree can be consulted to see
which subgoals were most critical for the final result, and those individual valuations may be
adjusted to more ‘sensible’ values.
Severity
❑ The severity of an attack depends on the likelihood that it will be launched, the likelihood
that it will succeed, and the damage that it might do.
❑ Likelihood depends on the difficulty of the attack, on the motivation of the attacker, on the
number of potential attackers, and on existing countermeasures.
❑ The DREAD methodology that complements Microsoft’s STRIDE threat model demonstrates
how the severity of an attack can be measured in a systematic manner. The DREAD approach
list the following categories:
▪ Damage potential: relates to the values of the assets being affected.
▪ Reproducibility: attacks that are easy to reproduce are more likely to be launched from
the environment than attacks that only work in specific circumstances.
▪ Exploitability: captures the effort, expertise, and resources required to launch
an attack.
▪ Affected users: the number of assets affected contributes to the damage potential.
▪ Discoverability: will the attack be detected? In the most damaging case, you will never
know that your system has been compromised.

22. Risk and Threat Analysis
Common Vulnerability Scoring System
❑ The Common Vulnerability Scoring System (CVSS) is shown in Fig. (4), where the basic
metric group collects generic aspects of a vulnerability, the temporal metrics group captures
the current state of exploits and countermeasures and the environmental metrics group rates
the impact on the assets of a given organization.
Fig. (4): Metrics in the Common Vulnerability Scoring System
Quantitative and Qualitative Risk Analysis
❑ Having measured the value of assets, the criticality of vulnerabilities, and the likelihood
and impact of threats, Very informally, risk can be calculates as
Risk = Assets × Threats × Vulnerabilities.
❑ Quantitative risk analysis takes ratings from a mathematical domain such as a probability

23. Risk and Threat Analysis
❑ Qualitative risk analysis takes values from domains that do not have an underlying
mathematical structure:
▪ Assets could be rated on a scale of critical – very important – important – not important.
▪ Criticality of vulnerabilities could be rated on a scale of has to be fixed immediately – has
to be fixed soon – should be fixed – fix if convenient.
▪ Threats could be rated on a scale of very likely – likely – unlikely – very unlikely.
Countermeasures / Risk Mitigation
❑ The result of a risk analysis is a prioritized list of threats, together with recommended
countermeasures to mitigate risk.
❑ Risk analysis tools usually come with a knowledge base of countermeasures for the threats
they can identify.
❑ Risk analysis is also used for calculating the return on security investment (ROSI). ROSI
compares for given security measures the expected reduction in risk with the costs of fielding
the security measures.
❑

24. Risk and Threat Analysis
❑ Ideally, risk analysis must be conducted before deciding on which security measures to
implement. However, the ideal approach may not work for two reasons:
▪ Firstly, conducting a risk analysis for a larger organization will take time, but the IT
system in the organization and the world outside will keep changing. So, by the time the
results of the analysis are presented, they are already somewhat out of date.
▪ Secondly, the costs of a full risk analysis may be difficult to justify to management.
❑ As an alternative the above approach, organizations may opt for Baseline protection, which
analyzes the security requirements for typical cases and recommends security measures
deemed adequate.

25. END!