Information Security

Malicious Code and Application Attacks

 Outline
 Malicious code
 Password attacks
 DOS Attack
 Application attacks
 Web application security
 Reconnaissance attack (gathering information about a target system or network)
 Masquerading attack
 Malicious Code

• Set of instructions that cause a site’s

security policy to be violated
• Often leveraging an inadvertent flaw (design
or implementation for maximum advantage)
– To propagate/install on target
– To cause harm on target
 Malware Summary
• Malware covers all kinds of intruder software
Code Type Characteristics
Virus Attaches itself to program and copies to other
program

Trojan Horse Contains unexpected, additional functionality

Logic Bomb Triggers action when condition occurs
Time Bomb Triggers action when specified time occurs
Trapdoor Allows unauthorized access to functionality
Worm Propagates copies of itself through the network
Root Kit Hooks standard OS calls to hide data
 Rootkits
• A rootkit is a stealthy type of malware designed to hide
the existence of certain processes or programs from
normal methods of detection and enable continued
privileged access to a computer
• Insert file filters to cause files or directories disappear
from normal listings
• Techniques apply equally well to Linux and Mac
• Detection is difficult because a rootkit may be able to
subvert the software that is intended to find it.
• Detection methods include using an alternative and
trusted operating system, behavioral-based methods,
signature scanning, difference scanning, and memory
dump analysis.
• Removal can be complicated or practically impossible,
especially in cases where the rootkit resides in the kernel
 Anti-virus software
• Initially: signature detection.
• But signatures are not enough!
– Pattern matching
– Automatic learning
– Environment emulation
– Neural networks
– Data mining
– Bayes networks (probabilistic graphical model used to represent and
analyze uncertain relationships between variables)

– Hidden Markov models(statistical model used to describe systems )

 Signature Avoiding Viruses
• Polymorphic Virus produces varying but
operationally equivalent copies of itself
– Use alternative but equivalent instructions
– Gets around signature scanners.
• Stealth Virus actively tries to hide all signs of its
presence
– A virus can intercept calls to read a file and return
correct values about file sizes etc. Brain Virus
 Sandboxes
• A sandbox is a security mechanism
for safely running untrusted programs
– Provides a tightly-controlled set of resources for guest
programs to run in, such as space on disk and memory.
Network access, the ability to inspect the host system or
read from input devices is usually disallowed or heavily
restricted. E.g. virtual machine.
• Examples of sandboxes are:
– Applets are self-contained programs that run in a virtual
machine or scripting language interpreter that does the
sandboxing, for example in the browser.
– Jails are a special kind of resource limit imposed on
programs by the operating system.
– Virtual machines emulate a complete host computer, on
which an entire operating system can run.
 Why we have so much malware?
• Users are ill-educated, resulting in distribution
as Trojans and viruses
– Because computers are fast-changing and still
relatively new
• Software has vulnerabilities, resulting in
distribution of worms and viruses
– Because it is badly written or badly designed
– Because the designers have historically favoured
user convenience over security
• The PC is an open platform
– Users can install software, in contrast with (old
fashioned) mobile phones, mp3 players, set-top
boxes, embedded computers, etc.
 The Threat of Monopoly
• Another reason for the prevalence of malware
is the homogeneity of software
– Most computers run Windows, MS Office, MS
Outlook Express, MS Internet Explorer
– This makes the attacker’s job very easy.
• In contrast, in the linux world, there is a plenty
of rival distributions, office suites, email
clients, browsers.
– Makes the attacker’s job much, much harder!
 Open-source vs closed source
• It is often argued that • But one can also argue
– OS more secure that
– OS less secure because
because vulnerabilities attackers can see the code and
have a much higher find vulnerabilities to exploit.
chance of being – CS more secure because
attacker doesn’t have access to
spotted, since hundreds the source code.
of people around the – However, this argument is “security
world are scrutinising through obscurity” and should be
rejected.
the source code.
– CS less secure
because very few
people have access to
the source code.
 Trend towards crime

“Modern bots and trojans spread more stealthily,

remaining below the detection radar... They infect
your PC and wait for instructions more than
worms.”
 The future
• The tension between flexibility and security will
continue to introduce vulnerabilities
– especially in emerging domains, such as wearables and
multi-functional devices
• But users will continue to become better educated,
and established software will continue to mature
and become less vulnerable
• And PCs continue to become “locked-down”
– draconian firewalls, sandboxes, fewer user priviliges
– Trusted computer platforms
• Thus, things will slowly get better, but at a high
price, and we will still see some spectacular
attacks
 Password -I
 Password cracking is the process of recovering
passwords from data that has been stored in or
transmitted by a computer system
 Passwords to access computer systems are usually
stored in a database so the system can perform
password verification when a user attempts to login or
access a restricted resource.
 To preserve confidentiality of system passwords, the
password verification data is typically not stored in
cleartext form, but instead a one-way function is applied
to the password, possibly in combination with other data,
and the resulting value is stored.
 Password - II
 When a user later attempts to authenticate by entering
the password, the same function is applied to the
entered value and the result is compared with the stored
value. If they match, there is an extremely high likelihood
the entered password was correct.
 For simplicity in this discussion, we will refer to the one
way function employed (which may be either an
encryption function or cryptographic hash) as a hash and
its output as a hashed password.
 Password - III
 If a system uses a poorly designed password hashing
scheme to protect stored passwords, an attacker can
exploit any weaknesses to recover even 'well-chosen'
passwords.
 One example is the LM hash that Microsoft Windows XP
and previous uses by default to store user passwords of
less than 15 characters in length. LM hash converts the
password into all uppercase letters then breaks the
password into two 7-character fields which are hashed
separately—which allows each half to be attacked
individually.
 Password Types
 Password that contain only letters
 Password that contain only numbers
 Password that contain only special characters
 Password that contain letters and numbers
 Password that contain only letters and special characters
 Password that contain only special characters and
numbers
 Password that contain letters, special characters and
numbers
 Guessable Password
 Passwords can sometimes be guessed by humans with knowledge of the user's
personal information. Examples of guessable passwords include:
• blank (none)
• the words "password", "passcode", "admin" and their derivatives
• a row of letters from the qwerty keyboard -- qwerty itself, asdf, or
qwertyuiop)
• the user's name or login name
• the name of their significant other, a friend, relative or pet
• their birthplace or date of birth, or a friend's, or a relative's
• their automobile license plate number, or a friend's, or a relative's
• their office number, residence number or most commonly, their mobile
number.
• a name of a celebrity they like
• a simple modification of one of the preceding, such as suffixing a digit,
particularly 1, or reversing the order of the letters.
• a swear word.
• and so, extensively, on.
 Types of password Attacks
 Dictionary attack
 Brute force attack
 Hybrid attack
 Social engineering
 Shoulder surfing
 Dumpster diving
Manual Password Cracking

Source: EC Council
Automatic Password Cracking

Source: EC Council
 Password Cracking
Countermeasures
 Enforce 7-12 character alphanumeric passwords
(Preferably with special characters).
 Set the password change policy to 30 days.
 Physically isolate and protect the server
 Store encrypted hashes in the disk
 Monitor the server logs for brute force attacks on user
accounts
 Keep computer clean from malware ( Trojan horse,
Keylogger, spyware etc.)
 Levels of Security
Human level: Corrupt/careless User
Network/User Interface
Database application program
Database system
Operating System
Physical level
 Network Level Security
Must use encryption to prevent
 Eavesdropping: unauthorized reading of
messages
 Masquerading:
• Pretending to be an authorized
user or legitimate site, or
• Sending messages supposedly
from authorized users

24
DoS and DDoS
 Definition
 Denial-of-service (DoS) attack aims at disrupting the
authorized use of networks, systems, or applications
 by sending messages which exhaust service provider’s
resources ( network bandwidth, system resources, application
resources)
 Distributed denial-of-service (DDoS) attacks employ
multiple (dozens to millions) compromised computers to
perform a coordinated and widely distributed DoS attack
 Victims of (D)DoS attacks
 service-providers (in terms of time, money, resources, good will)
 legitimate service-seekers (deprived of availability of service
itself)
 Zombie systems(Penultimate and previous layers of
compromised systems in DDoS)
 Approaches to DoS attacks
 Internet designed for minimal-processing and best-
effort forwarding any packet
 Make shrewd use of flaws in the Internet design and systems
 Unregulated forwarding of Internet packets :
Vulnerability ,Flooding
 Vulnerability attack
 Vulnerability : a bug in implementation or a bug in a default
configuration of a service
 Malicious messages (exploits) : unexpected input that utilize
the vulnerability are sent
 Consequences :
• The system slows down or crashes or freezes or reboots
• Target application goes into infinite loop
• Consumes a vast amount of memory
 Ex : Ping of death
 Approaches to DoS attack - II
 Flooding attack
 Work by sending a vast number of messages whose
processing consumes some key resource at the
target
 The strength lies in the volume, rather than the
content
 Implications :
• Make the traffic look legitimate
• Flow of traffic is large enough to consume victim’s
resources
• Send with high packet rate
• These attacks are more commonly DDoS
 Classical DoS attacks
 Simplest classical DoS attack: Flooding attack on an
organization
 Ping flood attack

Service denied
to legitimate
users

29
 Flooding attacks
 Goal : Bombarding large number of malicious packets at
the victim, such that processing of these packets
consumes resources
 Any type of network packet can be used
 Attack traffic made similar to legitimate traffic
 Valid traffic has a low probability of surviving the discard
caused by flood and hence accessing the server
 Some ways of flooding :
 To overload network capacity on some link to a server
 To overload server’s ability to handle and respond to this traffic
 The larger the packet, the more effective the attack
 Types of flooding attacks
 Classified based on type of network protocol used to
attack
 ICMP flood
 Uses ICMP packets , ex: ping flood using echo request
 Typically allowed through, some required
 UDP flood
 Exploits the target system’s diagnostic echo services to create
an infinite loop between two or more UDP services
 TCP SYN flood
 Use TCP SYN (connection request packets)
 Distributed Denial-of-service
 Attacker uses multiple compromised user work
stations/PCs for DoS by:
 Utilising vulnerabilities to gain access to these systems
 Installing malicious backdoor programs , thereby making
zombies
 Creating botnets: large collection of zombies under the control of
attacker
 Generally, a control hierarchy is used to create botnets
 Handlers: The initial layer of zombies that are directly controlled
by the attacker
 Agent systems: Subordinate zombies that are controlled by
handlers
 Attacker sends a single command to handler, which then
automatically forwards it to all agents under its control
 DDoS control hierarchy
 Example: Tribe Flood Network (TFN)
 Relied on large number of compromised systems and layered
command structure

Command-line
program

Trojan Program
 DDoS attack toolkits
 Some popular DDoS programs
 Trinoo,TFN,Stacheldraht,Shaft,TFN2K,Mstream,Trinity,Phatbot
 Blended threat toolkits: Include some (all) of the
following components
 Windows network service program
 Scanners
 Single-threaded DoS programs
 An FTP server
 An IRC file service
 An IRC DDoS Bot
 Local exploit programs
 Remote exploit programs
 System log cleaners
 DoS Detection Techniques
 Goal: To detect and distinguish malicious packet traffic
from legitimate packet traffic
 Flash crowds: High traffic volumes may also be
accidental and legitimate
 Highly publicized websites: (unpredictable) news aggregation
site
 Much-awaited events: (Predictable) Olympics, SLC result etc.
 There is no innate Internet mechanism for performing
malicious traffic discrimination
 Once detected, vulnerability attacks are easy to be
addressed
 If vulnerability attacks volume is so high that it manifests
as flooding attack, very difficult to handle
 Vulnerability Attack Detection Techniques
Detection techniques can be installed locally or remotely
Locally : detectors placed at potential victim resource
or at a router or firewall within the victim’s subnetwork
Remotely: To detect propagating attacks
Attack defined by detection methods:
 an abnormal and noticeable deviation of some statistic of the
monitored network traffic workload
 Proper choice of statistic is crutial
Also can use statistical detection methods e.g. activity
profiling
 Defenses against DoS attacks
 DoS attacks cannot be prevented entirely
 Impractical to prevent the flash crowds without
compromising network performance
 Three lines of defense against (D)DoS attacks
 Attack prevention and preemption
 Attack detection and filtering
 Attack source traceback and identification

37
 Defenses against DoS attacks -II
 Block IP broadcasts
 Block suspicious services & combinations
 Manage application attacks with “puzzles” to
distinguish legitimate human requests
 Good general system security practices
 Use mirrored and replicated servers when high
performance and reliability required

38
 Responding to attacks
 Need good incident response plan
 With contacts for ISP
 Needed to impose traffic filtering upstream
 Details of response process
 Have standard antispoofing, rate limiting,
directed broadcast limiting filters
 Ideally have network monitors and IDS
 To detect and notify abnormal traffic patterns
 Responding to attacks - II.
 Identify the type of attack
 Capture and analyze packets
 Design filters to block attack traffic upstream
 Identify and correct system application bugs
 Have ISP trace packet flow back to source
 May be difficult and time consuming
 Necessary if legal action desired
 Implement contingency plan
 Update incident response plan
 ‘’For next meet’’
Application Attacks
 Why should we care about Web
Application Attacks?

Security Spending
% of Attacks % of Dollars

Web 10%
Application
s

75% 90%

Network
Server
25%

75%of All Attacks on Information Security

Are Directed to the Web Application Layer
 Application Vulnerabilities

43
 Application Threat Negative Impact Example Impact

Cross Site scripting Identity Theft, Sensitive Hackers can impersonate legitimate users,
Information Leakage, … and control their accounts.
OWASP Top 10 Application Attacks
Injection Flaws Attacker can manipulate queries Hackers can access backend database
to the DB / LDAP (Light Weight information, alter it or steal it.
Directory Access Protocol) / Other
system
Malicious File Execution Execute shell commands on Site modified to transfer all interactions to
server, up to full control the hacker.

Insecure Direct Object Attacker can access sensitive files Web application returns contents of
Reference and resources sensitive file (instead of harmless one)

Cross-Site Request Attacker can invoke “blind” actions Blind requests to bank account transfer
Forgery on web applications, money to hacker
impersonating as a trusted user

Information Leakage and Attackers can gain detailed Malicious system reconnaissance may
Improper Error Handling system information assist in developing further attacks

Broken Authentication & Session tokens not guarded or Hacker can “force” session token on victim;
Session Management invalidated properly session tokens can be stolen after logout

Insecure Cryptographic Weak encryption techniques may Confidential information (SSN, Credit Cards)
Storage lead to broken encryption can be decrypted by malicious users

Insecure Communications Sensitive info sent unencrypted Unencrypted credentials “sniffed” and used
over insecure channel by hacker to impersonate user

Failure to Restrict URL Hacker can access unauthorized Hacker can forcefully browse and access44
a
 Web Application Architecture
Customer Sensitive
App is deployed data is
here stored here

Internet
Internet

Firewall

Client Tier
(Browser) Database
SSL App Server
(Presentation)
(Business
Logic)
Protects
Transport Protects Data Tier
Middle Tier
Network
 What is Web Application
Security?
 Not Network Security
 Securing the “custom code” that drives a web
application
 Securing libraries
 Securing backend systems
 Securing web and application servers

 Network Security Mostly Ignores the Contents of

HTTP Traffic
 Firewalls, SSL, Intrusion Detection Systems,
Operating System Hardening, Database Hardening
 Code is Part of Your Security
Perimeter
Your security “perimeter” has huge
holes at the application layer
Application Layer

Legacy Systems

Human Resrcs
Web Services
Directories
Databases

Billing
Custom Developed
Application Code
APPLICATION
ATTACK

App Server
Web Server
Network Layer

Hardened OS

Firewall
Firewall

You can’t use network layer protection (firewall, SSL, Intrusion Detection system, hardening)
to stop or detect application layer attacks
 Why Application Security is a
High Priority?
 Web applications are the #1 focus of hackers:
 75% of attacks at Application layer (Gartner)
 XSS (cross site scripting) and SQL Injection are #1 and #2 reported
vulnerabilities (Mitre)

 Most sites are vulnerable:

 90% of sites are vulnerable to application attacks (Watchfire)
 78% percent of easily exploitable vulnerabilities affected Web applications
(Symantec)
 80% of organizations will experience an application security incident
(Gartner)

 Web applications are high value targets for hackers:

 Customer data, credit cards, ID theft, fraud, site defacement, etc

 Compliance requirements:
 Application Security Problems

Root Cause:
 Developers are not trained to write or test for secure code
 Network security (firewall, IDS, etc) does not protect the Web
Application Layer
Current State:
 Organizations test tactically at a late & costly stage in the SDLC
 A communication gap exists between security and development
as such vulnerabilities are not fixed
 Testing coverage is incomplete
 Critical Web Application Security
Vulnerabilities
1. Unvalidated Parameters
2. Broken Access Control
3. Broken Account and Session Management
4. Cross-Site Scripting (XSS)
5. Buffer Overflows
6. Command Injection Flaws
7. Error Handling Problems
8. Insecure Use of Cryptography
9. Remote Administration Flaws
10.Web and Application Server Misconfiguration
 (1). Unvalidated Parameters
 Information from web requests is not validated
before being used by a web application.
 URL, Querystring, Form Fields, Hidden Fields,
Cookies, Headers
 Web apps use this information to generate web pages
 Attackers can use these flaws to attack
background components through a web
application.
 How to Protect ( Countermeasures)
Ensure that all parameters are validated
before they are used.
 Data type (string, integer, real, etc.)
 Allowed character set
 Minimum and maximum length
 Whether null is allowed
 Whether the parameter is required or not
 Whether duplicates are allowed
 Numeric range
 Specific legal values (enumeration)
 Specific patterns (regular expressions)
 (2). Broken Access Control
 Restrictions on what authenticated users are
allowed to do are not properly enforced.
 Many sites have a complex access control policy
 Insidiously difficult to implement correctly
 Attackers can exploit these flaws to access other
users' accounts, view sensitive files, or use
unauthorized functions.
 How to Protect ( Countermeasures)
 Think through an application's access control
and capture it in a web application security
policy.
 Some specific access control issues include:
 Insecure Id's
 Forced Browsing Past Access Control Checks
 Path Traversal
 File Permissions
 Client Side Caching
 Implement access control in a centralized
module
 (3). Broken Account and Session
Management
Account Management
 Handling credentials across client-server gap
 Backend authentication credentials too
Session Management
 HTTP is a “stateless” protocol. Web
applications need to keep track of which
request came from which user
 “Brand” sessions with an id using cookie,
hidden field, URL tag, etc…
 How to Protect ( Countermeasures)
 Careful and proper use of custom or off the shelf
authentication and session management
mechanisms
 Password Change Controls
 Password Strength
 Password Storage
 Protecting Credentials in Transit
 Session ID Protection
 Account Lists
 Browser Caching
 Backend Authentication
 (4). Cross-Site Scripting (XSS)
 What is it?
 The web application can be used as a mechanism to
transport an attack to an end user's browser.
 Malicious script echoed back into HTML returned from
a trusted site, and runs under trusted context

 What are the implications?

 A successful attack can disclose the end user's
session token, attack the local machine, or spoof
content to fool the user
 Cross Site Scripting – The Exploit
Process
Evil.org

5) Evil.org uses stolen

1) Link to bank.com session information to
sent to user via impersonate user
E-mail or HTTP
4) Script sends user’s
cookie and session
information without the user’s
consent or knowledge
User bank.com
2) User sends script embedded as data

3) Script/data returned, executed by browser

XSS Web Application Hijack Scenario

www.hacker.com
 Exploiting XSS
 If I can get you to run my JavaScript, I can…
 Steal your cookies for the domain you’re browsing
 Track every action you do in that browser from now on
 Redirect you to a Phishing site
 Completely modify the content of any page you see on
this domain
 Exploit browser vulnerabilities to take over machine
…
 XSS is the Top Security Risk today (most
exploited)
 How to Protect ( Countermeasures)

 Detailed code review that searches the code for

validation of all headers, cookies, query strings,
form fields, and hidden fields (i.e., all
parameters)
 (5). Buffer Overflows
 Web applications read all types of input from
users
 Libraries, DLL’s ( Dynamic Link Libraries), Server
code, Custom code, Exec
 Web application components in some languages
that do not properly validate input can be
crashed and, in some cases, used to take
control of a process.
 C and C++ code is vulnerable to buffer overflows
 Input overflows end of buffer and overwrites the stack
 Can be used to execute arbitrary code
 How to Protect ( Countermeasures)
 Keep up with the latest bug reports for your web
and application server products and other
products in your Internet infrastructure. Apply the
latest patches to these products.
 Review all code that accepts input from users
via the HTTP request.
 (6). Command Injection Flaws
 Web applications pass parameters when they access
external systems or the local operating system.
 User-supplied data is sent to an interpreter as part of a
command, query or data.
 If an attacker can embed malicious commands in
these parameters, the external system may execute
those commands on behalf of the web application.
 What are the implications?
 SQL Injection – Access/modify data in DB
 SSI Injection – Execute commands on server and
access sensitive data
 LDAP (Lightweight Directory Access Protocol) Injection
– Bypass authentication
 …
 SQL Injection

User input inserted into SQL Command:

 Get product details by id:
Select * from products where
id=‘$REQUEST[“id”]’;
 Hack: send param id with value ‘ or ‘1’=‘1
 Resulting executed SQL:
Select * from products where id=‘’ or ‘1’=‘1’
 All products returned
 SQL Injection

SQLQuery =
“SELECT  FROM Users WHERE (UserName='” +
strUN + “') AND (Password='” + strPW + “');”

 User name “fredchen”, password “199msq” :

SELECT  FROM Users WHERE (UserName='fredchen')
AND (Password='199msq');
 SQL Injection: User name/Password : ' OR 'A'='A

SELECT  FROM Users WHERE

(UserName='' OR 'A'='A') AND
(Password='' OR 'A'='A');
68
 How to Protect ( Countermeasures)
 Avoid the use of commands where possible.
 Carefully validate the data provided to ensure
that it does not contain any malicious content.
 Ensure that the web application runs with only
the privileges it absolutely needs to perform its
function.
 Any user information that is being inserted into
the command should be rigorously checked.
 (7). Error Handling Problems
 Errors occur in web applications all the time
 Out of memory, too many users, timeout, db failure
 Authentication failure, access control failure, bad input
 If an attacker can cause errors to occur that the
web application does not handle, they can gain
detailed system information, deny service, cause
security mechanisms to fail, or crash the server.
 How to Protect ( Countermeasures)
 A specific policy for how to handle errors should
be documented.
 Need to tell user what happened (no hacking clues)
 Ensure that the site is built to gracefully handle
all possible errors.
 Certain classes of errors should be logged to
help detect implementation flaws in the site
and/or hacking attempts.
 (8). Insecure Use of Cryptography
 Web applications frequently use cryptographic
functions to protect information and credentials.
 Algorithms are simple to use, integrating them is
hard
 These functions and the code to integrate them
have proven difficult to code properly, frequently
resulting in weak protection.
 How to Protect ( Countermeasures)
 Minimize the use of encryption and only keep
information that is absolutely necessary.
 Choose a library that has been exposed to
public scrutiny and make sure that there are no
open vulnerabilities.
 Encapsulate the cryptographic functions that are
used and review the code carefully.
 Be sure that secrets, such as keys, certificates,
and passwords, are stored securely.
 Don’t store user passwords – use a hash like
SHA-256
 (9). Remote Administration Flaws
 Many web applications allow administrators to
access the site using a web interface.
 If these administrative functions are not very
carefully protected, an attacker can gain full
access to all aspects of a site.
 How to Protect ( Countermeasures)
 Never allow administrator access through the
front door if at all possible.
 The use of strong authentication such as
certificates, token based authenticators,...
 The use of encryption (e.g., VPN or SSL) for the
entire administrative session.
 Interfaces be separate from interfaces provided
to normal users.
 Network separation or IP filtering.
 (10). Web and Application Server
Misconfiguration
All web and application servers have
many security-relevant configuration
options
 Default accounts and passwords
 Unnecessary default, backup, sample apps,
libraries
 Overly informative error messages
 Misconfigured SSL, default certificates, self-
signed certs
 Unused administrative services
 How to Protect ( Countermeasures)
 Create a hardening guideline for configuration:
 Configuring all security mechanisms
 Turning off all unused services
 Setting up roles, permissions, and accounts
 Logging and alerts
 Configuration maintenance:
 Monitoring the latest security vulnerabilities published
 Applying the latest security patches
 Updating the security configuration guideline
 Regular vulnerability scanning from both internal and
external perspectives
 Regular status reports to upper management
documenting overall security posture
 Security Guidelines

a) Validate Input and Output

b) Fail Securely (Closed)
c) Keep it Simple
d) Use and Reuse Trusted Components
e) Defense in Depth
f) Only as Secure as the Weakest Link
g) Security By Obscurity Won't Work
h) Least Privilege
i) Compartmentalization (Separation of
Privileges)
 a. Validate Input and Output
 All user input and user output should be
checked to ensure it is both appropriate and
expected.
 Allow only explicitly defined characteristics and
drop all other data.
 b. Fail Securely (Closed)
 When it fails, it fails closed.
 It should fail to a state that rejects all subsequent
security requests.
 A good analogy is a firewall. If a firewall fails it
should drop all subsequent packets.
 c. Keep it Simple

 If a security system is too complex for its user

base, it will either not be used or users will try to
find measures to bypass it.
 This message applies equally to tasks that an
administrator must perform in order to secure an
application.
 This message is also intended for security layer
API's that application developers must use to
build the system.
 d. Use and Reuse Trusted
Components
 Using and reusing trusted components makes
sense both from a resource stance and from a
security stance. When someone else has
proven they got it right, take advantage of it.
 e. Defense in Depth
 Relying on one component to perform its
function 100% of the time is unrealistic.
 While we hope to build software and hardware
that works as planned, predicting the
unexpected is difficult. Good systems don't
predict the unexpected, but plan for it.
 f. Only as Secure as the Weakest Link
 Careful thought must be given to what one is
securing.
 Attackers are lazy and will find the weakest point
and attempt to exploit it.
 g. Security By Obscurity Won't Work
It's naive to think that hiding things from
prying eyes doesn't buy some amount of
time.
This strategy doesn't work in the long term
and has no guarantee of working in the
short term.
 h. Least Privilege
 Systems should be designed in such a way that
they run with the least amount of system
privilege they need to do their job .
 i. Compartmentalization
(Separation of Privileges)
 Compartmentalizing users, processes and data
helps contain problems if they do occur.
 Compartmentalization is an important concept
widely adopted in the information security realm.