ITCS 405:
Foundation of
Cybersecurity
WE EK03:INTRODUC TI ON TO C Y BERSECURITY
D R . LUBNA FAY EZ E LI YAN
COL LEGE OF I NFORMATION T ECHNOLOGY
Week03: Outline
▪OSI Security Architecture
▪Attacks
▪Mechanisms,
▪Services
▪Security Design Principles
2
OSI Security Architecture
▪To assess effectively the security needs of an organization and to evaluate
and choose various security products and policies there is a need for:
▪A systematic way of defining the requirements for security and
characterizing the approaches to satisfying those requirements
▪OSI Architecture focuses on security attacks, mechanisms, and services
▪computer and communications vendors have developed security
features for their products and services that relate to OSI structured
definition of services and mechanisms
3
OSI
Security Security Security
Attacks Mechanisms Services
4
OSI Architecture: Security Attacks
▪Any action that compromises the security of information owned by an
organization
▪Active attacks
▪Masquerade: an entity pretends to be a different entity
▪Replay: involves the passive capture of a data unit and its subsequent
retransmission to produce an unauthorized effect
▪Alternatim/modification: portion of a legitimate message is altered, or that
messages are delayed or reordered, to produce an unauthorized effect
▪The denial of service attack
5
OSI Architecture: Security Attacks
▪Passive attacks
▪ Eavesdropping or monitoring of transmission and logging
▪ Traffic analysis: observe the frequency and length of messages being
exchanged→ guess the nature of the communication that was taking place
▪ gather information about the system, network, or devices
▪ the attacker can’t read the message but only understands the pattern and
length of encryption
6
OSI Architecture: Security Attacks
▪Passive attacks
▪very difficult to detect:
▪ do not involve any alteration of the data
▪ traffic is exchanged in a normal fashion, and neither the sender nor the receiver
is aware that a third party has read the messages or observed the traffic pattern
7
OSI Architecture: Security Mechanisms
▪The approach to identifying any breach of security or attack on the
organization
▪responsible for protecting a system, network, or device against
unauthorized access, tampering, or other security threats
8
Security Mechanisms (1/4)
• use algorithms to transform data into a form that can only
be read by someone with the appropriate decryption key
Encryption • used to protect data transmitted over a network, stored on a
device.
Digital • the use of cryptographic techniques to create a unique,
verifiable identifier for a digital document or message
• an ensure of the authenticity and integrity of the document
Signature or message
9
Security Mechanisms (2/4)
Authentication • A mechanism to ensure the identity of an entity
using information exchange
Exchange
• technique used to add extra data to a network
Traffic Padding traffic stream to obscure the true content of the
traffic and make it more difficult to analyze.
10
Security Mechanisms (3/4)
Routing • allows the selection of specific physically
secure routes for specific data transmission
Control and enables routing changes
Access • Rules and policies to enforce access rights to
resources
Control
11
Security Mechanisms (4/4)
Data • Mechanisms used to assure the
Integrity integrity of data streams
• The use of a trusted third party to
Notarization ensure certain properties of a data
exchange
12
OSI Architecture: Security Services
▪Services available for maintaining the security and safety of an organization
▪help in preventing any potential risks to security
▪Use security mechanisms to provide services
13
Security Services (1/2)
• the process of verifying the identity of a user or device
Authentication to grant or deny access to a system or device
• the use of policies and procedures to determine who
Access Control is allowed to access specific resources within a
system.
Data • the protection of information from being accessed or
disclosed to unauthorized parties
Confidentiality
14
Security Services (2/2)
• the use of techniques to create a verifiable record of
Non- the origin and transmission of a message,
• can be used to prevent the sender from denying that
repudiation they sent the message
Data The assurance that data received are exactly as sent by an
authorized entity (contain no modification, insertion,
Integrity deletion, or replay).
15
Fundamental Security Design Principles
▪not been possible to develop security design and implementation
techniques that systematically exclude security flaws and prevent all
unauthorized actions.
▪But there is a set of widely agreed design principles
16
Design Principles (1/13):
Economy of Mechanism
▪The design of security measures for hardware and software should be as simple
and small as possible. Why?
▪Simple mechanisms tend to have fewer exploitable flaws and require less
maintenance.
17
Design Principles (1/13):
Economy of Mechanism-cont’d
▪Small design is easier to test and verify
▪The more complex the mechanism, the more likely it is to possess exploitable
flaws.
▪Configuration management issues are simplified, updating or replacing a
simple mechanism becomes a less intensive process.
▪In practice, this is perhaps the most difficult principle to honor
▪ There is a constant demand for new features in both hardware and software,
complicating the security design task
18
Design Principles (2/13):
Fail-safe Default
▪access decisions should be based on permission rather than exclusion
▪The default situation is lack of access, and the protection scheme
identifies conditions under which access is permitted
▪implementation mistake in a mechanism
▪→ refusing permission, a safe situation that can be quickly detected.
▪Instead of having the default to permit access
▪implementation mistake in a mechanism
▪→ allowing access, a failure that may long go unnoticed in normal use
19
Design Principles (3/13):
Complete Mediation
▪Every access must be checked against the access control mechanism
▪ Systems should not rely on access decisions retrieved from a cache why?
▪if access decisions are remembered for future use:
▪ careful consideration should be given to how changes in authority are propagated
into such local memories
▪ File access systems appear to provide an example of a system that complies with this
principle
▪ Yet, once a user has opened a file, no check is made to see if permissions change
▪ How to fully implement complete mediation?
▪ → every time a user reads a field or record in a file or a data item in a database, the
system must apply access control
▪ → This resource-intensive approach is rarely used
20
Design Principles (4/13):
Open Design
▪The design of a security mechanism
should be open rather than secret
▪Example:
▪ Encryption keys must be secret→
▪ yet, encryption algorithms should be
open to public scrutiny
▪ The algorithms can then be reviewed
by experts→ higher confidence for users
21
Design Principles (5/13):
Separation of Privilege
▪Multiple privilege attributes are required to achieve access to a restricted resource
▪User level
▪ Example: multifactor user authentication, which requires the use of multiple
techniques
▪ a password and a smart card, to authorize a user
▪Programs level divide the program into parts that are limited to the specific
privileges they require to perform a specific task
▪ Example: removing high-privilege operations to another process and running that
process with the higher privileges required to perform its tasks
▪ Day-to-day interfaces are executed in a lower-privileged process
22
Design Principles (6/13):
Least Privilege
▪Every process and every user of the system should operate using the least set
of privileges necessary to perform the task
▪Example: role-based access control:
▪The system security policy can identify and define the various roles of users
or processes.
▪Each role is assigned only those permissions needed to perform its functions.
▪Each permission specifies permitted access to a particular resource (such as
read and write access to a specified file or directory)
23
Design Principles (6/13):
Least Privilege-cont’d
▪Unless permission is granted explicitly, the user or process should not be able
to access the protected resource
▪System programs or administrators who have special privileges should have
those privileges only when necessary
▪For ordinary activities→ the special privileges should be withdrawn
24
Design Principles (7/13):
Least Common Mechanism
▪The design should minimize the functions
shared by different users, providing mutual
security
▪Helps in reducing the number of unintended
communication paths and reduces the amount
of hardware and software on which all users
depend and share
▪making it easier to verify if there are any
undesirable security implications
25
Design Principles (8/13):
Psychological Acceptability
▪Security mechanisms should not interfere improperly with the work of users,
while at the same time meeting the needs of those who authorize access
▪If security mechanisms hinder the usability or accessibility of resources
▪ → then users may opt to turn off those mechanisms
▪Security mechanisms should be transparent with minimal obstruction
▪Should not be intrusive or burdensome,
▪ security procedures must reflect the user’s mental model of protection
▪ If the protection procedures do not make sense to the user
▪ → the user is likely to make errors.
26
Design Principles (9/13):
Isolation
▪public access systems should be isolated from
critical resources (data, processes, etc.)
▪ → to prevent disclosure or tampering.
▪For information with high sensitivity or criticality
organizations may want to limit the number of
systems on which that data is stored and isolate
them, either physically or logically.
▪Physical isolation: ensure no physical connection
exists between an organization’s public access
information resources and an organization’s critical
information
▪The processes and files of individual users should
be isolated from one another except where it is
explicitly desired.
27
Design Principles (10/13):
Encapsulation
▪specific form of isolation based on object-oriented
functionality.
▪Protection is provided by encapsulating a collection
of:
▪ procedures and data objects in a domain of its
own so that the internal structure of a data
object
▪is accessible only to the procedures of the
protected subsystem, and the procedures may be
called only at designated domain entry points.
28
Design Principles (11/13):
Modularity
▪development of security functions as separate, protected modules
and to the use of a modular architecture for mechanism design and
implementation
▪Use of separate security modules instead of developing them
▪Example:
▪ protocols and applications make use of cryptographic functions
instead of implementing such functions in each protocol or
application
▪ Why?
▪The design and implementation effort can then focus on the secure
design and implementation of a single cryptographic module and
include mechanisms to protect the module from tampering.
29
Design Principles (12/13):
Layering
▪Layering: the use of multiple,
overlapping protection approaches
addressing the people, technology,
and operational aspects of
information systems.
▪The failure or circumvention of any
individual protection approach will
not leave the system unprotected.
30
Design Principles (12/13):
Layering
▪01 Human Layer:
▪ Practices and policies that ensure that
employees, contractors, and other
users do not fall victim to phishing
attacks and other security threats due
to human error or lack of knowledge.
▪ Examples: security awareness training,
strong password policies, multi-factor
authentication
▪ →ensuring that users can identify and
respond appropriately to security
threats.
▪ Most vulnerable
31
Design Principles (12/13):
Layering
▪02 Perimeter Layer:
▪The walls of a fortress
▪It serves to protect the network by
controlling incoming and outgoing
network traffic based on an
organization's previously established
security policies.
▪ Examples: Intrusion Detection
Systems (IDS), Intrusion Prevention
Systems (IPS), VPNs, firewalls.
32
Design Principles (12/13):
Layering
▪03 Network Layer:
▪managing and protecting the
communication between
applications and devices on the
network
▪ Examples secure protocols: HTTPS,
SSH, employing network
segmentation.
33
Design Principles (12/13):
Layering
▪04 Application Security Layer:
▪keeping software and devices free of
threats.
▪Apply secure coding practices to
detect and remove vulnerabilities in
the application to avoid
vulnerabilities as entry points for
cyber threats
▪Examples regular security scanning
and testing
34
Design Principles (12/13):
Layering
▪05 Endpoint Layer:
▪Protect the individual devices that
connect to the network: computers,
smartphones, and tablets
▪ Examples antivirus programs and
endpoint detection and response
(EDR) solutions to monitor, detect,
and block malicious activities and
threats on endpoints
35
Design Principles (12/13):
Layering
▪06 Data Security Layer:
▪protecting the data residing in the
network, focusing on maintaining its
confidentiality, integrity, and
availability
▪ Examples encryption, backups,
access controls
36
Design Principles (12/13):
Layering
▪07 Mission-critical Assets:
▪ protecting assets that are crucial to an
organization's operations and business
continuity.
▪ Examples: proprietary software,
sensitive customer data, or essential
hardware.
▪ Examples regularly updating and
patching mission-critical applications
▪ →ensures that vulnerabilities are
addressed, minimizing the risk of
exploitation and ensuring the
uninterrupted functionality of
essential assets.
37
Design Principles (13/13):
Least Astonishment
▪a program or user interface should always
respond in the way that is least likely to
astonish the user
▪Example, the mechanism for authorization
should be transparent enough to a user that
the user has a good intuitive understanding of
how the security goals map to the provided
security mechanism.
38
