Application Security Logging and Monitoring The Next Frontier

Application Security Logging and Monitoring The Next Frontier OWASP Peter Freiberg Principal Consultant Shelde pfreiberg@shelde. com +61 3 9650 7852 April 2012 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http: //www. owasp. org

Application Security Logging and Monitoring The Next Frontier This talk will discuss: • The four key challenges for application security logging and monitoring • Common issues in current logging practices • Current resources (or lack of) available to developers for security logging • Tools for correlating and alerting from log sources • Logging in multi-tiered architectures and disparate systems • Which logging capabilities can be driven by application security and what types of logging might be required by audit and the business OWASP 2

Key challenges for Application Security Logging 1. 2. 3. 4. Lack of Security Logging Frameworks Lack of guidance on what and how to log Lack of requirements for security logging Lack of correlation and alerting capabilities OWASP 3

Where is the real threat? According to the 2010 Fraud and Misconduct Survey by KPMG Australia • 65% of Fraud was from ‘Inside Jobs’ • This represented 98% of the total fraud loss. Do you think an insider used SQL injection or XSS to commit fraud? (Probably not) Source: https: //www. kpmg. com/AU/en/Issues. And. Insights/Articles. Publications/Fraud-Survey/Documents/Fraud-and. Misconduct-Survey-2010. pdf OWASP 4

Key challenges for Application Security Logging Many applications have poor security logs (and sometimes have none at all) Without good security event information it is difficult to: • detect attacks • detect compromised user account • detect fraud • detect abuse of privileges and • Respond to events OWASP 5

Challenge #1 Lack of Security Logging Frameworks OWASP 6

Java Common Logging Severity Levels Where is the security log level? Log Level Description fatal Severe errors that cause premature termination. Expect these to be immediately visible on a status console. error Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console. warn Use of deprecated APIs, poor use of API, 'almost' errors, other runtime situations that are undesirable or unexpected, but not necessarily "wrong". Expect these to be immediately visible on a status console. info Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum debug detailed information on the flow through the system. Expect these to be written to logs only. trace more detailed information. Expect these to be written to logs only. Source: http: //en. wikipedia. org/wiki/Java_logging_framework OWASP 7

Current Logging frameworks are focused on identifying where a technical fault has occurred. OWASP 8

Challenges for detail in logging functions Example given to developers public class Foo { private Log log = Log. Factory. get. Log(Foo. class); public void foo() { . . . try { } … } catch (Illegal. State. Exception e) log. error("Something bad happened to " + name, e); } Source: http: //commons. apache. org/logging/apidocs/org/a pache/commons/logging/package-summary. html Log Event Data should include the following: 1. Time stamp from a trusted system component 2. Severity rating for each event 3. Tagging of security relevant events, if they are mixed with other log entries 4. Identity of the account/user that caused the event 5. Source IP address associated with the request 6. Event outcome (success or failure) 7. Description of the event Source: https: //www. owasp. org/index. php/OWASP_Secure_Coding_ Practices_-_Quick_Reference_Guide OWASP 9

Security Logging needs to be more tightly coupled with the user performing the action (instead of the object class where the error occurred) OWASP 10

How to add a security log level in Framework X OWASP guide on how to add a security log level in the Java log 4 j framework. https: //www. owasp. org/index. php/How_to_add_a_security_log_level_in_log 4 j However, there are lots of logging frameworks. OWASP 11

There are many logging frameworks Java (commonly used) . Net (commonly used) • Commons Logging • Microsoft Enterprise Library • Log 4 j • Log 4 net • Logback • Logger. NET • SLF 4 J • NLog Other frameworks Craftsman Spy, Houston, j. Lo, Jmyra, JTrace. Dump, Just 4 log, Limpid Log, Logging Toolkit, Monolog, Object. Guy Framework, Protomatter, RP Logging, Simple Log, Smart. Inspect, Trace. Tool C# Logger, Common. Data, CSharp Dot Net Logger, Debug. Writer, Log. This, Net. Trace, Nspring, Object. Guy Framework, Smart. Inspect, Tcp. Trace, Traceract, Trace. RT. NET, Traffic Monitor Source: http: //www. java-logging. com/ Source: http: //www. dotnetlogging. com/ OWASP 12

Other considerations for Logging Frameworks Data Validation (Who does the escaping – the developer or the framework? ) • XSS in web based logging interfaces • Log Forging (Can an attacker guess the log format and alter it using carriage return injection? ) Signal to noise ratio • Separating Application Logs and Security logs • Maybe the noise is the signal? (Is 40, 000 exceptions and stack traces an attack? ) Access control of security logs • Who has access to view or modify the security logs? (Are they just text files? Or database rows? Or centrally stored? ) OWASP 13

Other considerations for Logging Frameworks Storage growth requirements (e. g. What volume of log data is generated per day or month? 1 MB, 100 MB, 1 GB? ) Data retention periods (e. g. How long do you need logs for? 3 months? 3 years? ) Regulatory restrictions on centralised logging solutions (e. g. It might not be allowed to centralise application logs outside of a country’s borders) OWASP 14

Challenge #2 Lack of guidance on what and how to log OWASP 15

What detail needs to be logged? What developers have What security people want • • Severity rating for each event • Identity of the account/user that caused the event • Source IP address associated with the request • User context across application tiers (internal webservice, MQ, Database) • log. error("Something bad happened to " + name, e); Time stamp Event outcome (success or failure) It would be nice if we had something like: Log. security( User. Context, // containing username, ip address, browser etc Application. Events. Data. Validation. Failure, e); Free form text for log messages makes it harder to identify and correlate events OWASP 16

The level of details for logging Log Event Data should include the following: 1. Time stamp from a trusted system component 2. Severity rating for each event 3. Tagging of security relevant events, if they are mixed with other log entries 4. Identity of the account/user that caused the event 5. Source IP address associated with the request 6. Event outcome (success or failure) 7. Description of the event Source: https: //www. owasp. org/index. php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide Challenges: • What event types are there (technical and logical) and are they defined for the application and the organisation? • What rating do you give events? • Do you have the details of the requesting user? (username, IP address, etc) • Are the logs in a format that can be easily consumed by logging and correlation tools OWASP 17

High level security logging requirements • Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software • Restrict access to logs to only authorized individuals • Utilize a master routine for all logging operations • Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords • Ensure that a mechanism exists to conduct log analysis Source: https: //www. owasp. org/index. php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP 18

High level security logging events • Log all input validation failures • Log all authentication attempts, especially failures • Log all access control failures • Log all apparent tampering events, including unexpected changes to state data • Log attempts to connect with invalid or expired session tokens • Log all system exceptions • Log all administrative functions, including changes to the security configuration settings • Log all backend TLS connection failures • Log cryptographic module failures Challenge with this guidance: Mostly technical nature Source: https: //www. owasp. org/index. php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide OWASP 19

Starting Point - OWASP App. Sensor Project Overview The App. Sensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the App. Sensor tool which can be utilized by any existing application interested in adding detection and response capabilities. Detection App. Sensor defines over 50 different detection points which can be used to identify a malicious attacker. Response App. Sensor provides guidance on how to respond once a malicious attacker has been identified. Possible actions include: logging out the user, locking the account or notifying an administrator. More than a dozen response actions are described. Source: https: //www. owasp. org/index. php/OWASP_App. Sensor_Project OWASP 20

What to log? What level of detail is required to identify a user and reliably trace back to an unauthorised malicious action? Where are they? (is it a green screen internal application? An internet facing web application, a corporate desktop application? ) What technical details can be identified and logged? (e. g. XSS, Change of IP address mid-session, data validation issues etc. ) What business level detail must be logged? (e. g. viewing sensitive data, who did what for segregation of duties, etc. ) OWASP 21

Challenge #3 Lack of requirements for security logging OWASP 22

Types of Business Events Logical, Behavioural and Compliance • Privileged User Access • Process Violations • Segregation of Duties bypass • Bulk Downloads • Privacy Violations Influencers: • Business Owners • Internal Audit • Regulatory Bodies • Operational Risk • Fraud Teams • Security Consultants (PCI-DSS, SOX, Government, etc. ) OWASP 23

Challenges for Security Logging requirements Communication and Education • Does the fraud team talk to the business, security and developers? • What incidents have occured in the past? Could these have been avoided? • How can requirements be defined that can be technically implemented and tested? • How many applications and systems need to log to gain value by reducing risk and fraud? Technology: • What will be used to monitor and correlate events? Business: • Who pays for the monitoring technology? (Is it a security initiative or business solution? ) OWASP 24

Challenge #4 Lack of correlation and alerting capabilities OWASP 25

Correlation and alerting capabilities If an business application has made it this far, its got: • Some type Security Logging Framework • Some list of security event types (including technical, logical and process) • Business requirements for logging So, we’ve got security event logs, what do we do with them? OWASP 26

Correlation Technology Security Information and Event Management (SIEM) technology provides: • Security Information Management (SIM) – log management and compliance reporting • Security Event Management (SEM) – real-time monitoring and incident management for security-related events from networks, security devices, systems and application SIEM Technology is typically deployed to support three primary use cases: • Compliance – Log management and compliance reporting • Threat Management – real-time monitoring of user activity, data access and application activity and incident management • A deployment that provides a mix of compliance and threat management capabilities Source: Gartner Magic Quadrant for SIEM. http: //www. arcsight. com/collateral/whitepapers/Gartner_Magic_Quadrant_2011. pdf OWASP 27

Event correlation requires a broader view OWASP 28

Event correlation requires a broader view Often business processes rely on many applications and systems. To see the enterprise view or end to end process correlation needs to occur outside. Enterprise Event Correlation & Response Centralised Log Aggregation & Management Application 1 Meaningful Logs Application 2 Meaningful Logs Application 3 Meaningful Logs Application 4 Meaningful Logs … Application N Meaningful Logs OWASP 29

Where should correlation occur? Enterprises typically have more than one interface for a given application. For example: • Web application for customers • Green screen Mainframe application for back end administration • Desktop GUI for Help Desk staff Abuse case or threat scenario: • An administrator using the green screen application changes a help desk staff password who is on holidays • then logs on as a help desk operator and changes a customers password • then logs on as the customer from an internet café Can you detect this scenario in any single application? OWASP 30

Solving these challenges Technology challenges 1. Lack of Security Logging Frameworks 2. Lack of guidance on what and how to log Business challenges 1. Lack of requirements for security logging 2. Lack of correlation and alerting capabilities OWASP 31

Solving these challenges Where to start? Focus on high risks and incidents What risk or impact are you minimising: • Reduced internal fraud • Compromised user accounts (leading to external fraud) • Process Violations • Compliance with regulatory bodies • External compromise OWASP 32

Solving these challenges Technology challenge 1. Security Logging Frameworks Possible solutions: • OWASP Project providing security in common Logging Frameworks • Security professionals working with the producers of software (E. g. Oracle Java, Microsoft, PHP) • Create a reference implementation OWASP 33

Solving these challenges Technology challenge 2. Guidance on what and how to log Possible solutions: • Logging frameworks that support security • Defined event types with example implementations and outputs • Building and sharing experience through use of centralised logging, monitoring and correlation tools (Supporting projects like App. Sensor which are defining event types and responses will help build industry knowledge) (Experience in the trenches of real applications and business will help drive what works and what doesn’t) • Event Standards like Common Event Expression (CEE) (see http: //cee. mitre. org) OWASP 34

Solving these challenges Business challenge 3. Requirements for security logging Possible solutions: • Make it easy for the business – defined logging events allow for easier communication and implementation • Better Education and Consulting – How will this help the business? • Break down corporate silos (Understand what Fraud and Incidence response is occurring, what audit requirements exists and socialise with security and development for implementation) • Be Realistic – What value will security logging and monitoring provide and what risks can this help mitigate OWASP 35

Solving these challenges Business challenge 4. Correlation and alerting capabilities Possible solutions: • Look for Compliance drivers such as SOX, PCI-DSS • Adopt security logging standards for applications • Be realistic – what value will security logging and monitoring provide • Common event types and logging formats (Spending on monitoring and correlation infrastructure can’t always be justified, possibly can piggy back off other initiatives) (Having key applications log security events is better than waiting for the full enterprise solution. ) OWASP 36

Application Security Logging and Monitoring The Next Frontier Summary: • The four key challenges for application security logging and monitoring • Common issues in current logging practices • Current resources (or lack of) available to developers for security logging • Tools for correlating and alerting from log sources • Logging in multi-tiered architectures and disparate systems • Which logging capabilities can be driven by application security and what types of logging might be required by audit and the business OWASP 37

Questions? Application Security Logging and Monitoring The Next Frontier Peter Freiberg Principal Consultant Shelde pfreiberg@shelde. com +61 3 9650 7852 OWASP 38