Security Principles

Haipeng Dai

[email protected]
313 CS Building
Department of Computer Science and Technology
Nanjing University
 Security Principles
 Variations of lists of security principles
 Security vulnerabilities often exploit violations of these
principles
 Good security solutions or countermeasures follow these
principles
 Some overlap & some tension between principles
 More generally, checklists are useful for security
 These principles can be applied at many levels, e.g., in source
code of an application, between applications on a machine at OS
level, at network level, within an organization, between
organizations
 Here we give 16 principles
 Main Source: software security principles by Gary McGraw and
John Viega

CSE825 2
 Principle 1: Securing the weakest
 Security is a chain; a system is only as secure as the weakest link.
 Spend your efforts on improving the security of the weakest part
of a system, as this is where attackers will attack.
─ Bank vs. convenience store
─ Firewall vs. application visible through firewall
 Social engineering: a common weak link.
─ Software can be weak, surrounding infrastructure can be weaker.
─ Typical scenario: a service center gets a call from a sincere-sounding user
─ Educating users may be best investment to improve security, eg., think of
phishing attacks, weak passwords

CSE825 3
 Principle 1: Securing the weakest link

 Credit card example - threats to credit card numbers include:

● eavesdropping on the network
● stealing from customer database
● me loosing my wallet – weakest link
 Solution: risk analysis.

CSE825 4
 Principle 2: Defense in depth
 If one layer fails, hopefully another layer can succeed.
 No single point of failure.
 Why is bank more secure than convenience store?
─ Redundant security measures: security guard, bulletproof glass,
electronically locked doors, vault protecting the rest and requiring the
presence of two individuals who are rarely at the bank at the same time,
security camera,…
 Well-known principle even beyond security
─ Have a series of defenses so that if an error isn't caught by one, it will
probably be caught by another. (From Bruce MacLennan's Principles of
Programming Languages.)
 Securing the weakest link applies to nonoverlapping functions.
 Defense in depth applies to same function.

CSE825 5
Principle 2: Defense in depth (cont.)
 Example 1: have a firewall and secure web application software,
and run web application with minimal privileges
 Example 2: use OS access control to restrict access to sensitive
files, and encrypt them, especially when files are stored on
removable media such as USB sticks, laptops, or PCs which
might be disposed.
 Counterexample: on UNIX systems, the password file,
/etc/passwd, which contains hashed passwords, was world
readable.
─ Solution: enforce tight access control to the file.
 Counterexample: having a firewall, and only having firewall
─ a user bringing in a laptop circumvents firewall
 Counterexample: firewall + unencrypted data within network

CSE825 6
 Principle 3: Secure failure
 When systems fail, they should not revert to insecure behavior.
Otherwise, attacker only need to invoke the right failure.
 Incorrect handling of unexpected errors is major cause of
security breaches
 Example: careful handling of exceptions in JAAS (Java
Authentication and Authorization Service) module code!
isAdmin = true; // enter Admin mode
try {
something that may throw SomeException
} catch (SomeException ex) {
// should we log?
log.write(ex.toString());
// how should we proceed?
isAdmin = false;
// or should we exit?
}
CSE825 7
 Principle 3: Secure failure (cont.)
 Counterexample: old version software did not use encryption,
new version does; for backward compatibility, when new
version talks to old version, new version disables encryption.
─ Attack: when new version talks to new version, attackers can tamper
message on the wire to make both think the other is over version.
─ Solution: new version notifies old version to download patches from a
secure place that the old version knows.
─ Question: what about old version downloads patches from new version?
─ Security problem: then new version is not authenticated.
 Counterexample - Remote Method invocation (RMI)
─ When a client and server want to communicate over RMI, if the server
wants to use an encryption protocol that client does not support, the client
downloads the protocol implementation from the server at runtime.
─ Security problem: if the client fails to establish a secure connection (a
failure), it will establish a connection using whatever protocol an
untrusted entity gives it.
CSE825 8
 Principle 4: Least privilege
 Only the minimum access necessary to perform an operation
should be granted, and that access should be granted only for the
minimum amount of time necessary.
 Example: you go vacation, ask a friend to pick up mail
 Example: U.S. government -- the policy of “need to know.”
 Counterexample: famous violations of least privilege exist in
UNIX systems (-- needs root privilege for running a service on a
port number less than 1024)
─ Some e-mail servers is that they don't give up their root permissions once
they have grabbed the mail port (Sendmail is a classic example).
 Counterexample: device drivers having to run in kernel mode
 Counterexample: Several calls in the Windows API for
accessing objects that grant all access if you pass "0" as an
argument.
─ Programmers are lazy.

CSE825 9
 Principle 4: Least privilege (cont.)
 In organization
─ don’t give everyone access to root passwords
─ don’t give everyone administrator rights
 On computer
─ Run process with minimal set of privileges
─ For example, don’t run web application as root or administrator
 for Java application: not the default policy
grant codeBase "file:${{java.ext.dirs}}/*" {
permission java.security.AllPermission;
};
but minimum required
grant codeBase "file:./forum/*" {
permission java.security.FilePermission;
"/home/forumcontent/*","read/write";};
CSE825 10
 Principle 4: Least privilege (cont.)
 Expose minimal functionality in interfaces of objects, classes,
packages, applications.

 in code:
─ not public int x;
─ but private int x;
─ not public void m()
─ but package void m()

 Least privilege example:

─ Standard coding standard
not to use import java.lang.*;
but always import java.lang.String;

CSE825 11
 Principle 4: Least privilege (cont.)
 Use Secure Defaults
 By default,
─ security should be switched on
─ permissions turned off
 This will ensure that we apply principle of least privilege
 Counterexample: bluetooth connection on mobile phone is by
default on, but can be abused

CSE825 12
 Principle 5: Compartmentalization
 Break the system up into as many isolated units as possible
─ Simplicity
─ Containing attacker in case of failure
 Example: submarines are built with many chambers, each
separately sealed
 Example: prison.
 Counterexample: Famous violations of this principle exist
standard UNIX privilege model
─ A program with root privilege can do everything (including erase logs)
 A few operating systems, such as Trusted Solaris, do
compartmentalize.
 Tradeoff with manageability.
 Counterexample: OS that crashes if an application crashes.

CSE825 13
Principle 5: Compartmentalization (cont.)
 Use different machines for different tasks
 Example: run web application on a different machine from
employee salary database
 Example: use different user accounts on one machine for
different tasks
 Compartementalization provided by typical OS is poor!
 Partition hard disk and install OS twice

CSE825 14
 Principle 6: Simplicity
 KISS mantra -- "Keep it simple, stupid!"
 Designs and implementations should be as simple as possible
─ Complexity increases the risk of problems; unavoidable in any system.
─ Complex code tends to be harder to analyze and maintain. It also tends to
be far more buggy.
 Should try to reuse components whenever possible.
 Be careful in applying this principle
─ Keep system simple on the condition of keeping system secure.
 Use choke points to improve simplicity
─ Force all security-critical operations through a few choke points.

CSE825 15
 Principle 7: Promote privacy
 Privacy of users, but also of systems
 Counterexample: services tend to give information about themselves that can
help the attacker figure out how to break in.
─ Telnet service tends to give the operating system name and version.
– > telnet somemachine
Trying 1.2.3.4
Connected to somemachine (1.2.3.4)
Red Hat Linux release 7.0 (Hedwig)
Kernel 1.2.3.4 on an i686
login:
─ Solution 1: use firewalls to block unnecessary services
─ Solution 2: remove such info from software (e.g., changing telenet login)
─ Solution 3: give the WRONG info! No hurt to lie to attackers!
 Counterexample: SQL error messages on webpage
 Counterexample: HTTP (http://www.cse.msu.edu/~alexliu/a.html)

CSE825 16
 Principle 8: Hard to hide secrets
 Don’t rely on security by obscurity [Kerckhoff principle]
 Don’t assume attackers don’t know the application source code,
and can’t reverse-engineer binaries
─ Don’t hardcode secrets in code.
─ Don’t rely on code obfuscation
 Counterexample
─ DVD encryption
─ webpages with hidden URLs
─ passwords in javascript code – this happens!

CSE825 17
 Principle 9: Be Reluctant to Trust
 Minimize Trusted Computing Base (TCB), i.e., the part of the
system that has to be trusted
 “Trusted” is not the same as “trustworthy”
 Counterexample: trust is extended far too easily in customer
support.
 All user input is evil !
─ Unchecked user input leads to
● buffer overflows, SQL injection, XSS on websites
─ User input includes cookies, environment variables, ...
 User input should not be trusted, and subjected to strong input
validation checks before being used
 Don’t trust your employees.
 Trust is transitive – make sure that trusted programs never
invoke untrusted programs.
CSE825 18
 Principle 10: Use Community Resources
 Repeated use without failure promotes trust. Public scrutiny
does as well.
 Never design your own cryptography
 Never implement your own cryptography
 Researchers help you to examine your algorithms for free!
 Don’t repeat known mistakes
 If you’re making an application of kind X using programming
language Y on platform Z and operating system W, look for
─ known threats for application of kind X
─ known vulnerabilities in programming language Y and platform Z, ...
─ existing countermeasures
 Counterexample: homebrew cookie schemes in Kevin Fu’s “Dos
and Don'ts of Client Authentication on the Web”

CSE825 19
 Principle 11: Minimize Attack Surface
 Minimize
─ number of open sockets
─ number of services
─ number of services running by default
─ number of services running with high priviliges
─ number of dynamic content webpages
─ number of accounts with administrator rights
─ number of files & directories with weak access control
 Counterexample
─ Linux box kind.cs.ru.nl was hacked, by someone guessing the root
password
─ Why was root login over the network allowed anyway?

CSE825 20
Principle 11: Minimize Attack Surface (cont.)
 Minimize Attack Surface in code
─ not public int x; but private int x;
─ not public void m(); but package void m()
─ This is applying principle of least privilege, and also reduces attack
surface, from buggy or hostile code

 Minimize attack surface in time

─ Automatically log off users after n minutes
─ Automatically lock screen after n minutes
─ Unplug network connection if you don’t use it
─ Switch off computer if you don’t use it
─ On smartcards, it’s good practice to zero-out arrays that contains sensitive
information (usually, decrypted information) as soon as it’s no longer
needed)

CSE825 21
 Principle 12: Don’t mix data & code
 This is the cause of many problems
 Counterexample: traditional buffer overflow attacks, which rely
on mixing data and code on the stack
 Counterexample: VB scripts in Office documents
─ leads to attacks by hostile .doc or .xls
 Counterexample: javascript in webpages
─ leads to XSS (cross site scripting attacks)
 Counterexample: SQL injection relies on user data (user input!)
as part of SQL query

CSE825 22
 Principle 13: Clearly Assign Responsibilities
 At organisational level:
─ eg. make one person responsible for something rather than two persons or
a whole group.
 At coding level:
─ make one module/class responsible for input validation, access control, ...
─ for a method
public void process(String str)
is the caller or callee responsible for checking if for instance
str!=null & !(str.equals(“”)) ?
 But still practice defence in depth...

CSE825 23
 Principle 14: Identify Your Assumptions
 Including obvious, implicit assumptions
─ these may be sources of vulnerability, and may change in long run
 Examples
─ laptops invalidate implicit assumption that computers don’t move past the
company firewall
─ assumption that user is a human may cause you to ignore possibility of
brute-force password guessing
─ TCP SYN flood attack exploits implicit assumptions in the spec “If we
receive a TCP packet with the SYN flag set, it means the sender wants to
start a dialog with us”
─ assumption that new LoginContext() won’t throw an OutOfMemory
Exception
─ assumption that a Java applet won’t use all CPU time

CSE825 24
 Principle 15: Audit Your System
 To keep a system secure, you need a record of changes made to
the system, either by its own utilities or by intrusion detection
systems such as Snort and Tripwire.
 While you can keep some records of changes by hand, on Unix-
like systems, logs of changes or errors are traditionally saved in
/var/log by system applications.
─ This system is not ideal, since altering logs to hide an intrusion is one of
the first steps that an expert cracker makes.
 However, since many attacks are by script-kiddies with little
understanding of the system, a change in logs is often the first
sign that a system has been compromised.
─ Some intrusion detection programs, such as Tripwire, can automate the
checking of logs and other key files.

CSE825 25
 Principle 16: Have Good Usability
 Understand your users
─ They will switch off security if too cumbersome.
─ They do not read documentation.
─ They ignore warnings – they just want to get what they want!

 Counterexample: Norton Internet Security keeps popping up

windows to ask questions

 User education may improve the situation, but only up to a point

CSE825 26
 Overview

Haipeng Dai

[email protected]
313 CS Building
Department of Computer Science and Technology
Nanjing University
Cryptographic algorithms and protocols can be
grouped into four main areas:
Symmetric encryption

• Used to conceal the contents of blocks or streams of data of any size,

including messages, files, encryption keys, and passwords

Asymmetric encryption

• Used to conceal small blocks of data, such as encryption keys and hash
function values, which are used in digital signatures

Data integrity algorithms

• Used to protect blocks of data, such as messages, from alteration

Authentication protocols

• Schemes based on the use of cryptographic algorithms designed to

authenticate the identity of entities

28
The field of network and Internet security
consists of:

measures to deter,
prevent, detect, and
correct security
violations that involve
the transmission of
information

29
 Computer Security
 The NIST Computer Security Handbook defines the term
computer security as:
“the protection afforded to an automated information
system in order to attain the applicable objectives of
preserving the integrity, availability and confidentiality of
information system resources” (includes hardware, software,
firmware, information/data, and telecommunications)

30
 Computer Security Objectives
Confidentiality
• Data confidentiality
• Assures that private or confidential information is not made available or disclosed to
unauthorized individuals
• Privacy
• Assures that individuals control or influence what information related to them may be
collected and stored and by whom and to whom that information may be disclosed

Integrity
• Data integrity
• Assures that information and programs are changed only in a specified and authorized
manner
• System integrity
• Assures that a system performs its intended function in an unimpaired manner, free
from deliberate or inadvertent unauthorized manipulation of the system

Availability
• Assures that systems work promptly and service is not denied to authorized
users

31
CIA Triad

32
 Possible additional concepts:

Authenticity Accountability
• Verifying that users • The security goal that
are who they say they generates the
are and that each input requirement for
arriving at the system actions of an entity to
came from a trusted be traced uniquely to
source that entity

33
Breach of Security Levels of Impact

• The loss could be expected to have a severe or

High catastrophic adverse effect on organizational
operations, organizational assets, or individuals

• The loss could be expected to have a

Moderate serious adverse effect on

organizational operations,
organizational assets, or individuals

• The loss could be expected

to have a limited adverse

Low effect on organizational

operations, organizational
assets, or individuals

34
 OSI Security Architecture
 Security attack
─ Any action that compromises the security of information owned by
an organization
 Security mechanism
─ A process (or a device incorporating such a process) that is designed
to detect, prevent, or recover from a security attack
 Security service
─ A processing or communication service that enhances the security of
the data processing systems and the information transfers of an
organization
─ Intended to counter security attacks, and they make use of one or
more security mechanisms to provide the service

35
Threats and Attacks

36
 Security Attacks
 A means of classifying security attacks, used both in X.800 and
RFC 4949, is in terms of passive attacks and active attacks
 A passive attack attempts to learn or make use of information
from the system but does not affect system resources
 An active attack attempts to alter system resources or affect their
operation

37
 Passive Attacks
 Are in the nature of eavesdropping on, or monitoring of,
transmissions
 Goal of the opponent is to obtain information that is being
transmitted

 Two types of passive attacks are:

─ The release of message contents
─ Traffic analysis

38
 Active Attacks
 Involve some modification of the
data stream or the creation of a • Takes place when one entity
pretends to be a different entity
false stream Masquerade • Usually includes one of the other
 Difficult to prevent because of the forms of active attack
wide variety of potential physical,
software, and network • Involves the passive capture of a
vulnerabilities data unit and its subsequent
Replay retransmission to produce an
 Goal is to detect attacks and to unauthorized effect
recover from any disruption or
delays caused by them
• Some portion of a legitimate
Modification message is altered, or messages are
of messages delayed or reordered to produce an
unauthorized effect

Denial of • Prevents or inhibits the normal use

or management of communications
service facilities

39
 Security Services
 Defined by X.800 as:
─ A service provided by a protocol layer of communicating open systems
and that ensures adequate security of the systems or of data transfers

 Defined by RFC 4949 as:

─ A processing or communication service provided by a system to give a
specific kind of protection to system resources

40
 X.800 Service Categories
 Authentication
 Access control
 Data confidentiality
 Data integrity
 Nonrepudiation

41
 Authentication
 Concerned with assuring that a communication is authentic
─ In the case of a single message, assures the recipient that the
message is from the source that it claims to be from
─ In the case of ongoing interaction, assures the two entities are
authentic and that the connection is not interfered with in such a way
that a third party can masquerade as one of the two legitimate parties

Two specific authentication services are defined in X.800:

• Peer entity authentication

• Data origin authentication

42
 Access Control
 The ability to limit and control the access to host systems
and applications via communications links
 To achieve this, each entity trying to gain access must
first be indentified, or authenticated, so that access rights
can be tailored to the individual

43
 Data Confidentiality
 The protection of transmitted data from passive attacks
─ Broadest service protects all user data transmitted between two users
over a period of time
─ Narrower forms of service includes the protection of a single message
or even specific fields within a message
 The protection of traffic flow from analysis
─ This requires that an attacker not be able to observe the source and
destination, frequency, length, or other characteristics of the traffic on
a communications facility

44
 Data Integrity
Can apply to a stream of messages, a single
message, or selected fields within a message

Connection-oriented integrity service, one that deals

with a stream of messages, assures that messages
are received as sent with no duplication, insertion,
modification, reordering, or replays

A connectionless integrity service, one that deals

with individual messages without regard to any
larger context, generally provides protection against
message modification only

45
 Nonrepudiation
 Prevents either sender or receiver from denying a transmitted
message
 When a message is sent, the receiver can prove that the alleged
sender in fact sent the message
 When a message is received, the sender can prove that the
alleged receiver in fact received the message

46
Security Services (X.800)

(This table is found on page

18 in textbook)

47
Security Mechanisms (X.800)

Specific Security Mechanisms

• Encipherment
• Digital signatures
• Access controls
• Data integrity
• Authentication exchange Pervasive Security Mechanisms
• Traffic padding • Trusted functionality
• Routing control • Security labels
• Notarization • Event detection
• Security audit trails
• Security recovery

48
Security Mechanisms (X.800)

(This table is found on pages

20-21 in textbook)

49
Model for Network Security

50
Network Access Security Model

51
 Unwanted Access
 Placement in a computer system of logic that exploits
vulnerabilities in the system and that can affect
application programs as well as utility programs such as
editors and compilers
 Programs can present two kinds of threats:
─ Information access threats
● Intercept or modify data on behalf of users who
should not have access to that data
─ Service threats
● Exploit service flaws in computers to
inhibit use by legitimate users

52