Transcript A Paranoid Programmer is a Good Programmer Paranoid Programming Practices 26 January 2009 “It’s not a matter of whether you’re paranoid or not. It’s.

A Paranoid Programmer is a Good Programmer
Paranoid Programming Practices
26 January 2009
“It’s not a matter of whether you’re paranoid or not.
It’s a matter of whether you’re paranoid enough.”
-
Unknown.
26 January 2009
(He wouldn’t give me his name…)
I’m not paranoid – everybody IS after me!
1
A Paranoid Programmer is a Good Programmer
A Mostly PCI/OWASP Agenda
1. Overview of Policy Frameworks related
to an organization’s efforts towards PCI and
formalizing secure programming practices.
2. Details of Secure Programming Practices.
3. Review of Vulnerabilities along OWASP Classifications
A note on scope:
Secure programming practices are in scope.
In-depth discussions of the PCI DSS are not.
26 January 2009
I’m not paranoid – everybody IS after me!
2
A Paranoid Programmer is a Good Programmer
Basic Premises
• Everyone is out to get us
I think we all know by this point in time that:
CyberCrime pays...
It has become a well organized, financed, and executed business.
• Hardware isn’t the answer
Direct quote from OWASP.org:
“Unlike other forms of security (such as firewalls
and secure lockdowns), web applications have the
ability to make a skilled attacker rich, or make
the life of a victim a complete misery. At this
highest level of the OSI software map, traditional
firewalls, and other controls simply do not help.
The application itself must be self-defending.”
26 January 2009
I’m not paranoid – everybody IS after me!
3
A Paranoid Programmer is a Good Programmer
Secure Programming and PCI
• Policy Frameworks in general
–
–
–
–
Organizational management champions security
A written security policy derived from accepted standards
A development methodology with adequate security checkpoints
Secure release and configuration management processes
• PCI DSS
The Payment Card Industry (PCI) has created their Data Security
Standard (DSS) to formalize their “Policy Framework”.
Certification ranges from self evaluation to inspection/evaluation by
an approved 3rd party auditor.
https://www.pcisecuritystandards.org/
• 3 Structured Pieces of general policy frameworks
– Development Methodology
– Coding Standards
– Source Control
26 January 2009
I’m not paranoid – everybody IS after me!
4
A Paranoid Programmer is a Good Programmer
The 3 Pieces – Methodology
• Development Methodology
The methodology used isn’t as important as just
adhering to one that is structured and has the following
characteristics:
– Strong acceptance of design, testing, and documentation
processes
– Clear instances where security controls (such as threat risk
analysis, peer reviews, code reviews, etc) are used
– Works well for the organization’s size and maturity
– Has the potential to reduce the current error rate and improve
developer productivity
– Will scale as the organization or product line grows
26 January 2009
I’m not paranoid – everybody IS after me!
5
A Paranoid Programmer is a Good Programmer
The 3 Pieces - Standards
• Coding Standards
You’ll notice that none of the following say anything
about indentation and tab styles…
–
–
–
–
–
–
–
–
Architectural guidance
Minimum documentation levels required
Mandatory testing and coverage requirements
Minimum levels of code commenting and the preferred comment style
Proper use of exception handling
Correct use of flow of control blocks
Preferred variable, function, class, and table naming styles
A preference for maintainable and readable code over clever or complex
code
– Common sanitizing and error handling functions
26 January 2009
I’m not paranoid – everybody IS after me!
6
A Paranoid Programmer is a Good Programmer
The 3 Pieces - Control
• Source Control
Formal source control systems increase efficiency over
ad-hoc copy-and-save procedures. The orders of efficiency increase
when source control systems are used for versioning code-lines,
tests, and documentation together .
General topics to consider with the use of a formal source control
system include:
–
–
–
–
–
Labels, Checkpoints, Pins, and Rollbacks
Branching
Access Levels and Controls
Integration with automated build and versioned test harnesses/tools
Backup/Restore Procedures and Tests
26 January 2009
I’m not paranoid – everybody IS after me!
7
A Paranoid Programmer is a Good Programmer
Approaching Secure Coding
• Secure programming can be looked at from
four perspectives:
–
–
–
–
Attackers
Tenants
Architectures
Principles
• A note about Asset Classification
While most security approaches use asset classification to partition
data into low and high value systems, from a purely PCI perspective
we are concerned with whether any aspect of the system lives
anywhere near cardholder data. It’s not uncommon to find that
given a data model and physical DB architecture, all data should be
classified as part of a high value systems.
26 January 2009
I’m not paranoid – everybody IS after me!
8
A Paranoid Programmer is a Good Programmer
Know Your Attackers
• You know the old saying, “keep your friends
close and your enemies closer.” Well, besides
from all the bad guys out there, the set is more than just
willful malice:
– Disgruntled staff or developers
– “Drive by” attacks, such as side effects or direct consequences
of a virus, worm or Trojan attack
– Motivated criminal attackers, such as organized crime
– Criminal attackers without motive against your organization,
such as defacers
– Script kiddies
– Accidental information exposure
– Accidental functionality exposure
26 January 2009
I’m not paranoid – everybody IS after me!
9
A Paranoid Programmer is a Good Programmer
Tenants
• Confidentiality
Only allow access to data for which the user
is permitted
• Integrity
Ensure data is not tampered or altered by unauthorized
users
• Availability
Ensure systems and data are available to authorized
users when they need it
26 January 2009
I’m not paranoid – everybody IS after me!
10
A Paranoid Programmer is a Good Programmer
Architecture
• Basic considerations:
–
–
–
Is the process surrounding this feature as safe as possible? In other words,
is this a flawed process?
If I were evil, how would I abuse this feature?
Is the feature required to be on by default? If so, are there limits or options that could help
reduce the risk from this feature?
• Threat Risk Modeling:
–
–
Threat Modeling provides a way to focus resources on the real risks through a process of
analysis and validation of both concerns and mitigations.
Examples include: “Thinking Evil™”, DREAD/STRIDE, Microsoft’s “SDL” Threat Modeling
• Quotes from OWASP:
–
–
“The best system architecture designs and detailed design documents contain security
discussion in each and every feature, how the risks are going to be mitigated, and what was
actually done during coding.”
“Security architecture starts on the day the business requirements are modeled, and never
finish until the last copy of your application is decommissioned. Security is a life-long
process, not a one shot accident.”
26 January 2009
I’m not paranoid – everybody IS after me!
11
A Paranoid Programmer is a Good Programmer
Principles
• Security Principles are guidelines designed
to give us a framework to consider our designs
and implementations against:
–
–
–
–
–
–
–
–
–
–
Minimize attack surface area
Establish secure defaults
Principle of Least privilege
Principle of Defense in depth
Fail securely
Don't trust services
Separation of duties
Avoid security by obscurity
Keep security simple
Fix security issues correctly
26 January 2009
I’m not paranoid – everybody IS after me!
12
A Paranoid Programmer is a Good Programmer
Security Principles - I
• Minimize attack surface area
– Every feature that is added to an application adds a
certain amount of risk to the overall application. The aim for secure
development is to reduce the overall risk by reducing the attack surface
area.
• Establish secure defaults
– There are many ways to deliver an “out of the box” experience for
users. However, by default, the experience should be secure, and it
should be up to the user to reduce their security – if they are allowed.
• Principle of Least privilege
– The principle of least privilege recommends that accounts have the
least amount of privilege required to perform their business processes.
This encompasses user rights, resource permissions such as CPU limits,
memory, network, and file system permissions.
26 January 2009
I’m not paranoid – everybody IS after me!
13
A Paranoid Programmer is a Good Programmer
Security Principles - II
• Principle of Defense in depth
– The principle of defense in depth suggests that where
one control would be reasonable, more controls that
approach risks in different fashions are better. Controls, when used in
depth, can make severe vulnerabilities extraordinarily difficult to exploit
and thus unlikely to occur. With secure coding, this may take the form
of tier-based validation, centralized auditing controls, and requiring
users to be logged on all pages.
• Fail securely
– Applications regularly fail to process transactions for many reasons.
How they fail can determine if an application is secure or not.
• Don't trust services
– Many organizations utilize the processing capabilities of third party
partners, who more than likely have differing security policies and
posture than you. It is unlikely that you can influence or control any
external third party, whether they are home users or major suppliers or
partners. Therefore, implicit trust of externally run systems is not
warranted. All external systems should be treated in a similar fashion.
26 January 2009
I’m not paranoid – everybody IS after me!
14
A Paranoid Programmer is a Good Programmer
Security Principles - III
•
Separation of duties
– A key fraud control is separation of duties. For example, someone
who requests a computer cannot also sign for it, nor should they
directly receive the computer. This prevents the user from requesting many
computers, and claiming they never arrived.
•
Avoid security by obscurity
– Security through obscurity is a weak security control, and nearly always fails
when it is the only control. This is not to say that keeping secrets is a bad idea, it
simply means that the security of key systems should not be reliant upon
keeping details hidden.
•
Keep security simple
– Attack surface area and simplicity go hand in hand. Certain software engineering
fads prefer overly complex approaches to what would otherwise be relatively
straightforward and simple code.
•
Fix security issues correctly
– Once a security issue has been identified, it is important to develop a test for it,
and to understand the root cause of the issue. When design patterns are used, it
is likely that the security issue is widespread amongst all code bases, so
developing the right fix without introducing regressions is essential.
26 January 2009
I’m not paranoid – everybody IS after me!
15
A Paranoid Programmer is a Good Programmer
Threat Risk Modeling
•
Microsoft has robust and well documented
threat modeling methodologies. They include
the following steps:
1.
2.
3.
4.
5.
Identify Security Objectives
Survey the Application
Decompose it
Identify Threats
Identify Vulnerabilities
• The Microsoft SDL Threat Modeling Tool
– http://msdn.microsoft.com/en-us/security/dd206731.aspx
26 January 2009
I’m not paranoid – everybody IS after me!
16
A Paranoid Programmer is a Good Programmer
STRIDE
• Stride is an methodology for identifying
the following “known” threats:
–
–
–
–
–
–
Spoofing Identity
Tampering with Data
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
26 January 2009
I’m not paranoid – everybody IS after me!
17
A Paranoid Programmer is a Good Programmer
DREAD
• DREAD is a methodology for risk rating.
The DREAD algorithm, shown below, is used to compute a
risk value, which is an average of all five categories.
Risk =
( DAMAGE + REPRODUCIBILITY + EXPLOITABILITY +
AFFECTED USERS + DISCOVERABILITY ) / 5
– Damage Potential
If a threat exploit occurs, how much damage will be caused?
– Reproducibility
How easy is it to reproduce the threat exploit?
– Exploitability
What is needed to exploit this threat?
– Affected Users
How many users will be affected?
– Discoverability
How easy is it to discover this threat?
26 January 2009
I’m not paranoid – everybody IS after me!
18
A Paranoid Programmer is a Good Programmer
And my own favorite…
• Quantify Risk Financially
It’s not something that engineers often talk about but at a
business level it is critical to understand the cost of exploited
risks against the cost of mitigation. This allows a financial balance to be
maintained between mitigation strategies and risks.
The following quote is from the ANSI document:
The Financial Impact of Cyber Risk
“The key to understanding the financial risks of cyber security is to
fully embrace its multidisciplinary nature. Cyber risk is not just a
“technical problem” to be solved by the company’s Chief Technology Officer.
Nor is it just a “legal problem” to be handed over to the company’s Chief Legal
Counsel; a “customer relationship problem” to be solved by the company’s
communications director; a “compliance issue” for the regulatory guru; or a “crisis
management” problem. Rather, it is all of these and more.“
Complete document is available for free download here:
http://webstore.ansi.org/cybersecurity.aspx
26 January 2009
I’m not paranoid – everybody IS after me!
19
A Paranoid Programmer is a Good Programmer
Here’s the formula…
• Net financial risk can be expressed as:
26 January 2009
I’m not paranoid – everybody IS after me!
20
A Paranoid Programmer is a Good Programmer
Key OWASP Areas
•
OWASP identifies the following areas as having clear
objectives within a development methodology:
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Handling E-Commerce Payments
Phishing
Web Services
Ajax and Other "Rich" Interface Technologies
Guide to Authentication
Guide to Authorization
Session Management
Data Validation
Interpreter Injection
Canonicalization, locale and Unicode
Error Handling, Auditing and Logging
File System
Distributed Computing
Buffer Overflows
Administrative Interface
Guide to Cryptography
Configuration
Software Quality Assurance
Deployment
Maintenance
26 January 2009
I’m not paranoid – everybody IS after me!
21
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - I
• Handling E-Commerce Payments
–
–
–
–
Secure Payment Account Number handling
Minimize fraud from cardholder not present (CNP) transactions
Maximize privacy and trust for users of e-commerce systems
Comply with all local laws and PCI (merchant agreement)
standards
• Ajax and Other "Rich" Interface Technologies
–
–
–
–
–
Secure Communications
Authentication and Session Management
Access Control
Input Validation
Error Handling and Logging
26 January 2009
I’m not paranoid – everybody IS after me!
22
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - II
• Authentication
– Tying an system identity to an individual user by
the use of a credential
– Providing reasonable authentication controls as per the
application’s risk
– Denying access to attackers who use various methods to attack
the authentication system
• Authorization
– To ensure only authorized users can perform allowed actions
within their privilege level
– To control access to protected resources using decisions based
upon role or privilege level
– To prevent privilege escalation attacks, for example using
administration functions whilst only an anonymous user or even
an authenticated user
26 January 2009
I’m not paranoid – everybody IS after me!
23
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - III
• Session Management
– Authenticated users have a robust and
cryptographically secure association with their session
– Applications enforce authorization checks
– Applications avoid or prevent common web attacks, such as
replay, request forging and man-in-the-middle
• Data Validation
– To ensure that the application is robust against all forms of input
data, whether obtained from the user, infrastructure, external
entities or database systems
• Interpreter Injection
– To ensure that applications are secure from well-known
parameter manipulation attacks against common interpreters
26 January 2009
I’m not paranoid – everybody IS after me!
24
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - IIII
• Canonicalization, locale and Unicode
– To ensure the application is robust when subjected
to encoded, internationalized and Unicode input
• Error Handling, Auditing and Logging
– Auditable – all activities that affect user state or balances are
formally tracked
– Traceable – it’s possible to determine where an activity occurs in
all tiers of the application
– High integrity – logs cannot be overwritten or tampered by local
or remote users
• File System
– To ensure that access to the local file system of any of the
systems is protected from unauthorized creation, modification,
or deletion
26 January 2009
I’m not paranoid – everybody IS after me!
25
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - V
• Distributed Computing
– Time of check, time of use race conditions
– Distributed synchronization issues
– Common multi-programming, multi-threaded and distributed
security issues
• Buffer Overflows
– Applications do not expose themselves to faulty components
– Applications create as few buffer overflows as possible
– Developers are encouraged to use languages and frameworks
that are relatively immune to buffer overflows
26 January 2009
I’m not paranoid – everybody IS after me!
26
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - VI
• Administrative Interface
– Administrator level functions are appropriately
segregated from user activity
– Users cannot access or utilize administrator functionality
– Provide necessary audit and traceability of administrative
functionality
• Cryptography
– To ensure that cryptography is safely used to protect the
confidentiality and integrity of sensitive user data
• Configuration
– To produce applications which are secure out of the box
26 January 2009
I’m not paranoid – everybody IS after me!
27
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - VII
• Software Quality Assurance
– The software quality assurance goal is to confirm the
confidentiality and integrity of private user data is protected as
the data is handled, stored, and transmitted. The QA testing
should also confirm the application cannot be hacked, broken,
commandeered, overloaded, or blocked by denial of service
attacks, within acceptable risk levels. This implies that the
acceptable risk levels and threat modeling scenarios are
established up front, so the developers and QA engineers know
what to expect and what to work towards.
• Deployment
– To ensure that the application is deployed as easily and as
securely as possible
26 January 2009
I’m not paranoid – everybody IS after me!
28
A Paranoid Programmer is a Good Programmer
Key Areas Objectives - VIII
• Maintenance
– Products are properly maintained post deployment
– Minimize the attack surface area through out the production lifecycle
– Security defects are fixed properly and in a timely fashion
• Web Services
– SOAP messages that are sent on the wire should be delivered
confidentially and without tampering
– The server needs to be confident who it is talking to and what the
clients are entitled to
– The clients need to know that they are talking to the right server, and
not a phishing site
– System message logs should contain sufficient information to reliably
reconstruct the chain of events and track those back to the
authenticated callers
26 January 2009
I’m not paranoid – everybody IS after me!
29
A Paranoid Programmer is a Good Programmer
Other OWASP Areas
• Phishing
Phishing is a vast topic area as the complexity
of phishing-esque attacks has blossomed over the years.
Some of the current key mitigation strategies are:
–
–
–
–
–
–
–
–
–
–
–
–
–
Deploy an SPF (Sender Policy Framework)
Provide User Education
Make it easy to report scams
Never ask your customers for their secrets
Fix XSS issues
Do not use pop-ups
Don’t use frames or iframes
Move application links off of front page
Enforce local referrers for images and other resources
Always show the address bar, use SSL, do not use IP addresses
Don’t be the source of identity theft
Implement safe-guards within your application
Monitor unusual account activity
26 January 2009
I’m not paranoid – everybody IS after me!
30
A Paranoid Programmer is a Good Programmer
The OWASP Top 10
•
For 2007, these are the published top 10
vulnerabilities:
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery (CSRF)
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
26 January 2009
I’m not paranoid – everybody IS after me!
31
A Paranoid Programmer is a Good Programmer
1 through 5
1. Cross Site Scripting (XSS)
–
XSS flaws occur whenever an application takes user supplied data and
sends it to a web browser without first validating or encoding that content.
XSS allows attackers to execute script in the victim's browser which can hijack user sessions,
deface web sites, possibly introduce worms, etc.
2. Injection Flaws
–
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs
when user-supplied data is sent to an interpreter as part of a command or query. The
attacker's hostile data tricks the interpreter into executing unintended commands or
changing data.
3. Malicious File Execution
–
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and
data, resulting in devastating attacks, such as total server compromise. Malicious file
execution attacks affect PHP, XML and any framework which accepts filenames or files from
users.
4. Insecure Direct Object Reference
–
A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, database record, or key, as a URL or form
parameter. Attackers can manipulate those references to access other objects without
authorization.
5. Cross Site Request Forgery (CSRF)
–
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a
vulnerable web application, which then forces the victim's browser to perform a hostile
action to the benefit of the attacker. CSRF can be as powerful as the web application that it
attacks.
26 January 2009
I’m not paranoid – everybody IS after me!
32
A Paranoid Programmer is a Good Programmer
6 through 10
6. Information Leakage and Improper Error Handling
–
Applications can unintentionally leak information about their configuration,
internal workings, or violate privacy through a variety of application
problems. Attackers use this weakness to steal sensitive data, or conduct
more serious attacks.
7. Broken Authentication and Session Management
–
Account credentials and session tokens are often not properly protected. Attackers
compromise passwords, keys, or authentication tokens to assume other users' identities.
8. Insecure Cryptographic Storage
–
Web applications rarely use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other crimes, such as
credit card fraud.
9. Insecure Communications
–
Applications frequently fail to encrypt network traffic when it is necessary to protect
sensitive communications.
10. Failure to Restrict URL Access
–
Frequently, an application only protects sensitive functionality by preventing the display of
links or URLs to unauthorized users. Attackers can use this weakness to access and perform
unauthorized operations by accessing those URLs directly.
26 January 2009
I’m not paranoid – everybody IS after me!
33