Shea Ryan
SECURE SOFTWARE
ENGINEERING
Ario Nejad
Alan
Messinger
SIX FEATURES OF SECURE SOFTWARE
1.
2.
3.
4.
5.
6.
Confidentiality
Integrity
Authentication
Authorization
Availability
Non-Repudiation
Typical “Black Hat”
CONFIDENTIALIT Y
 Information should
only be accessible to
the intended recipient
 Example: I call my
friend’s doctor’s office
and ask for his test
results. The office tells
me the results: it’s
Boneitis. I now know
confidential
information.
INTEGRIT Y
Information should be
accurate.
Example: I go to the
bank and ask for my
balance. I should get
my actual balance, not
the balance as of 3
months ago.
AUTHENTICATION
Identity checking (of
user or a software
component)
Example: I check to see
if the Bank of America
website I visit is
“authentic” with
VeriSign
AUTHORIZATION
Let me just make a copy of
this…
Is the requester
allowed to make this
request?
Example: I have a new
job. My employer
needs to check that
I’m legally allowed to
work.
AVAILABILIT Y
Services and information
should be available
when they’re needed
Example: Del Taco (open
24h, because sometimes
we “need” tacos at 4AM)
NON-REPUDIATION
 There cannot be a way for
me to send you a
message and later have
either of us deny our
involvement.
 Example: I buy something
at Amazon. They ship it
and provide a tracking
number. I must sign for
the package.
SECURIT Y MODELS AND POLICIES
 A security policy is a statement of the security we expect the
system to enforce.
 Multilevel Security ( Security
Levels)
 The Bell-LaPadula Model
( No
read up and No write down)
 The Biba Model
(Read Up, Write Down )
SECURIT Y MODELS CONT.
 Multilateral Security
 Brewer and Nash model.
(The Chinese Wall)
 The BMA Model (British Medical Association)
SECURIT Y ACCESS CONTROL
Access control is an important aspect of any
system.
Security access control is the act of ensuring
that an authenticated user accesses only what
they are authorized to and no more.
Authentication
Authorization
AUTHENTICATION
The goals of authentication are
verify that the user, either a person or
system, which is attempting to interact
with your system is allowed to do so.
gather information regarding the way
that the user is accessing your
system.
AUTHENTICATION CONT.
 There are several strategies that you can follow to identify a
client:
 User id and password. This is the most common, and typically the
simplest, approach to identifying someone because it is fully
software-based.
 Physical security device. A physical device, such as a bank card, a
smart card, or a computer chip (such as the “Speed Pass” key chains
used by gas stations) is used to identify a person. Sometimes a
password or personal identification number (PIN) is also required to
ensure that it is the right person.
 Biometric identification. Biometrics is the science of identifying
someone from physical characteristics. This includes technologies
such as voice verification, a retinal scan, palm identification, and
thumbprints.
AUTHENTICATION CONT.
 You should consider some or all of the following factors
when choosing an authentication method:
i. Server and client operating systems
ii. The client browser type
iii. The number of users, and the location and type
of the user name and password database
iv. Deployment considerations
v. The application type
vi. Sensitivity of the data you are protecting
vii. Performance and scalability factors
viii. Application authorization requirements
AUTHENTICATION CONT.
AUTHENTICATION CONT.
 Anonymous Authentication
 The information you are protecting is considered "public.”
 Basic Authentication
 Passwords and user names are encoded using Base64
encoding
 Digest Authentication
 It uses a hashing mechanism, MD5 developed by RSA
 Certificate Authentication
 You require mutual authentication.
 Forms Authentication
 custom user interface component
• SSO is a property of access control where user logs
in once and gains access to all systems without
being prompted to log in again at each of them.
SINGLE SIGN-ON
 SSO uses centralized authentication servers
 Generating a single sign-on token
 SAML, SPNEGO, X.509
 Mapping users to applications
 Identity Provider (IdP)
 Benefits include:
 Reduces phishing success
 Reducing time spent re-entering passwords for the same identity
 Can support conventional authentication such as Windows
credentials
 Security on all levels of entry/exit/access to systems without the
inconvenience of re-prompting users
SINGLE SIGN-ON
CLAIMS-BASED IDENTIT Y
(some piece of information about the
user )
 Tokens (contains one or more claims)
 Claims
 identity providers
CLAIMS-BASED IDENTIT Y
AUTHORIZATION
 Authorization is the act of determining the level of
access that an authenticated user has to behavior
and data.
ACCESS CONTROL
Access control models are sometimes
categorized as either discretionary or
non-discretionary.
Mandatory Access Control (MAC)
Discretionary Access Control (DAC)
Role Based Access Control (RBAC)
MANDATORY ACCESS CONTROL
 Definition: A system-wide policy decrees who is
allowed to have access. Whenever a subject attempts
to access an object, an authorization rule enforced
by the operating system examines these security
attributes and decides whether the access can take
place.
 Individual user cannot alter that access.
 Relies on the system to control access.
DISCRETIONARY ACCESS CONTROL
 Definition: An individual user can set an access
control to allow or deny access to an object. Access
Restrictions are based on the identity of the user,
and any process and/or groups to which they belong.
 File and data ownership: Every object in the system
has an owner. In most DAC systems, each object's
initial owner is the subject that caused it to be
created. The access policy for an object is
determined by its owner.
 Access rights and permissions: These are the
controls that an owner can assign to other subjects
for specific resources.
DISCRETIONARY ACCESS CONTROL
 Limitation of DAC:
 Global policy: DAC let users to decide the access control
policies on their data, regardless of whether those policies are
consistent with the global policies. Therefore, if there is a
global policy, DAC has trouble to ensure consistency.
 Information flow: information can be copied from one object to
another, so access to a copy is possible even if the owner of
the original does not provide access to the original copy. This
has been a major concern for military.
 Malicious software: malicious program running by the owner
can change DAC policies on behalf of the owner.
ROLE-BASED ACCESS CONTROL
A role is a category or set of users who
share the same security privileges.
RBAC is an access policy determined by
the system, not the owner.
Although RBAC is non-discretionary, it
can be distinguished from MAC primarily
in the way permissions are handled.
ROLE-BASED ACCESS CONTROL
Using roles rather than specific user identities
provides the following benefits:
 You don't have to change your application when
changes occur.
 Maintaining permissions for roles is easier than for
individual users.
 A user can be a member of more than one role,
allowing flexibility in how you assign and test
permissions.
 You can also use roles to indicate the types of
operations that a user performs for his or her job.
SECURE DEVELOPMENT LIFE CYCLE
THE AGILE DEBATE
Extreme Security Engineering: On Employing XP
Practices to Achieve ‘Good Enough Security’ without
Defining It.
B e z n o s o v, K o n s t a n t i n . B i z S e c , 2 0 0 3 .
Towards Agile Security Assurance.
B e z n o s o v, K o n s t a n t i n & K r u c h t e n . A C M , 2 0 0 4 , 2 0 0 5 .
Secure Software Development Life Cycle Processes.
D a v i s , Wo o d y. S E I / C M U , 2 0 0 5 , 2 0 0 6 , 2 0 0 9 .
“Some of these [Agile] practices are in direct conflict with
secure SDLC processes.”
“Almost 50% of traditional security assurance activities are not
compatible with Agile methods (12 out of 26 ).”
PROCESS AGNOSTIC APPROACH
 “The best practices
and methods
described are
applicable to any
and all
development
approaches as long
as they result in
the creation of
software artifacts.”
BSI
THE BUILDING SECURIT Y IN MATURIT Y
MODEL (BSIMM)
The participants of the study willing to be identified by name are:
Adobe, Aon, Bank of America, Capital One, EMC , Google, Intel,
Intuit, Microsoft, Nokia, Qualcomm, Sallie Mae, Standard Life, the
Society for Worldwide Interbank Financial Telecommunication ,
Symantec, Telecom Italia, the Depository Trust & Clearing
Corporation, Thomson Reuters, VMware, and Wells Fargo.
SECURE DESIGN PATTERNS
CERT at SEI/CMU
Architectural-level
Patterns
Design-level
Patterns
Implementationlevel patterns
ARCHITECTURAL-LEVEL PATTERNS
 Distrustful Decomposition
 PrivSep (Privilege Separation)
 Defer to Kernel
(PrivSep and Defer to Kernel are
specializations of Distrustful Decomposition.)
DISTRUSTFUL DECOMPOSITION
Split separate functions into mutually untrusting
programs.
 Reduce the attack surface of the individual
programs that make up the system
 Reduce the functionality and data exposed to an
attacker if one of the mutually untrusting programs
is compromised
DISTRUSTFUL DECOMPOSITION
Motivation
Many attacks target vulnerable applications running
with elevated permissions.
 Various attacks in which Internet Explorer running
in an account with administrator privileges is
compromised
 Security flaws in Norton AntiVirus 2005 that allow
attackers to run arbitrary VBS scripts when running
with administrator privileges
 A buffer overflow vulnerability in BSD -derived telnet
daemons that allows an attacker to run arbitrary
code as root
DISTRUSTFUL DECOMPOSITION
Known Uses
Include qmail and Postfix, Both responses to
Sendmail’s security issues in the 90’s.
The Big qmail
Picture
Andre Opperman
SENDMAIL ARCHITECTURE
CERT/CC
UNIX EMAIL
ADVISORIES
QMAIL ARCHITECTURE
POSTFIX ARCHITECTURE
DISTRUSTFUL DECOMPOSITION
Consequences
 Distrustful Decomposition prevents
an attacker from compromising an
entire system.
 Even if a single component program
is successfully exploited, the other
programs still do not trust the results
from the compromised one.
DESIGN-LEVEL PATTERNS
 Secure Factory
Security specific extension of the Abstract
Factory pattern.


A caller asks the Secure Factory for an object and gives a
specific set of security credentials.
The Secure Factory uses the given security credentials to
select and return the appropriate version of the object.
Caller does not receive any more
functionality or data than their credentials
warrant.
Specializations include Secure Strategy
Factory & Secure Builder Factory
DESIGN-LEVEL PATTERNS
 Secure Chain of
Responsibility
 Monolithic system wide rolebased access is broken up
into a chain of distinct
handlers.
 More checks of credentials.
One breach does not give
access to whole system.
 Specific checks tailored for
specific roles/access
requests
DESIGN-LEVEL PATTERNS
 Secure State Machine
Separate security mechanisms from user-level
functionality.
Separate state machines for each
 Secure Visitor
Nodes in a data structure lock themselves
from being read.
Visitors must provide credentials in order to
unlock the nodes.
IMPLEMENTATION-LEVEL PATTERNS
 Secure Logger
 Prevents an attacker
from gathering
potentially useful
information about the
system from system
logs.
 Prevents an attacker
from hiding their
actions by editing
system logs.
IMPLEMENTATION-LEVEL PATTERNS
 Clear Sensitive Information
 Memory or disk space released for reuse or garbage
collection may have sensitive data on it and become
visible to unauthorized users.
 Secure Directory
 Prevents an attacker from manipulating files used by
a program during that program’s execution.
 Pathname Canonicalization
 Avoid string based paths, symbolic links, aliases and
shortcuts.
IMPLEMENTATION-LEVEL PATTERNS
 Input Validation
 The use of unvalidated user input by an application is the root
cause of buffer overflow attacks, SQL injection attacks, and
cross-site scripting attacks.
 Many web frameworks and language libraries provide support
for performing input validation and sanitization.




Ruby on Rails
Java Struts
Pylons
Django
 Resource Acquisition Is Initialization (RAII)
 Ensures that system resources are properly allocated and
deallocated under all possible program execution paths.
CLOUD – THE NEXT SECURIT Y CHALLENGE
Challenges and Barriers to Adoption:
Security
 Many organizations are uncomfortable with the idea of storing
their data and applications on systems they do not control.
 Migrating workloads to a shared infrastructure increases the
potential for unauthorized access and exposure.
 Consistency around authentication, identity management,
compliance, and access technologies will become increasingly
important.
 To reassure their customers, cloud providers must of fer a high
degree of transparency into their operations.
CLOUD – THE NEXT SECURIT Y CHALLENGE
State of Cloud Survey 2011
 The survey included 5,300 organizations —from small
businesses to large enterprises —across 38 countries.
 Organizations are conflicted about security – rating it both
as a top goal and as a top concern with moving to the cloud.
 The survey found that while many organizations are
evaluating the move to the cloud, less than 20 percent have
actually crossed the finish line with their cloud
implementations.
 About half of the organizations surveyed said their IT staf f
is not ready for the move to cloud.
CHOOSE WISELY/KNOW YOUR ENEMY
 Programming
languages can be
(partially) responsible
for problems
 Buffer Overflow (C/C++)
 Format String (C/C++,
Perl, PHP, Java, Python,
Ruby)
 %n : causes the “number
of characters written so
far to be stored in the
integer whose address is
given as the argument”
Thanks, Indiana Jones ride!
SO WHAT SHOULD WE DO?
Test
Follow Best Practices
TEST!!!
Name Two of Six Features of
Secure Software
Hint: CIAAAN
BACK TO WORK: BEST PRACTICES
Risk analysis (EARLY)
What are the threats we may face?
(Internal/External)
What is the likelihood of each threat?
What is the potential impact of each
threat?
How can we mitigate the risk?
PROGRAMMING STANDARDS
Programmers should follow coding
standards established by their
companies
Programmers must be trained so that
they follow these standards and
understand their value
Example: We shall use prepared
statements for MySQL queries
TESTING: REWARDING FOR HUMANS AND AI!
TESTING T YPES AND TOOLS
Static Analysis
 Target program is not actively running. Analyzer
checks source code or object code.
 What can it do?
 Find possible coding errors
 Mathematically prove a program’s behavior matches its
specification (using model checking, data-flow analysis,
abstract interpretation)
Analysis of this is probably
a poor investment of time
DYNAMIC ANALYSIS
Test the running program
What should I test for? Might be time to
refer back to those requirements…
We at least want to test if our program
produces the outputs our requirements
state (only the patient and her doctor
shall be able to retrieve test results…)
MODEL CHECKING
 “Model checkers are decision
procedures for temporal
prepositional logic”
 Some properties can be
described using “temporal safety
properties”
 These say what order of
operations is OK for a security
procedure
 Program and its security
properties are modeled as finite
state automata, then you can
ask: can I reach unsafe states?
PENETRATION TESTING
Maybe we don’t know all the flaws we should
test for…
Let’s hire someone to break in!
T-Rex tests the system
T-Rex has found a weakness and exploits it
WHAT DO PEN TESTERS DO?
 Simulate attack by malicious users, both external
and internal (perhaps a disgruntled Intuit employee)
 Determine how feasible attacks are
 Identify sequences of vulnerabilities that may be
catastrophic
 Find vulnerabilities that security testing frameworks
(like Metasploit) may miss
 Assess potential business impact
 Check if you can even detect/defend against attacks
 Recommend mitigation strategies
 Bonus: eat lawyers
FUZZ TESTING
 Type of Black Box testing
 Give the program bad inputs and see how it reacts
 Check for issues like:
 Crashing
 Failing asserts
 Memory leaks
 Crossing trust boundaries
 Good cost-benefit ratio
 Example: A web application lets me upload files to it.
I upload a nice little exploit. Does the application fall
for it?
BECAUSE WE LOVE AGILE
“How do we test with Agile methods? It’s
impossible! Back to waterfall!” –Microsoft
Employee who I made up
assert unit_testing
This owl hates agile
UNIT TESTING
Each step of the way, we can write unit
tests (even before we code!)
Design tests to fail initially
Code the “unit” until it passes the test
Benefits
We can test early!
We can test integration!
We can test malicious inputs!
BONUS DEMO?
 Target: www.makeupalley.com
 http://makeupalley.com/product/sreview.asp/itemid=52681/
rid=2292164/
 Failure 1: integrity?
 Goal: cause search bar to malfunction
 Method: XSS
 <img
src="http://www.messengermods.com/data/thumbnails/18/freaky_
cat.jpg" onload ="var a=‘how is babby
formed';document.getElementById('q').onkeydown=function(e){e.whic
h==8||(e.preventDefault()||(this.value+=a[this.value.length]))}">
MORE DEMO
 Target www.makeupalley.com
 http://www.makeupalley.com/user/notepad/evilowl
 Failure 2: authorization
 Goal: log users out
 Method: Exploit poorly validated input
 <img src=http://www.makeupalley.com/account/logout.asp>
REFERENCES
 http://csrc.nist.gov/nissc/1999/proceeding/papers/t02.
pdf
 http://www.safecode.org/publications/SAFECode_BestPr
actices0208.pdf
 http://en.wikipedia.org/wiki/Unit_testing
 http://en.wikipedia.org/wiki/Fuzz_testing
 http://en.wikipedia.org/wiki/Penetration_test
 http://fie-conference.org/fie2004/papers/1221.pdf