Infosec leaders have a lot of corners to cover in their cybersecurity strategy. When crafting the tactics and onboarding the platforms that will protect sensitive information, the checklist of requirements could be missing a very important vector for attack, compliance risk or data loss: application logs.
The problem stems from the nature of application logs themselves — do you know which information exists in your application logs? Can you see it, or keep track of it? Since there are so many logs being generated every day by your systems and applications, it’s likely that you don’t even know what’s in there and what should be protected from exposure or loss among the massive amounts of data. On top of all this, application logs were not created with these questions and concerns in mind. Platforms that create and host application logs are not set up to protect sensitive information by default.
The reality is that application logs can be an attack or data loss vector if not properly secured with data classification and prevention technologies. Learn why it’s essential to secure sensitive information in your application logs and why cloud-native DLP is the best solution for safeguarding all your data in logs.
What are application logs?
Application logs are the foundation of a modern software development observability stack. Popular application log platforms include Datadog, Splunk, SumoLogic and New Relic. Techopedia defines application logging as “the process of collecting and storing data over a period of time in order to analyze specific trends or record the data-based events/actions of a system, network or IT environment. It enables the tracking of all interactions through which data, files, or applications are stored, accessed, or modified on a storage device or application.”
Once you get into the basic definition of how application logs work, it’s easy to see how sensitive information can get into application logs and how quickly it can spread around systems, leading to possible data leaks. The rest of this article has information on why protecting information in application logs should matter to your org, what’s at stake if application logs are left unsecured, and how DLP adds cybersecurity functionality to your application logging platforms.
Protect information in application logs to reduce data sprawl and spray
One question will help define your security risk in regards to your data logging systems: How are you logging data for users? The information you’re using to identify users makes a major difference in what is at risk of exposure or loss within application logs. Sensitive information like names, medical record numbers, or email addresses are commonly found in strings within application logs. At first glance, it’s a good way to keep track of customers. But including that information without a method to secure it can lead to gravely negative security outcomes. Consider this: if a single server can generate thousands of log records a day, and your org is allowing the use of personally identifiable information (PII) to identify customers within application logs, this would expose your org to PII proliferating across any SaaS systems connected to your logging platforms that cannot be controlled manually.
A compelling event, like launching a new app, scaling up your security teams, or reviewing your systems after a recent security incident is the catalyst you need to improve your security posture. Any of these events will likely change something about how your application logs work — implementing new systems, adding people, or just reevaluating what’s currently in place.
What’s really at risk within application logs?
Like any SaaS system, application logs can host a wide variety of sensitive information. We mentioned PII above as one type of information at risk of exposure in application logs. Protected health information (PHI), API keys, secrets & credentials, and any other information that’s used to identify users or files within application logs must be secured.
Here are a few examples of application logs being the catalyst for data breach incidents:
- An unsecured database exposed 85 gigabytes in security logs of major hotel chains in 2019. In this incident, the security logs of hotels including 19 Marriott locations across the U.S., Caribbean, Ireland, and the UK were accessed by security researchers. The logs were hosted on an unsecured server and the researchers were allowed unrestricted access to the security audit logs generated by Wazuh, an open-source intrusion detection system. Information exposed included server API keys and passwords, IP addresses, and cybersecurity policy details, as well as personal data belonging to hotel employees such as their full names and usernames.
- A Thai database leaked 8.3 billion internet records in May 2020. The database contained a combination of DNS query logs and NetFlow logs for Advanced Wireless Network customers, and exposed information within these logs included IP addresses. According to the article, with a single source IP address it's possible to quickly determine the type of devices on a user’s network and the social networks they frequent, like Google, YouTube, Facebook, TikTok — all social media platforms that have their own security issues.
- A live streaming adult site exposed 7 terabytes of private data in March 2020. The incident put 10.88 billion records containing PII at risk. The security team investigating the exposure discovered over 26 million entries with password hashes — with a proportion of hashes belonging to the live streaming site’s users and some from website system resources. Spam and fraud detection logs containing user password information were also exposed.
How can I protect my unsecured application logs?
Unsecured application logs are a risk that your org can’t take. But what can you do about it? There are a few ways to approach this critical aspect of your cybersecurity strategy.
It’s important to remember that no product exists currently to automate data protection in logs, and like we mentioned at the start of this article, application logging systems and platforms are not built to provide this type of security. Limited options means the ideas for protecting information within application logs are also limited:
- Minimizing the parts of your systems that work with sensitive information can help reduce the risk of exposing that data within logs. However, if identifying users or files with information like names, email addresses, and other PII can make things easier for your teams, this option is likely not a good fit.
- Similarly, you can mask data in logs and systems, but this can add more work where it’s not required. Masking data is often a manual setting in platforms and removes the option of transmitting some sensitive data as needed. In this case, brute force blocking isn’t the best option.
- Implementing expiration configuration on cloud based log systems is another option for securing sensitive information. This tactic is based on the idea that expired data is gone, therefore can't be lost. A short-lived data retention policy could be the right fit for your organization's needs.
- If the above options do not work for your teams, try retaining the logs in an archive with tight access control. Data that is harder to get to makes it much harder to lose.
Your strategy here cannot rely on inaction. Human error, lack of resources and bandwidth, and systems that generate tons of data are all working against you in your quest to secure information across the org. Fortunately, there is a way to take on the problem of sensitive information exposure in application logs.
Automate security for application logs with the Nightfall Developer Platform
With the Nightfall Developer Platform, you can protect sensitive information in all your application log platforms. Nightfall is the first and only data protection platform that can integrate with any SaaS system to detect and classify information like PII, PHI, secrets & credentials, and more — all in real time. Our machine-learning based detectors can be applied to any application logging environment via our APIs. You can create custom regexes to detect where the sensitive data is within your logs and set up automated rules to get alerts before information is exposed.
For more information about the Nightfall Developer Platform and to see a demo, click on the Calendly below to schedule a call with our team.