Chapter – 2
Secure Design Principles,
Secure System Design
1
What is system design
❑ System design is the process of defining the
architecture, components, modules, interfaces, and
data of a system to meet specified functional and
non-functional requirements.
❑ System development is the process of creating or
modifying information systems, encompassing the
methodologies, processes, practices, and models
used throughout the system’s life cycle
❑ Software architecture refers to the high-level
structure of a software system, defining its
components, their relationships, interactions, the
operating environment, and the guiding principles or
patterns used in its design. 2
Objectives of Software Architecture
and Design
Completeness: The architecture should support the
entire scope of defined functional and non-functional
requirements.
❑ Stability: The system should consistently perform as
intended within its operational environment.
❑ Flexibility: The design should adapt to changing
business needs, technologies, or environments with
minimal rework
❑ Decomposable - The system should be divided into
manageable, independent components so that
individual modules can be modified or replaced with
3
minimal impact on others.
Objectives of Software Architecture
and
❑ Design - The architecture should allow new
Extensibility
features or components to be added easily without
major redesign.
❑ Scalability - operates effectively at any size and
load.
❑ Attack resistance
⮚ Contains minimal security weaknesses that could
be exploited
❑ Attack tolerance
⮚ While resisting attack, software function, and
capability are not unduly affected
❑ Attack resilience
4
What is secure system design ?
❑ is the practice of designing and developing a system—
including hardware, software architecture, components,
modules, interfaces, and data—so that it meets specified
requirements while being protected against vulnerabilities
and attacks.
❑ This is achieved through continuous testing, strong
authentication, and adherence to secure programming best
practices.
System security goals
5
What is secure system design …
Secure system design involves
❑ Access – the ability to communicate or interact with a
system or its components.
❑ Authentication – the process of identifying an
individual or system for the purpose of assessing
authorization
❑ Authorization –used to limit which actions are allowed
to be performed with components based on identity.
❑ Vulnerability – weaknesses inherent to the system or
component design which allows an attacker to
circumvent intended security controls
❑ Impact – capabilities available to an attacker once
they’ve attained authorization 6
Security Design Best Practices
❑ Implement end-to-end security and privacy of system
data and operations e.g. E.g. server, end-user on a
management web portal
❑ Restrict system and network communications to only
known, authorized system components
❑ Expect software vulnerabilities & validate secure
coding using automated & manuals means
❑ Utilize secure coding best practices( static and
dynamic code) vulnerability testing.
❑ Implement reliable and securely managed
software/firmware update mechanisms using links7
Secure Design Principles
❑ Security design principle is a declarative statement
made with the intention of guiding security design
decisions in order to meet the goals of a system.
❑ Proper implementation of secure design principles,
taken in context with business objectives and
constraints, significantly reduces vulnerability and
mitigates risk
❑ Specific design principles underlie the design and
implementation of mechanisms for supporting
security policies.
❑ What is a principle? The fundamental truth or
proposition serving as the foundation for belief or
action
8
Secure Design Principles
Principle of Least Privilege
❑ A system module should only have the minimal
privileges needed for its intended purposes
❑ A program should be given only those privileges it
needs in order to satisfy its requirements—no more,
no less
⮚ If a program doesn’t need an access right, it should not be
granted that right
❑ E.g. when accessing the database on behalf of an
unprivileged user, the database account used will
have only the privileges necessary
⮚ access to only the required databases and tables
Leastcontrols
⮚ Access to only the necessary operational Organization user
policy role
Available taskprivilege
❑ CRUD(Create, Read, Update, Delete)
9
Secure Design Principles
❑ Benefits of implementation of least privilege
❑ A condensed attack surface: Limiting privileges people,
processes, and applications/machines diminish the pathways
and ingresses for exploitation.
❑ Reduced malware infection and propagation: helps
dramatically reduce malware infection and propagation of
malware (such as SQL injections) should be denied the
ability to elevate processes that allow installing or execute.
❑ Improved operational performance: applications and
systems, restricting privileges to the minimal range of
processes to perform an authorized activity reduces the
chance of incompatibility issues and helps reduce the risk of
downtime.
❑ Easier to achieve and prove compliance: constraining the
possible activities, least privilege enforcement helps create
a less complex, and thus, a more audit-friendly environment
10
Secure Design Principles
❑ Privilege Separation: separate users and processes based on
different levels of trust, needs, and privilege requirements
❑ Separation of privilege refers to both:
❑ Segmentation of user privileges across various, separate users
and accounts
❑ Compartmentalization of privileges across various application
or system sub-components, tasks, and processes.
❑ It requires at least two actors
❑ Separation of privilege can be implemented in a number of ways
⮚ Separating administrative account functions from each other
⮚ Separating administrative and standard account capabilities
⮚ Separating auditing and logging capabilities within
administrative accounts
⮚ Separating system functions like read, edit, write, execute, etc.
❑ It is more robust and flexible than one that allows access to the
presenter of only a single key. 11
Secure Design Principles…
❑ Defense in Depth: a secure design strategy that
provides multiple, redundant defensive measures in
case a security control fails or a vulnerability is
exploited.
❑ It states that multiple security controls make attacks
less successful due to layers of authorization
verifications.
❑ It is based
Physical control:on controls
prevent that are designed to protect
physical
access
the to systems(locked
physical, doorand
technical or administrative aspects of
security
your guards)
network.
Technological control: protect
network systems or resources using
hardware/software (firewall or
antivirus program)
Administrative control: consisting 12
Secure Design Principles…
❑ Open Design: the security mechanism should not
depend on the secrecy of its design or
implementation.
❑ Designers and implementers of a program must not
depend on the secrecy of the details of their design
and implementation to ensure security.
❑ The source code should be public
❑ This is a particularly important principle for security
concepts like cryptographic implementations.
❑ Well-designed cryptography implementations are
published publicly
13
Secure Design Principles…
❑ Open Design ….
❑ E.g. Content Scrambling System (CSS) is a cryptographic
algorithm that protects DVD movie disks from unauthorized
copying.
❑ DVD disk has an authentication key, a disk key, and a title key.
❑ The title key is enciphered with the disk key.
❑ A block on the DVD contains several copies of the disk key, each
enciphered by a different player key, and a checksum of the disk
key.
❑ When a DVD is inserted into a DVD player, the algorithm reads
the authentication key.
❑ Then deciphers the disk keys using the DVD player's unique
key.
❑ When it finds a deciphered key with the correct hash, it uses
that key to decipher the title key, and uses the title key to 14
Secure Design Principles…
❑ Economy of Mechanisms: security mechanisms
should be as simple as possible.
❑ If a design and implementation are simple, fewer
possibilities exist for errors.
❑ The checking and testing process is less complex, b/c
fewer components and cases need to be tested.
❑ Simpler means less can go wrong and when errors
occur they easier understand and fix
15
Secure Design Principles…
❑ Economy of Mechanisms …
❑ Example. the ident protocol transmits information
about a user or system
❑ Many client implementations assume that the
server's response is well-formed.
❑ However, if an attacker were to create a server that
generated an infinite stream of characters, and an
ident client were to connect to it, the client would
print all the characters.
❑ As a result, log files and disks could be filled up,
resulting in a denial of service attack on the
querying host. This is an example of incorrect
assumptions about the input to the client.
16
Secure Design Principles…
❑ Compete Mediation: requires that all accesses to
objects be checked to ensure that they are allowed.
❑ Whenever a subject attempts to read an object, the
operating system should mediate the action.
❑ It determines if the subject is allowed to read the
object.
❑ If so, it provides the resources for the read to occur.
❑ If the subject tries to read the object again, the
system should check that the subject is still allowed
to read the object.
❑ They would cache the results of the first check and
base the second access on the cached results.
17
Secure Design Principles…
❑ Compete Mediation ….
❑ Example: Domain Name Service (DNS) caches information
mapping hostnames into IP addresses. If an attacker is able to
poison the cache by implanting records associating a fake IP
address with a name, one host will route connections to another
host incorrectly.
❑ Least Common Mechanism
❑ The mechanism used to access resources should not be shared.
❑ Sharing resources provides a channel along which information
can be transmitted, and such sharing should be minimized.
❑ In practice, if the operating system provides support for virtual
machines, the operating system will enforce this privilege
automatically to some degree
❑ Otherwise, it will provide some support (such as a virtual
memory space) but not complete support (because the file
system will appear as shared among several processes). 18
Secure Design Principles…
❑ Least Common Mechanism …
❑ Example: a Web site provides electronic commerce
services for a major company.
❑ Attackers want to deny the company of the revenue it
obtains from that Web site. They flood the site with
messages and tie up the electronic commerce
services.
❑ Legitimate customers are unable to access the Web
site and, as a result, take their business elsewhere.
❑ The sharing of the Internet with the attackers' sites
caused the attack to succeed.
❑ The appropriate countermeasure would be to restrict
the attackers' access to the segment of the Internet-
19
connected to the Website
Secure Design Principles…
❑ Psychological Acceptability: states that security
mechanisms should not make the resource more difficult
to access than if the security mechanisms were not
present.
❑ Configuring and executing a program should be as easy
and intuitive as possible, and output should be clear,
direct, and useful.
❑ If security-related software is too complicated to
configure, system administrators may unintentionally set
up the software in a non-secure manner.
❑ Similarly, security-related user programs must be easy to
use and must output understandable messages.
❑ If a password is rejected, the password changing program
should state why it was rejected rather than giving a
cryptic error message.
❑ If a configuration file has an incorrect parameter, the 20
Secure Design Principles…
❑ Psychologically Acceptable…
❑ Example: the SSH program allows a user to set up a
public key mechanism for enciphering
communications between systems.
❑ The installation and configuration mechanisms for
the UNIX version allow one to arrange that the
public key be stored locally without any password
protection.
❑ In this case, one need not supply a password to
connect to the remote system, but will still obtain the
enciphered connection.
❑ This mechanism satisfies the principle of
psychological acceptability.
21
Secure Design Principles…
❑ Secure Weakest Link: spend your security budget
securing the biggest problems and the largest
vulnerabilities.
❑ Security practitioners often point out that security is
a chain and just as a chain is only as strong as the
weakest link, a software security system is only as
secure as its weakest component
❑ Attackers go after the weakest point in a system, and
the weakest point is rarely a security feature or
function.
❑ When it comes to secure design, make sure to
consider the weakest link in your system and ensure
that it is secure enough.
22
Secure Design Principles…
Fail-Safe Defaults:
❑ Unless a subject is given explicit access to an object,
it should be denied access to that object.
❑ This principle requires that the default access to an
object is none.
❑ Whenever access, privileges, or some security-
related attribute is not explicitly granted, it should
be denied.
❑ if the subject is unable to complete its action or task,
it should undo those changes it made in the security
state of the system before it terminates.
❑ This way, even if the program fails, the system is still
safe.
23
Secure Design Principles…
Fail-Safe Defaults …
❑ Example: If the mail server is unable to create a file in the
spool directory, it should close the network connection issue
an error message and stop.
❑ It should not try to store the message elsewhere or to expand
its privileges to save the message in another location,
because an attacker could use that ability to overwrite other
files or fill up other disks (denial of service attack).
❑ The protections on the mail spool directory itself should allow
create and write access only to the mail server and read and
delete access only to the local server.
❑ Practically, most systems will allow an administrator access
to the mail spool directory and allow be able to access only
the subjects and objects involved in mail queueing and
delivery by least privilege
❑ If administrator's account is compromised then mail system
can be damaged or destroyed, but nothing else can be. 24
Thank you
25