CISSP: Application Security

Presented by Pascal Meunier, M.Sc., Ph.D., CISSP

Purdue University CERIAS
August 21, 2007

1
 Scope & Learning Objectives

 This presentation:
• won't teach you everything you need to
know
• will present an overview of the subject
area
» this will help you prepare your plan of
study and identify areas you need to
strengthen
 What is in this domain?

 From the (ISC)2 Store:

• Applications Development &
Programming Concepts
• Audit and Assurance Mechanisms
• Malware
• Database and Data Warehousing
Environments
• Web Application Environments
 Remapping the Subject Areas

 Software Engineering
 Threats and Countermeasures
 Database Systems security
 Web Application Security
 CISSP Prep Guides

 Software controls
• vs environment
 Software lifecycle
• Change control
 Object-oriented components
 Some technologies
• Java, etc...
 Why Secure Software?
(Motivation)
 Appliances (e.g., firewalls) do not
provide complete security
• Insider attacks
• Bypassed by proxy servers, VPNs
 Same software can be used by
different users with different
privileges
 Many security layers help
 Security Approaches

 Reactive (expensive and slow)

• Vulnerability scanning and patching
• Intrusion detection
• Incident response
 Proactive
• More secure software and technologies
» Designed
» Configured
 Security Approaches

 Black Lists
• Forbid known bad things (or look for
them)
• Always one step behind
• Prone to failure as attackers figure out
ways around the blocks
 White Lists
• Allow only what's known to be safe
• Make it provably safe
 Software Engineering Areas

 Requirements
 Design
 Construction
 Testing
 Maintenance
 See: “Software Engineering Body of Knowledge”
a.k.a. “SWEBOK”
 Requirements

 Security functional
• Logging
• Password quality checks
 Security Assurance
• Testing
• Code audits
» Code checking tools

 See lists in Common Criteria (NIST)

 Which Requirements?

 Threats vs countermeasures (controls)

• Threat modeling
• Threat assessment
• Risk analysis
• Risk assessment
 Definition of “Controls”

 Read as “things that improve security”

• Prevent
• Detect } policy violations
• Correct
 Using means
• Physical
• Administrative
• Technical (a.k.a. logical)
 Administrative Controls

 Policies
 Procedures
 Standards
 Guidelines
 e.g., must get approval to make a
code change
 Physical Controls

 Software development and production

environments should be secured
 Physical access
• Servers, workstations
• Network plugs
 Temperature, power
 Activity monitoring
• Cameras
 Logical Controls

 Protect data (confidentiality, integrity)

and resources (availability)
 Database controls
• Accounts
• Roles
• Transactions
 File system controls
• Permissions (someone name another?)
 Risk Analysis

 Do the defenses match the risks?

 Cost vs risk
• Typically more secure systems cost
more to build
» Not always true, c.f. Spark EAL 5 study
– But the CISSP test doesn't want to argue
fine points

 Security vs functionality
 Threats, Vulnerabilities and
Attacks
 Vulnerabilities and the Software
Development Life Cycle
• Object-Oriented Programming
• Capability-Maturity Model
 Malware definitions
 Detecting attacks
• Expert systems and artificial intelligence
 Software Development Life
Cycle (SDLC)
 Feasibility study
 Requirements definition
 Design
 Implementation
 Integration and testing
 Operations and maintenance
 Simplified SDLC

 Design (first 3 phases)

 Implementation (phases 4 and 5)
 Operation and maintenance
 People often like to discuss
vulnerabilities according to the SDLC
phase in which they were introduced
• sometimes ambiguous
 Quick Question

 “Construction” in SWEBOK
corresponds to which SDLC phase?
 Vulnerabilities & Flaws

 Vulnerability: “An instance of an error in the

specification, development, or configuration of
software such that its execution can violate the
security policy" [Krsul 98].
 Flaw: a flaw defines or implies what should have
been done to prevent policy violations; it is a
problem at a higher level of abstraction that may
potentially enable several different attacks and
create various vulnerabilities.
• example flaw: missing input validation
 Vulnerability Types

 It is common to refer to the set of vulnerabilities

that enable attack scenario X as “X vulnerabilities”,
e.g., “cross-site scripting vulnerabilities”
 Sometimes the name of a technology is used instead
of the name of an attack, e.g., “format string
vulnerabilities”.
• Question: name another popularly named
vulnerability type.
 Secure Programming

 A set of processes, techniques and a

way of thinking about software
engineering to minimize the
occurrence of flaws and
vulnerabilities
• In general, fewer bugs mean fewer
vulnerabilities
» Software engineering methods that
prevent bugs are good for security
 Secure Programming

 Input validation
• Boundary identification and formation
• Input awareness
• Taint tracking
 Secure programming principles
 Code checkers
 Code integrity with formal methods
 Principles

 Least privilege

 Economy of mechanism

 Complete mediation

 Open design

 Separation of privilege

 Least common mechanism

 Psychological acceptability

 Fail-safe defaults (deny by default; white list)

 Object-Oriented
Programming
 Fundamental idea: encapsulate data
with the procedures that manipulate
it into a logical entity (“object”)
• Forbid direct access to the data, so that
» Invariants can be enforced
– Data integrity is stronger
» Only pre-defined actions can be taken
– Decreases the possibility of malicious or
erroneous actions
 OOP Things to Know

 Instance
 Inheritance
 Polymorphism
• Common methods defined by a common
parent class (superclass)
 Polyinstantiation
 Object Request Brokers (ORB)
 Capability Maturity Model

 Software development processes

• Level 1: Ad Hoc (heroics)
• Level 2: Repeatable
• Level 3: Defined
• Level 4: Quantitatively Managed
• Level 5: Optimizing
 From an artisan approach (1) to an
engineering science (5)
 Definitions

 Attack code
• Attack code aims at exploiting vulnerabilities, and
is commonly found in the form of attack scripts
or proof-of-concept exploits. Worms are another
example of attack code. Malicious code isn’t
necessarily attack code, but its mere presence
may imply that the system was compromised by a
prior attack. Malicious code resident on a victim
computer and performing an undesirable
function, such as spyware, rootkits or backdoors,
is to be differentiated from attack code that
exploits vulnerabilities.
 Definitions

 Parasitic code
• Parasitic code is code that is attached or included
in another document or executable and violates
its integrity. Intended or original properties of
the document or executable must be identifiable
in order to determine the presence, nature and
extent of the parasite. Parasitic code is not
necessarily attack code.
 Definitions

 Back-Door
• A back-door is code bypassing policy-approved user
authentication mechanisms. Back-doors are usually
hidden, hard to discover, and inserted and used for
malicious purposes. For example, a remote user may
issue commands as root through a previously installed
back-door. Some back-doors are created by
programmers for reasons of convenience (e.g., remote
maintenance) and so the original intent may not be
malicious. However, back-doors that violate security
policies must be considered malicious, based on their
behavior alone. Remote access mechanisms operating
within policy are not to be confused with back-doors.
 Definitions

 Trojan
• Code that gets executed by deceiving a user is a
trojan (the deception aspect implies
maliciousness, even if it is a mild prank). Trojans
can carry and be the initial entry mechanism for
malicious code of another nature (e.g., a back-
door or keylogger).
 Definitions

 Self-Propagating code (two modes)

●
Viruses are parasitic and are spread by means of
finding new host files (documents or
executables) that will presumably also get read
or run later. Macro viruses refer to viruses
carried by documents which can carry “macros”,
essentially a scripting capability which blurs the
boundary between data and code.
●
Worms spread on their own, by duplicating their
code to other systems and re-spawning their
processes.
 Famous Worms

 Code Red
 Blaster
 SQL Slammer
 Nachi (Welchia)
 Be prepared to answer a few
questions about viruses and worms
 Definitions

 Spyware
• Spyware is code that reports user activities and
system information to “unauthorized” parties
(who is “unauthorized” may depend on
perspective). An example is an “unauthorized”
keylogger. Spyware could also take “interesting”
forms such as being a virus, and reporting when a
certain type of document is opened.
 Definitions

 Logic/Time triggered code

• This is extraneous code that is not part of the
expected function of a software artifact and
remains dormant until very specific activation
conditions are met. If it can then perform
attacks, it is a “Bomb”. If not, and it simply
exposes humorous (at least to some) content, it is
considered an “Easter egg”. Some Digital Rights
Management (“DRM”) code that violates a security
policy, e.g., while trying to aggressively enforce a
licensing agreement, could be considered
triggered code.
 Definitions

 Rootkit
• A rootkit is a set of software artifacts that
attempts to conceal its existence and execution
(and possibly that of other malicious software as
well) from the rest of the operating system, other
processes or security tools, and consequently
from users and administrators. Typically a
rootkit subverts or replaces the utilities included
with an operating system for the purposes of
hiding a compromise and a back-door. A rootkit
may include attack code as one of its components
and may resist removal.
 Definitions

 Distributed code
• Distributed code has coordinated copies of itself on
many hosts. By acting in a coordinated fashion, the
distributed code attempts goals that would likely be
unreachable for a single copy. The coordination
mechanism may be the reception of commands, or
interactions between copies or with a controller.
Blindly following specially crafted rules of conduct
may also result in the overall desired behavior. Worms
have been known to include a time bomb for attacking
a pre-determined target at a given time, resulting in a
distributed attack.
 Distributed Code: Botnets

 Botnets are organized “networks of

robots” obeying commands from a
particular source, unknown to the
owners of the computers
• Often ill-protected home computers
 Used for
• Spamming
• Distributed Denial-of-Service (DDoS)
attacks
 Detecting Attacks

 Intrusion Detection Systems (IDS)

typically use two types of
technologies:
• Expert systems
» rules defined by experts
» usually detects only known attack types
• Artificial neural networks
» system is trained to detect attacks
» may detect new attacks
 Software Threats

 1999 DARPA IDS classification:

●
Probe (or surveillance, information gathering: activity)
●
Denial of service (consequence of an attack)
●
R2L (remote to local), i.e., unauthorized access from a
remote machine
●
U2R (user to root), i.e., unauthorized transition to root
for an unprivileged user
●
Data. This is meant to represent attacks whose goal is to
obtain and extract (“exfiltrate”) confidential files from a
system
 Anomaly Detection

 Detect abnormal patterns of behavior

 Neural network approach
• Trained with normal behavior data
» False positives and false negatives are
given a “cost”
» System tries to minimize overall cost

 Expert systems approach next slide

 AppArmor Anomaly Detection

 Idea: observe what an application

needs to do, and forbid everything
else
• Phase 1: make rules for what is allowed,
based on observation
• Phase 2: rules are frozen in a profile
 http://en.opensuse.org/Apparmor
 Signature Detection

 Look for known patterns of behavior

that indicate attacks
 Static set of rules
• e.g., Snort
 Clearly an expert system approach
 Integrity Checks

 a.k.a. “target monitoring”

 Verify at regular intervals that what is
not supposed to change hasn't
• Compute hashes
• Verify system invariants
» e.g. cash on hand = starting money +
deposits - withdrawals

 e.g., Tripwire
 Database Security

 Database types
 Database access control mechanisms
 Database integrity
 Database attacks and
countermeasures
 Relational Databases

 Tables, rows, primary keys

» Foreign key constraints link a table to
another
– e.g., a table for people and another for
possessions
– Guarantees integrity by making sure that
there aren't possessions without an
owner
» 3rd normal form avoids duplicate and
inconsistent data
 Database Access Control

 Views
• Only provide the data needed
 Stored Procedures
• Code executed in the database
 Roles
• Avoid errors in the repetitive assignment
of permissions to users
• Reason about types of users
 Stored Procedures

 Usually people think of the speed

benefit
 Important security benefits as well
• Add checks (controls) at choke point
» Protect invariants and data integrity
• Guarantee that things are done the right
way (processes are followed)
• Define which actions are allowed
 Example Logging Setup

 Role “A” for creating tables

 Role “B” for creating stored
procedures. Example: the procedures
only allow reading (select) and inserts
but not deleting or updating
 Role “C” that can only execute stored
procedures. Role “C” can't delete or
modify existing rows
 Database Integrity

 Transactions
• Transactions are groups of database
operations that either fail or succeed as
a group
» e.g., read value A, calculate A-X, store
new value
– If A changes after reading and before
storing the new value, bad things could
happen
• Transactions preserve invariants
 Database Attacks and
Countermeasures
 Attack: SQL injection
• Uses meta-characters such as ' ” ; in
data to change the meaning of
commands sent to the database
 Countermeasure: Parameterized
Queries
• Send the commands and data separately
so there can be no confusion
 Web Application Security

 Trust Analysis
 Polluted web sites
• Cross-site scripting
• Malicious ads
 Malicious web sites
 Client-side scripting as an attack
vector
 Trust Analysis

 Do you know where this data has

been?
 Shopping web applications
• Send list of items with price to client
• Client returns to the server selected
items for purchase, with the price
• Server trusts the price returned by the
client
» Attacker says the price is $0.01 !
 Polluted Web Sites

 Attackers adding malicious content to

innocent web sites
• Could be malicious ads
» Web site owners have little control over
the ads provided to them for display
• Could be in user-provided information
» XSS (cross-site scripting) attacks
» MySpace worm
 Malicious Web Sites

 Attacks against your browser

 Attacks against other sites you visited
before and authenticated to (cookie)
• Site contains a reference to your
webmail app, with the command to
change your password or send an email
» CSRF attack

 Attacks against you (phishing)

 Client-Side Scripting

 Most browser attacks use some form

of client-side scripting
• Compromised browser can mean
compromised computer
• Not required for CSRF attacks
 Great idea, execute foreign code from
people I don't know or trust
• Functionality over security
» Forced choice – enable it or go away
 Client-Side Scripting

 Java has a strong security model

• But slow and cumbersome so unpopular
 JavaScript is ubiquitous and powerful
 Flash can execute JavaScript
 Windows also has Active X, VBScript
 Client-Side Mitigation

 Internet Explorer Zones

 FireFox NoScript extension
 Phishing web site lists
• Black list idea, likely to fail
 Server side
• Strong input validation
• Do not require client-side scripting
 Server-Side Controls

 XSS
• Strong input validation
» White list approach: define what's
allowed and reject everything else

 CSRF
• Every form should contain a secret value
set for each user at every session
» Receiving script should check that this
secret is present
 Session Fixation

 Malory lays out a trap in the form of a URL or HTTP

redirect

 The trap specifies a session ID; Alice clicks on it

 The web server accepts the session ID as valid

 Alice authenticates (gives user name and password)

 Session status is now "authenticated" and linked to Alice's

user name

 Malory can now send commands as Alice because he

knows the sessionID
 Analysis

 Why does the attack work?

• Is it because the client chose the session-ID?
» – No: an attacker can first get a valid session-
ID from the real server, and keep it alive as
long as necessary (until an attack succeeds)
• The server has no proof that Alice received the
original session ID directly, and not through
Malory
» This shared knowledge is the pitfall
» Resembles a partial Man-In-The-Middle attack
 Fix: Authentication Nonce

 Remove the possibility of decoupling

the identification and authentication
• Assign a proof of authentication nonce
to Alice's browser only and directly in
response to a successful authentication
request
» Request valid nonce for every request
afterwards
 Other Sources

 GIAC white papers for the CISSP CBK

• http://www.giac.org/resources/whitepape
 “All-in-one CISSP certification” (Harris
S.)
 Rob Slade's list of reference books at
http://victoria.tc.ca/int-
grps/books/techrev/mnbksccd.htm
 Other Sources

 Wikipedia
 CISSP prep guide (Krutz and Vines)
 My secure programming materials
(CS390S)
• www.cs.purdue.edu/homes/cs390s
 Matt Bishop's “Computer Security: Art
and Science”