Paranoid Programming Practices

1. 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. (He wouldn’t give me his name…) I’m not paranoid – everybody IS after me!

2. A Mostly PCI/OWASP Agenda • Overview of Policy Frameworks relatedto an organization’s 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. I’m not paranoid – everybody IS after me!

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 isn’t the answerDirect 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.” I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

5. The 3 Pieces – Methodology • Development MethodologyThe 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 I’m not paranoid – everybody IS after me!

6. The 3 Pieces - Standards • Coding StandardsYou’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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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. 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. I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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, 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-longprocess, not a one shot accident.” I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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. I’m not paranoid – everybody IS after me!

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. I’m not paranoid – everybody IS after me!

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. I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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? I’m not paranoid – everybody IS after me!

19. 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 I’m not paranoid – everybody IS after me!

20. Here’s the formula… • Net financial risk can be expressed as: I’m not paranoid – everybody IS after me!

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 • Deployment • Maintenance I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 – 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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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 • 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 I’m not paranoid – everybody IS after me!

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 I’m not paranoid – everybody IS after me!

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. I’m not paranoid – everybody IS after me!

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. I’m not paranoid – everybody IS after me!