Designing your applications with a security twist 2007

Designing Your A li i
D i i Y Applications
with a Security Twist
y
David S. Read, Chief Technologist
, g

© 2007 Property Casualty Insurers Association of America

Contents
o e s

Application Security Landscape
Security Standards and Best Practices
Embedding Security in the SDLC
Deep Di i t K E l it
D Dive into Key Exploits


We have entered a third phase
in the
i th world of IT security
ld f it
Phase 1 Phase 2 Phase 3

Software
Application

Internet

Operating
System
S


Addressing application
security is now essential
Server Application
pp

Non-Server Application

3% 2% 2% 1% 0%
Operating System
15% 41%
Hardware

Communication Protocol

Other
36% Network Protocol Stack
Network security issues have Encryption Module
attracted most attention
The application layer has been
left exposed and vulnerable

Data shows that application
security is a widespread i
it i id d issue
75% of attacks against Web servers are entering through
applications and not at the network level. When a company
makes even subtle changes on its Web sites and applications,
new vulnerabilities can arise – Gartner’s John Pescatore
Four years of penetration testing on more than 250 web
applications including e-commerce, online banking, enterprise
collaboration, and supply chain management sites showed that
at least 92% of web applications are vulnerable to some form of
hacker attacks - WebCohort's Application Defense Center
In as study to determine the frequency in which a worm or virus
was spread via email versus the Web, It was found that the Web
was responsible for 30% of infections and only 20-25% were
caused by malicious emails – IDC Denmark


Typical software flaws
yp

Trust of Client State
Trust of Client Input
Incomplete Instrumentation (Logging)
Exploitable Designs
Unencrypted Communications
Weak Config Mgmt (e g Long-lived Accounts)
(e.g. Long lived
Backdoors
Lack of Testing (Bugs Buffer Overflows, Race
Conditions, etc.)
Conditions etc )


Know the root causes by de-
webbing th OWASP Top 10
bbi the T
OWASP Vulnerability Type of Flaw

Unvalidated Input Trust of Client Input

Broken Access Control Exploitable Designs, Incomplete Instrumentation, Lack of Testing, Backdoors

Broken Auth and Session
Exploitable Designs, Unencrypted Communications, Trust of Client State, Backdoors
Mgmt
Cross Site Scripting (XSS)
Trust of Client Input
Flaws

Buffer Overflows Lack of Testing, Trust of Client Input
g p

Injection Flaws Lack of Testing, Trust of Client Input

Improper Error Handling Exploitable Designs, Incomplete Instrumentation, Lack of Testing

Insecure Storage Unencrypted Communications, Exploitable Designs, Lack of Testing, Backdoors

Denial of Service Exploitable Designs

Insecure Conf Mgmt
g Weak Configuration Mgmt, Incomplete Instrumentation, Lack of Testing, Backdoors

Source: http://www.owasp.org/documentation/topten.html


Contents
o e s

Application Security Landscape
Security Standards and Best Practices
Embedding Security in the SDLC
Deep Dive into Key Exploits


Why talk about security
standards?
Security failure may result in:
– Unauthorized disclosure
– Intentional or accidental loss, destruction, or modification of key
information
– T
Temporary or extended lack of system availability
t d dl k f t il bilit
– Costs related with penalties, fines and repairs
The goals of security are Prevention, Detection and Recovery
– Prevent the breach of a security policy
– Enable the detection of activities that are in violation of security
policy
– Stop the security violation, identify the attacker, and provide
corrective action to assess damage and perform repairs
The foundation of having auditable and secure systems are
effective security standards and policies
– The standards must cover the entire application lifecycle
– Th policies must b conspicuous and consistently enforced
The li i t be i d i t tl f d


Typical standards for
application security
Integrated Security Infrastructure
Audit Trails
Universal Participation
Segregation of Duties
S f
Failsafe Stance (failure of security infrastructure,
application access denied)
Weakest Link (fix all weaknesses)
Least Privilege
Limit design/implementation knowledge for vendors
(need to know basis-compartmentalization)


Use standards as the basis for
controls to mitigate flaws
Should have security standards that define how
security-related issues are to be documented and
handled across the SDLC
Should be based on current best practices, adjusted
practices
for specific data sensitivity issues
Must be reviewed frequently to ensure that standards
are being consistently enforced and met
Audit trails must be monitored, manually or via
scripts, so that abuse warning signs are spotted
quickly
Strong Passwords!


From standards, principles for
best practices emerge…
emerge
Security in Depth
Segregation of Duties
Identify Weakest Links
Least Privilege
Audit Trails
Appropriate Communications
Effective Configuration Management
Paranoid Design


Some key best practices for
Application Control Checklist
Multi-level Security
Design and Code Reviews
Third-party Audits
Extended Testing
Users – The Ultimate Firewall


Application Control Checklist
pp

Project Management and Control
Standards
Application Systems Development
Application Program Development
Operating System Maintenance
Program Maintenance
Testing
Documentation
Implementation
I l t ti
Vendor Software/Support
Source: http://www.auditnet.org/docs/ITGeneralControlsAudit.pdf


Multi-level Security
y
AKA Security In Depth
Don’t rely on a single point of enforcement
– If a cracker gets past one level, hopefully the next will stop
him/her
Still need firewalls, IPSs, VPNs, DMZs, etc.
– Just don’t rely on them to protect poorly designed or
implemented software
p
Some exploits have nothing to do with software you
control-how do you control these?
– Social Engineering
g g
– WiPhishing
– Physical Security


Design and Code Reviews
g
Look for potential weaknesses in design and
implementation
Ensure company security standards are applied
Use design patterns
Use best practice security implementations
– Don’t create your own in each application
Simplify
Si lif
AOP can help with cross-cutting concerns such as
logging and authorization
– AOP modifies your source! Know your vendor!


Third-party audits
p y
Fresh point, alternative to “group think”
point group think
Security experts have seen many situations and can
generalize them to make your solutions more secure
– Smaller shops can save cost by renting a security expert
Audits are useful throughout the SDLC
– Functional specifications
– Design documents
– Code reviews
– Testing reviews
– Audit trail reviews


Extended Testing
g
Focus is typically on UAT
– This assures the app does what the users need, it doesn’t help identify
whether the system will do things it shouldn’t
Unit Testing
– Helps identify flaws quickly with minimal time spent
– Gives developers a quick way to prove code is working
– Exposes overly complex code, difficult to test with many dependencies
– Should test all paths, particularly error handling code
Security Testing
– Based on the belief that the software is vulnerable, utilizes tests to exploit
those vulnerabilities
– Once each vulnerability is found, it’s root cause must be identified and fixed
– Standards should be updated to reflect any new knowledge the vulnerability
presented
Random Testing
– Focused on causing an unexpected or unhandled error
– Critical, yet not expected
,y p


Users – The Ultimate Firewall
Users are the first and last line of defense of
our data
Training and consistent messaging are vital
g g g
to keep users aware of their role in following
the corporate policies and practices designed
to protect the business’ IT assets
business
Look for opportunities to help users protect
system data
y
Establish and maintain a culture of security


Use best practices to inform
and i
d improve standards
t d d
Think about security from the start … avoid costly
y y
repairs due to inadequate planning and design
Identify security risks early and use FMEA to
p
prioritize and categorize the various levels of risk
g
Stay on top of statutory requirements and company
policy on security
Involve key constituents throughout the project life
cycle to ensure all business requirements are
captured
Implement IT support for p
p pp post-production monitoring
p g
and support


Functional objectives drive
security th
it throughout the SDLC
h t th
Build / Deploy /
Define
D fi Analyze
A l Design
D i
Test Support

Application development life cycle
segregated into distinct phases
Security must be planned for and executed
within every phase from inception
Better to invest in security in the
y
development life cycle rather than pay
heavily for security breaches in production


Security (too) should start in
the D fi
th Define stage
t Define

Functional Objectives Security Considerations

Identify project scope Understand company
and success criteria policy regarding
Establish core team requirements
Produce a project Agree on security
charter definitions and goals
Classify security levels
Select appropriate PM
methodology


Security standards must be
established early
t bli h d l Define

Company policies to:
– Ensure confidentiality, integrity, and availability of apps and info
(Security in Depth, Segregation of Duties, Unencrypted Communications)
– Ensure the proper and authorized use of such applications and
information (Security in Depth, Segregation of Duties, Least Privilege)
– Provide for emergency recovery and restoration in case of attack or
failure (Security in Depth, Audit Trails, Exploitable Design)
Project management methodologies to:
– Ensure proper resources are assigned and roles/responsibilities are
clearly understood
– Require process and deliverable documentation throughout each
phase
– Require rigorous review and approval by team and business
stakeholders
t k h ld


Security threats are specified in
the A l
th Analyze stage
t Analyze


Benchmark existing Identify potential threats to
business process (As Is) the application
and build high level future Application
A li ti security risk
it i k
process (To Be) categorization
Perform gap analysis Evaluate the risks and
Document business develop a
requirements protection/security plan
Identify risks inherent in the Identify training for key
p
process and establish risk constituents
mitigation plan Use method for harvesting
security requirements


Standards during the Analyze
stage
t Analyze

Identify training for key constituents
– Security Analysts, Designers, Developers, QA,
End Users and the Application Maintenance team
pp
(all security risk categories)
Use a standard methodology for gathering
and defining security requirements
– Find-Gather-Validate-Translate


Design stage should present a unified
security architecture and identify all
y y
possible attacks Design


Conversion of functional Integration of security into
requirements into technical functionality during design
specifications is easier and cheaper
Design system with
Rollback to gap analysis to potential security violation
ensure all requirements are in mind (refer to FMEA)
addressed Perform security design
Obtain key constituent reviews to assure that
signoff before proceeding security requirements are
to development attained


Standards are established and
used in the Design stage Design

Formal design reviews and stakeholder signoffs to
ensure security has been addressed in Design
(Covers all security risk categories)
Apply technical safeguards in the design
documentation
– User authentication routines and system access
procedures (Segregation of D ties Least Pri ilege Weak
Duties, Privilege,
Configuration Management)
– Information encryption (Unencrypted Communications)
– Logging features to facilitate troubleshooting and
ensure auditing capabilities (Audit Trails)
Eliminate or mitigate any design flaws p
g y g prior to
development (Weakest Link)

During the Build / Test stage, the
security focus must be on the code Build /
Test

Conversion of technical At code level, focus on
specifications into blocks of code implementation flaws*
forming the desired system / app Perform code review
Establish user access and allocate – Finding and removing all
g g
system / app responsibilities implementation fl
i l t ti flaws i in
source code does nothing to
Develop use case scenarios to address architectural
test the app’s functionality problems*
Perform tests and capture results Build security test plans*
Obtain user and key business – T ti standard and security
Testing t d d d it
constituent signoff for production functionality
release – Risk-based testing based on
attack patterns and threat
models
Consider cost-benefit when
cost benefit
designing / building security into
your applications

Source: From the Ground Up: The DIMACS Software Security Workshop, IEEE Computer Society, 2003


Security standards to establish and
use in the Build / Test stage
se B ild Build /
Test

Formal code reviews to obtain signoff and ensure
that there are no apparent flaws in the application
(look for threats in all security risk categories)
When using outside vendors for development, limit
the amount of details given on a need-to-know basis
(Exploitable Design, Security in Depth)
Use formal testing and use case scenarios to test the
application
– Unit Testing, Security Testing, User Acceptance
Testing, and Random Testing (covers all security
risk categories)


During the Deploy / Support stage,
security policies must be enforced Deploy /
Support


Complete and publish all Registration approval and
process and application login authorization in
documentation place
Conduct role-specific Enforce and maintain
training plan for all security policy
application users Continuously monitor
y
Develop an ongoing plan application against threats
to ensure process and or attacks
application control
Implement application
support for ongoing
maintenance


Standards are established and used in
the Deploy / Support stage Deploy /
Support

Perform necessary training for new
application
Policy on continuous monitoring of application
log files to identify misuse, potential threats,
and/or attacks (Audit Trails)
( )
Recovery and restoration policy in case of
failure or fatal attacks (Security in Depth)


Results of attacks can be
extremely harmful
t l h f l
Stolen, lost,
Stolen lost or improperly altered data
Loss of system availability or Denial of
Service
S i
Can cost the company dearly, in terms
of worker productivity and
unrecoverable customer goodwill
May lead to lawsuits and lost revenue


Types of Hackers and
Common E l it
C Exploits
Types of hackers:
– Black Hats
– Whit H t
White Hats
– Grey Hats
Common types of exploit:
– Directory Traversal
– Cross-site Scripting (XSS)
– SQL Injection


Directory Traversal
ec o y es
Definition
–C
Convinces th server t provide th client with a li ti of di t
i the to id the li t ith listing f directory
contents
–Rather than accessing a specific file
Risks
–Allowing users to access functionality that their role would not normally
allow
–Allowing theft of configuration details and providing a complete list of
application resources
Root Cause
–Directory traversal vulnerabilities are typically due to flaws in
- Server Configuration and Server Software
–Developers have some ability to help mitigate the risk
- Provide a standard default page in every directory of the web
application (e.g. index.html, index.jsp, index.do)
- Provide appropriate, if redundant, server-specific configuration
information such as .htaccess files for an Apache server
htaccess


Type 1 XSS
ype
Definition
–Involves a vulnerable application and tricking a user to enter some
exploit code
–A vulnerable application is one that echoes the input back to the front-
end, unsanitized
–The exploit code can be hidden in places like an IM or email link
Risks
–The risks include theft of user credentials, data, email addresses and
cookies.
–Th risks can cause a user t misunderstand what server i actually
The i k to i d t d h t is t ll
controlling their UI experience, tricking him or her into divulging personal
information. Further the hosting application that allows the exploit
becomes a participant in the attack.
Root Cause
–Type 1 XSS vulnerabilities are typically produced by developers.
–The normal use case involves:
- Accepting input from a user that is then used as part of the
content on a later screen.
t t l t


Type 2 XSS
ype
Definition
–Involves an application that stores unsanitized input in a repository
where it will later be sent to a user
–Email systems, blogs, news feedback sites and applications that store
“comments” or user entered text for later retrieval are likely candidates
Risks
–The risks include all the risks of a type 1 XSS, without the need to trick
the user into passing the exploit code to the server.
–The risks are passed onto many users (large number depending on the
popularity of the site) since the exploit code once uploaded by an
code,
attacker, is essentially embedded in the application.
Root Cause
–Type 2 XSS vulnerabilities are typically produced by developers.
–Th normal use case i
The l involves accepting i
l ti input f
t from a user th t i th
that is then
stored intact in the application’s database.
–As with Type 1 XSS, by creating targeted input the attacker can cause
the client application to send credentials destined for the application to a
separate server and application.
application


SQL Injection
Q jec o
Definition
–Involves passing input from an application tier to the database
–Such that the input is treated as part of the SQL statement, not just as a
parameter
Risks
–The risks include allowing users to access any data that their database
connection allows leading the theft, alteration and loss of data.
–Each of these risks can cause our application to provide misinformation
or fail altogether.
Root Cause
R tC
–SQL Injection vulnerabilities are typically produced by developers.
–The normal use case involves accepting input from a user that is to be
used as part of a SQL statement, often the where clause.
–Through careful manipulation of the input parameters the attacker learns
what the template SQL statement looks like, what DBMS product is
being used, what schemas, tables and columns can be accessed.
Finally the attacker is able to extract the data from the backend.


SQL Injection Attack and
Mitigation Live Demo
Miti ti – Li D


Designing your applications with a security twist 2007

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Designing your applications with a security twist 2007

Similar to Designing your applications with a security twist 2007 (20)

Recently uploaded

Recently uploaded (20)

Designing your applications with a security twist 2007