1 Don t Get Burned! Are you Leaving your Critical Applications Defenseless? Ed Bassett Carolyn Ryll, CISSP Enspherics Division of CIBER
2 Presentation Overview Applications Exposed The evolving application security threat Shortcomings of perimeter security Challenges faced Strategy for effective protection Securing Applications to Protect Data Design in vs. bolt on
3 Web-Based Applications Under Attack All the organizations covered by this year s survey experienced some Web site incidents» Source 2004 Computer Crime and Security Survey, Computer Security Institute with the participation of the San Francisco Federal Bureau of Investigation's (FBI) Computer Intrusion Squad
4 Evolving Threat Application security mechanisms are generally the arbiter of data access Less reliance on network, operating system, and database controls Successful attacks more likely to result in access to valuable data/transactions More use of packaged applications, standardized development platforms Attackers can develop attacks with widespread utility Path of least resistance Applications are visible, accessible Many applications are not very well secured
5 Perimeter Controls What about perimeter controls? Largely block network vulnerabilities Example: HTTP requests are able to sail past firewalls, filters, platform hardening, and intrusion detection systems Attacks are inside legal HTTP requests Attacker can tamper with the URL, query string, headers, cookies, form fields, hidden fields to bypass security mechanisms Some of these attacks are buffer overflows, code injection, SQL injection, command insertion, cookie poisoning, hidden field manipulation, format string attacks, and cross site scripting Even SSL secured Websites accept the requests without scrutiny.
6 Perimeter Controls Application code is part of the security perimeter As number, size, and complexity of applications increase, so does perimeter exposure Case study demonstrates one organization that produces hundreds of applications per year Without a proper application security focus, perimeter security is extremely hampered Initial incident, weak access controls Zero traceability.
7 But I Have A Firewall Perimeter security devices do a good job stopping other things but are largely transparent to application attacks Application protocols (usually HTTP, HTTPS) are used for valid access, so are passed by the firewall Applications generally can be accessed from any source address Most applications encrypt sensitive transactions using SSL so firewall cannot see contents of transaction The nomenclature of application requests is not known by the firewall Request to log in remotely telnet://webserver.xyz.com STOP Firewall recognizes that telnet is the wrong protocol and blocks access
8 But I Have A Firewall Perimeter security devices do a good job stopping other things but are largely transparent to application attacks Application protocols (usually HTTP, HTTPS) are used for valid access, so are passed by the firewall Applications generally can be accessed from any source address Most applications encrypt sensitive transactions using SSL so firewall cannot see contents of transaction The nomenclature of application requests is not known by the firewall Request to application https://webserver.xyz.com/yourapp Firewall recognizes HTTPS as an approved protocol and allows access Details of request are encrypted with SSL Firewall cannot tell if request is valid or malicious
9 But I Have An Intrusion Prevention System These devices typically look for Attack Signatures Many web server attacks and some application attacks can be detected and blocked by IPS Attacks in an SSL connection are not visible to the IPS because they are still encrypted Web server attack common_attack_signature STOP IPS recognizes the attack signature and blocks access
10 But I Have An Intrusion Prevention System These devices typically look for Attack Signatures Many web server attacks and some application attacks can be detected and blocked by IPS Attacks in an SSL connection are not visible to the IPS because they are still encrypted Encrypted web server attack https://webserver.xyz.com/ common_attack_signature Simply using SSL (HTTPS) causes attack to be invisible to IPS
11 Successful Attacks Can Yield Significant Damage SQL injection attacks one of the OWASP Top 10 can permit execution of arbitrary database queries Dumping the entire database is not uncommon Similar attacks can often bypass the login prompt Permits attacker to impersonate a valid user Most applications cannot detect these attacks Unauthorized access can continue over a long period The OWASP list (www.owasp.org) is similar to the SANS/FBI Top Twenty List (www.sans.org). The SANS/FBI list is organized around network and infrastructure products. OWASP is focused on application security. While OWASP states a particular focus on Web application security, their recommendations are quite useful to application development vulnerabilities in general, as many of the same coding practices often carry over.
12 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Unvalidated Input Information from Web requests is not validated before being used by a Web application. Attackers can use these flaws to attack backend components through a Web application Broken Access Control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users accounts, view sensitive files, or use unauthorized functions Note previously mentioned Case Study that referenced insignificant access control mechanisms. Broken Authentication and Session Management Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users identities
13 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Cross Site Scripting (XSS) Flaws The Web application can be used as a mechanism to transport an attack to an end user s browser. A successful attack can disclose the end user s session token, attack the local machine, or spoof content to fool the user. Phishing attacks Buffer Overflows Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and Web application server components. An excellent reference for these types of attacks, as well as attacks on Unvalidated Input, and Injection Flaws (next) is The Shellcoder s Handbook by Koziol, Litchfield, Aitel, Anley, Eren, Mehta, and Hassell (Wiley Publishing, 2004)
14 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Injection Flaws Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the Web application. Improper Error Handling Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the Web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. In actuality, it is very difficult to test for all errors. This being said, it is then difficult to perform complete error handling.
15 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Insecure Storage Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. Case study: Cryptographic algorithm conversion Denial of Service Attackers can consume Web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail. An excellent reference is How to Break Software Security, by Whittaker and Thompson (Pearson Education, 2004). Holodeck Written by faculty and students at Florida Tech Case study: Network fault injection denial of all ports vs. denial of network access
16 Successful Attacks Can Yield Significant Damage The OWASP Top Ten: Insecure Configuration Management Having a strong server configuration standard is critical to a secure Web application. These servers have many configuration options that affect security and are not secure out of the box. Case study: Medical devices and Web servers.
17 Comparison Factor How to Break Software Security (Wiley, 2004) Unanticipated Scenarios Blocking access to libraries Manipulating application registry values Forcing use of corrupt files Manipulation and replacement of files Environmental fault conditions (low memory, disk-space and network-availability conditions) Any of the above may result in a minimum of Denial of Service, to Broken Access Control
18 Comparison Factor How to Break Software Security (Wiley, 2004) User Interface Attacks Overflowing input buffers (Corresponds to Buffer Overflows) Examine all common switches and options Explore escape characters, character sets, and commands Note the similarity to OWASP s Injection Flaws and Unvalidated Input
19 Comparison Factor How to Break Software Security (Wiley, 2004) Design Attacks Default and test account names and passwords (Corresponds to Broken Access Control) Expose unprotected test APIs Connect to all ports Fake the source of data Create loop conditions in any application that interprets script, code, or other user-supplied logic (Corresponds to Injection Flaws, Unvalidated Input, Cross Site Scripting) Use alternate routes to accomplish the same task Force the system to reset values (Corresponds to Unvalidated Input)
20 Comparison Factor How to Break Software Security (Wiley, 2004) Implementation Attacks Get between time of check and time of use (Corresponds to Insecure Storage) Create files with the same name as those protected with a higher classification (Corresponds to Broken Access Control) Force all error messages (Corresponds to Improper Error Handling) Look for temporary files and screen their contents for sensitive information (Corresponds to Broken Access Control, and Broken Authentication and Session Management)
21 Successful Attacks Can Yield Significant Damage These issues are not new many have been around for decades Mistakes keep recurring No magic cure-all Requires a change in development culture, developer training, updated software processes, use of technology where appropriate
22 Challenges Faced Lack of true definition of application security gray area in understanding Some definitions, it relates only to custom application code Other definitions, it covers the entire application layer, which includes libraries, server configurations, and application layer protocols Organizational specificity Difficult to state relativity of specific vulnerabilities to individual organizations Individual organizations are the only ones qualified to assess their own risk levels in relation to specific types of vulnerabilities Example: Algorithmic vulnerabilities versus cross-site scripting
23 Challenges Faced Placement of application security into the SDLC Often gets placed into the cycle after code completion, as an afterthought Succeeds when built in from the start Most cost effective Consulting projects often see a change in attitude in the client from entry to departure. Entry, the client is bored, does not think that vulnerabilities will be found Departure, the client is overwhelmed at everything they must do to mitigate all the vulnerabilities that were found.
24 Strategy For Effective Protection Be deliberate Make security a priority item in application projects Adopt reliable, consistent application security processes Obtain specialized application security expertise Establish security standards for apps Use independent validation to monitor compliance
25 Designing Security In Design applications to be secure Analyze potential attacks/risks Establish security requirements for custom applications Evaluate security features in selection of off-the-shelf packages Build applications to be secure Mandate secure coding practices Test the security of applications Before acceptance, perform assurance testing Monitor applications to maintain security Monitor logs Validate security posture during operations Evaluate security impact of changes
26 What s Included? Typical Application Security Scope Authentication Authorization Session Context Control Audit Logging Intrusion Detection and Deterrence Data Cleansing Data Privacy and Integrity Back-end Communications Alternative Interfaces
27 Application Security Scope Authentication Mechanisms such as passwords or tokens that are used to authenticate the identity of the user, including an analysis of whether the login process can by bypassed Authorization Mechanisms for controlling what application functionality and data are accessible to each user, including an analysis of anonymous access restrictions (what users can see without logging into the application) Session Context Control Mechanisms to ensure the integrity and segregation of user sessions, including an analysis of whether it is possible to spoof or hijack another user s session
28 Application Security Scope Audit Logging Features to track and log user actions, especially unauthorized access attempts Intrusion Detection and Deterrence Mechanisms to detect and/or block unauthorized access attempts, including an analysis of the application s response to account and password guessing attacks and URL guessing/modification attacks Data Cleansing Mechanisms to detect bad user input, including an analysis of the application s reaction to null/missing data, extraneous data, and buffer overflow attacks in selected fields
29 Application Security Scope Data Privacy and Integrity Mechanisms to protect the privacy and integrity of data exchanged with the user during an application session, including encryption of passwords and sensitive data, and attempts to spoof or replay a user session Back-End Communications Mechanisms by which the application exchanges data with back-end databases or applications, including an analysis of the protocols used and means of authentication Alternative Interfaces Other application interfaces (Web or otherwise) that are used by administrators and maintainers to configure the application
30 Application Security Scope Importance is also on Policies and Procedures Policies and procedures should be present that surround the use and administration of the application Security should be built using a Security Development Life Cycle that mirrors the Software Development Life Cycle Security should be built into the application from the beginning, rather than retrofitted at the end.
31 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production Support Timely and relevant security input at each stage of application development Reference: NIST Special Publication , Security Considerations in the System Development Life Cycle Incident Handling
32 Life Cycle Considerations Time Line Requirement/Specification Set requirements for security features/functions Design Development Test Documentation Post-production support Incident Handling
33 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Detailed design Choose security products/mechanisms Trade-offs between security and other criteria Incident Handling
34 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Implement security features Training Secure coding guidelines Post-production support Incident Handling
35 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Incident Handling Security Compliance testing Ensure the application security features meet the design requirements Penetration testing Ensure the application is resistant to hostile acts
36 Spectrum of Assurance Testing Automated External Network Scan Network Penetration Testing Network, Host, and App Testing Compliance Testing Customized Testing of All Components In-depth S/W and H/W Trust Evaluation Low Typical Choices Commercial Gov t Non-DoD DoD/Intel High
37 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Incident Handling Risk evaluation Assurance evidence as a decision aid for the business unit in accepting the security risks associated with the application Compliance evaluation Document how application meets security and privacy regulations
38 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production Support Incident Handling Establish operational procedures to monitor/maintain security Review and test any software changes that affect security Periodic verification of the security posture of applications
39 Life Cycle Considerations Time Line Requirement/Specification Design Development Test Documentation Post-production support Procedures and resources for Incident analysis Investigation Damage control Reporting Incident Handling
40 What About Risks In Existing Applications? Assessment Testing Decision Support for Risk Acceptance Decisions Certification Testing Incident Handling Recommendations for Enhancements Implementation of Enhancements
41 Risks in Existing Applications May perform a triage to decide critical applications Organization should perform a formal application security assessment Factors involved will include tradeoffs in security versus consequences to the business. This is not the pretty picture, but it is the reality. Case study: Low-end medical device and small hospital Organizations have only so much time, and so much money. When assessing existing application security risks, not all risks may be mitigated. This, again, supports the argument that it is better to add application security to the design/build process from the beginning.
42 California SB 1386 Information Practices Act If you store personal information on one or more California residents, you must notify them if their data have (or may have) been accessed illegally Disclosure no longer a PR decision Stated goal: minimize damage from identity theft Expeditious notification of possible misuse is imperative Encryption of data is critical but not sufficient Law only applies to unencrypted personal information But what if data is decrypted as part of the breach? Affects all companies who do business with California residents Outsourcing companies Data processing and storage companies Similar legislation being introduced elsewhere
Standard: Version: Date: Requirement: Author: PCI Data Security Standard (PCI DSS) 1.2 October 2008 6.6 PCI Security Standards Council Information Supplement: Application Reviews and Web Application Firewalls
WHITE PAPER Informatica Cloud Architecture and Security Overview Independent Analysis of the Architecture and Security Features of Informatica Cloud Prepared by Mercury Consulting, a leader in Ground to
Data protection Protecting personal data in online services: learning from the mistakes of others May 2014 Contents Introduction... 2 What the DPA says... 4 Software security updates... 5 Software security
Best Practices: Use of Web Application Firewalls Version 1.0.5, March 2008, English translation 25. May 2008 Author: OWASP German Chapter with collaboration from: Maximilian Dermann Mirko Dziadzka Boris
Cyber Security Planning Guide The below entities collaborated in the creation of this guide. This does not constitute or imply an endorsement by the FCC of any commercial product, service or enterprise
PCI DSS PCI Prioritized DSS Approach for for PCI DSS.0 The Prioritized Approach to Pursue PCI DSS Compliance The Payment Card Industry Data Security Standard (PCI DSS) provides a detailed, 1 requirements
Reducing the Cyber Risk in 10 Critical Areas Information Risk Management Regime Establish a governance framework Enable and support risk management across the organisation. Determine your risk appetite
Cyber Security Planning Guide The below entities collaborated in the creation of this guide. This does not constitute or imply an endorsement by the FCC of any commercial product, service or enterprise
Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS) Glossary of Terms, Abbreviations, and Acronyms Version 3.0 January 2014 AAA Access Control
Special Publication 800-125 Guide to Security for Full Virtualization Technologies Recommendations of the National Institute of Standards and Technology Karen Scarfone Murugiah Souppaya Paul Hoffman NIST
The Critical Security Controls for Effective Cyber Defense Version 5.0 1 Introduction... 3 CSC 1: Inventory of Authorized and Unauthorized Devices... 8 CSC 2: Inventory of Authorized and Unauthorized Software...
Securing Enterprise Applications Version 1.1 Updated: November 20, 2014 Securosis, L.L.C. 515 E. Carefree Highway Suite #766 Phoenix, AZ 85085 T 602-412-3051 firstname.lastname@example.org www.securosis.com Author
Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors Program Guide Version 2.0 May 2013 Document Changes Date Version Description February 11, 2010 1.0 May 2013 2.0 Approved Scanning
Firewall Strategies June 2003 (Updated May 2009) 1 Table of Content Executive Summary...4 Brief survey of firewall concepts...4 What is the problem?...4 What is a firewall?...4 What skills are necessary
FOREWORD A key component in protecting a nation s critical infrastructure and key resources (CIKR) is the security of control systems. WHAT ARE CONTROL SYSTEMS? Supervisory Control and Data Acquisition
Standards for Internal Control in New York State Government October 2007 Thomas P. DiNapoli State Comptroller A MESSAGE FROM STATE COMPTROLLER THOMAS P. DINAPOLI My Fellow Public Servants: For over twenty
Report Number: I332-016R-2005 Security Guidance for Deploying IP Telephony Systems Systems and Network Attack Center (SNAC) Released: 14 February 2006 Version 1.01 SNAC.Guides@nsa.gov ii This Page Intentionally
Checklist to Assess Security in IT Contracts Federal Agencies that outsource or contract IT services or solutions must determine if security is adequate in existing and new contracts. Executive Summary
Cloud Service Level Agreement Standardisation Guidelines Brussels 24/06/2014 1 Table of Contents Preamble... 4 1. Principles for the development of Service Level Agreement Standards for Cloud Computing...
What To Do If Compromised Visa Inc. Fraud Control and Investigations Procedures Version 3.0 (Global) Effective May 2011 Visa Public Table of Contents Introduction... 1 Identifying and Detecting Security
Standard: Version: 2.0 Date: June 2011 Author: PCI Data Security Standard (PCI DSS) Virtualization Special Interest Group PCI Security Standards Council Information Supplement: PCI DSS Virtualization Guidelines
Apple Technical White Paper Best Practices for Deploying FileVault 2 Deploying OS X Full Disk Encryption Technology August 2012 OS X 10.7.4 1 Contents Overview 3 Gain Protection. Retain Simplicity. 4 Design
PeopleSoft Red Paper Series Securing Your PeopleSoft Application Environment July 2010 Including: How to Plan for Security How to Secure Customized System Exposing PeopleSoft outside the Firewall Securing
V 1.0 November, 2010 CYBERSECURITY The protection of data and systems in networks that connect to the Internet 10 Best Practices For The Small Healthcare Environment Your Regional Extension Center Contact
New York State Office of the State Comptroller Division of Local Government and School Accountability LOCAL GOVERNMENT MANAGEMENT GUIDE Information Technology Governance Thomas P. DiNapoli State Comptroller
April 21, 2009 Dines Bjørner: MITS: Models of IT Security: 1 Models of IT Security Security Rules & Regulations: An Interpretation Dines Bjørner Fredsvej 11, DK 2840 Holte, Denmark Presented at Humboldt
Special Publication 800-41 Revision 1 Guidelines on Firewalls and Firewall Policy Recommendations of the National Institute of Standards and Technology Karen Scarfone Paul Hoffman NIST Special Publication
A Websense White Paper ADVANCED PERSISTENT THREATS AND OTHER ADVANCED ATTACKS: THREAT ANALYSIS AND DEFENSE STRATEGIES FOR SMB, MID-SIZE, AND ENTERPRISE ORGANIZATIONS REV 2 ADVANCED PERSISTENT THREATS AND
23c3 Security in the cardholder data processing?! Manuel Atug and Thilo W. Pannen SRC Security Research & Consulting GmbH, Bonn, Germany, email@example.com Experiences and lessons learned with the Payment