Paranoid Programming Practices

1
Paranoid Programming Practices

• 26 January 2009
• Its not a matter of whether youre paranoid or
  not.
• Its a matter of whether youre paranoid enough.
• - Unknown. (He wouldnt give me his name)

2
A Mostly PCI/OWASP Agenda

• Overview of Policy Frameworks relatedto an
  organizations efforts towards PCI
  andformalizing secure programming practices.
• Details of Secure Programming Practices.
• 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.

3
Basic Premises

• Everyone is out to get usI think we all know by
  this point in time that CyberCrime pays...It
  has become a well organized, financed, and
  executed business.
• Hardware isnt the answerDirect quote from
  OWASP.orgUnlike 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.

4
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 DSSThe Payment Card Industry (PCI) has
  created their Data SecurityStandard (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

5
The 3 Pieces Methodology

• Development MethodologyThe methodology used
  isnt 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 organizations 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

6
The 3 Pieces - Standards

• Coding StandardsYoull 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

7
The 3 Pieces - Control

• Source ControlFormal 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

8
Approaching Secure Coding

• Secure programming can be looked at fromfour
  perspectives
• Attackers
• Tenants
• Architectures
• Principles
• A note about Asset ClassificationWhile 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. Its 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.

9
Know Your Attackers

• You know the old saying, keep your friendsclose
  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

10
Tenants

• ConfidentialityOnly allow access to data for
  which the user is permitted
• IntegrityEnsure data is not tampered or altered
  by unauthorized users
• AvailabilityEnsure systems and data are
  available to authorized users when they need it

11
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,
  Microsofts 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-longprocess,
  not a one shot accident.

12
Principles

• Security Principles are guidelines designedto
  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

13
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.

14
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.

15
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.

16
Threat Risk Modeling

• Microsoft has robust and well documentedthreat
  modeling methodologies. They includethe
  following steps
• 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

17
STRIDE

• Stride is an methodology for identifyingthe
  following known threats
• Spoofing Identity
• Tampering with Data
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

18
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 PotentialIf a threat exploit occurs, how
  much damage will be caused?
• ReproducibilityHow easy is it to reproduce the
  threat exploit?
• ExploitabilityWhat is needed to exploit this
  threat?
• Affected UsersHow many users will be affected?
• DiscoverabilityHow easy is it to discover this
  threat?

19
And my own favorite

• Quantify Risk Financially Its 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
  documentThe Financial Impact of Cyber
  RiskThe 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
  companys Chief Technology Officer. Nor is it
  just a legal problem to be handed over to the
  companys Chief Legal Counsel a customer
  relationship problem to be solved by the
  companys 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 herehttp//webstore.ansi.org/cyber
  security.aspx

20
Heres the formula

• Net financial risk can be expressed as

21
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

22
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

23
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 applications 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

24
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

25
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 its 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
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

27
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

28
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

29
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

30
Other OWASP Areas

• PhishingPhishing is a vast topic area as the
  complexityof 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
• Dont 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
• Dont be the source of identity theft
• Implement safe-guards within your application
• Monitor unusual account activity

31
The OWASP Top 10

• For 2007, these are the published top
  10vulnerabilities
• Cross Site Scripting (XSS)
• Injection Flaws
• Malicious File Execution
• Insecure Direct Object Reference
• Cross Site Request Forgery (CSRF)
• Information Leakage and Improper Error Handling
• Broken Authentication and Session Management
• Insecure Cryptographic Storage
• Insecure Communications
• Failure to Restrict URL Access

32
1 through 5

• 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.
• 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.
• 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.
• 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.
• 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.

33
6 through 10

• 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.
• 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.
• 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.
• Insecure Communications
• Applications frequently fail to encrypt network
  traffic when it is necessary to protect sensitive
  communications.
• 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.