Welcome to our comprehensive series on the Top 5 Security Considerations for a New Web App. This penultimate post, focusing on Logging and Monitoring, is part of a broader effort to equip developers, IT professionals, and web administrators with essential security knowledge for proactively safeguarding their web applications. Throughout this series, we explore the critical security measures that are fundamental to the development and launch of a secure web application. For a complete overview and the context of this series, we invite you to read the Introduction post. This foundational understanding will enhance your grasp of why each consideration plays a vital role in the lifecycle of a web application in the initial buildout and the days immediately following the launch. Join us as we delve into the best practices, strategies, and real-world applications that underscore the importance of implementing robust security measures from the ground up.
Previous: Data Encryption and Protection
4. Logging And Monitoring
In the complex landscape of web application security, the roles of logging and monitoring are paramount, acting as critical components for maintaining the integrity and resilience of online platforms. These mechanisms serve as the eyes and ears of an IT environment, offering insights into operational behavior and potential security threats. Through diligent logging and vigilant monitoring, organizations can detect, analyze, and respond to incidents with precision and speed.
Logging
Logging entails the systematic recording of events and transactions within an application. This recorded data plays a crucial role in understanding the actions and events that transpire within an application, providing a detailed account of system operations, security incidents, and potential vulnerabilities.
Key Aspects of Effective Logging include:
- Comprehensive Coverage: It's vital to ensure that logging mechanisms encompass all critical aspects of the application, capturing every action from user authentication attempts to system errors and data modifications.
- Detail and Clarity: The utility of a log is only as good as the information it contains. Logs must strike a balance between offering detailed records for analysis and maintaining clarity to prevent data overload.
- Secure Storage: Given that logs can contain sensitive information, securing these records against unauthorized access and ensuring their integrity is of utmost importance.
- Redacting Secrets: While you certainly want to have enough information in your logs to give you an understanding of what is happening in your application, there are certain types of information that you intentionally want to omit from log entries. For example, you do not want to capture payment card numbers or cleartext passwords or even password hashes.
Monitoring
While logging provides the raw data, monitoring is the proactive process of reviewing this data and the application's overall health in real-time. Effective monitoring can alert to abnormal activities that may signify security breaches, operational failures, or other significant issues.
Strategies for Effective Monitoring include:
- Establishing Baselines: You need to capture and identify what is normal before you can determine what is unusual.
- Real-Time Alerts: Configuring immediate alerts for unusual activity patterns enables organizations to quickly detect and respond to potential security incidents.
- Automated Analysis: Leveraging tools that automatically analyze log data helps identify trends or anomalies, facilitating early detection of security threats.
- Regular Audits: Continuous evaluation of both the logging and monitoring systems ensures they are capturing and analyzing the relevant data efficiently.
Best Practices
Implementing best practices in logging and monitoring involves a combination of technical measures and organizational policies. Protecting log data, establishing appropriate retention periods, and ensuring that access to logs is tightly controlled are essential steps in leveraging logging and monitoring as effective security and operational tools. One of the most difficult parts is ensuring that monitoring and alerting catches the events that need to be investigated, without generating so much noise that they are indistinguishable.
Case Study - Failure to React - Target (2013)
For a case study focusing on the pivotal role of logging and monitoring, the Target data breach of 2013 provides a textbook example. This incident not only underscores the importance of these security measures but also highlights the consequences of failing to act on the intelligence they provide.
The Timeline of the Target Data Breach:
- November 27, 2013: The breach began two days before Thanksgiving, a peak shopping period in the United States, when malicious software was installed on Target’s security and payments system designed to steal every credit card used at the company’s 1,797 U.S. stores.
- November 30, 2013: The first alerts from FireEye were triggered. The software detected the installation of the malware but the security team did not immediately respond to the alerts.
- December 12, 2013: DOJ alerted Target to the breach.
- December 15, 2013: Target confirmed the breach internally after further investigation following persistent signs of unauthorized access.
- December 18, 2013: A cybersecurity journalist contacted Target after learning about the breach from a source, which prompted Target to make a public announcement.
- December 19, 2013: Target publicly acknowledged the breach, stating that up to 40 million credit and debit card accounts might have been affected. Later investigations raised the estimate to 70 million customers who had personal information stolen.
The Target breach vividly illustrates the critical need for not only implementing logging and monitoring systems but also ensuring that the alerts they generate are promptly and effectively addressed. In Target’s case, the company had invested in a sophisticated security monitoring system that successfully detected the initial signs of the breach. However, the failure to act on these alerts in a timely manner allowed the attackers to continue their operations undetected for weeks, leading to the extensive exposure of customer data.
The aftermath of the breach had far-reaching implications for Target, including the resignation of its CEO and CIO, over $200 million in costs related to the breach, and significant damage to its reputation among consumers. Additionally, the incident led to a reevaluation of security practices across the retail industry, emphasizing the importance of active and responsive security operations centers (SOCs).
The Target data breach highlights that effective security is not just about having the right tools in place but also about ensuring that these tools are integrated into an operational framework that prioritizes rapid response to threats. Logging and monitoring are essential for early detection of security incidents, but their effectiveness is contingent upon the actions taken in response to the intelligence they provide. This case reinforces the lesson that proactive and responsive security practices are critical in protecting sensitive information from cyber threats.
The senate kill-chain analysis of the breach is available here: https://www.commerce.senate.gov/services/files/24d3c229-4f2f-405d-b8db-a3a67f183883
In Summary
It is natural for logging and alerting to improve over time. When considering what to log, I tend to think through what questions I definitely need to be able to answer. For example, considering a single user account, these are some questions that I might imagine:
- Did this particular user account log in (successfully)?
- Were there failed login attempts first?
- Did the successful login come from the same person or place? What information tells us this?
- Did the same person attempt to log in with other user accounts?
- Was the contact information for the account (e.g. email address) changed?
- If so, what was the previous value?
- What data was accessed during this session?
- Was any data changed? If so, which records?
To answer each of these questions, you need certain information to be available.YouI need to be able to efficiently find it in the logs, or You need to be able to correlate the log activity to other data sources such as audit tables or revision history. In either case, you want to be certain that you can confidently answer each question, or you have a clear reason why that question cannot be answered.
For monitoring and alerting, you consider a few key things:
- Are there particular patterns of behavior, represented in the logging questions, that will usually indicate malicious use? An example would be the same source trying to log in with many different accounts. A user might forget which email address they used to sign-up, but they probably only have 2 or 3 possibilities to try.
- Are there behaviors that should never occur in organic use of the application, that suggest an attempt to circumvent security controls? For example, consider a multi-user Todo list application where each user has a private list of tasks. They can select one of their own tasks to see more detail or change the status of the task. However, if they do not see other users’ lists, there is no natural way for them to accidentally attempt to change the status of another user’s task. The only way you would expect this to occur is if they modify the task ID in their traffic. You should set an alert on this, as there is a high probability that it indicates either 1) an account is being used maliciously or 2) the Todo application broke in a way that has compromised the integrity of the authorization boundaries. In either case, you want to investigate in a timely manner.
Additional Materials
- OWASP Logging Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
This lengthy cheat sheet really covers the topic in depth, including key aspects of the topic such as what to log. - Application Logging Best Practices by Loggly (https://www.loggly.com/use-cases/application-logging-best-practices/)
This is not a security-focused view, but provides a more approachable, general look at application logging. It is useful for providing a more complete understanding of logging.
