Become a Digital Detective With Application Monitoring
You might already know the benefits of application monitoring: it helps you track performance, shows you where transactional bottlenecks may be, and lets you know when an error rate threshold has been reached. Monitoring goes hand-in-hand with logging, together allowing you both a high-level and detailed view of how your application is being used. An unexpected perk of keeping an eye on your application’s stats is detecting anomalies that could be tied to malicious users. Let’s look at ways that your logging and monitoring setup can work double time for you and help you to catch users with ill-intent.
Know thyself (or, well… thy application)
First, let’s check in: Do you have logging in your application? Where are you sending those logs to? How do you view your application’s performance? What types of alerts do you receive? If you’re uncertain about any of these questions, now’s the time to explore the lay of the land.
If you don’t already have log management and application monitoring setup, there’s no time like the present! I don’t claim to be an expert in this realm, but there are many resources on the web for picking the tools and services that are right for you.
If you’re just starting out, here’s a compilation of helpful tips for setting up logs and log management for your product. If you’re ready to take a deeper dive into log management, the National Institute of Standards and Technology has a publication on Computer Security Log Management that’s packed full of information ranging from definitions, common issues, recommendations for organizational structures to uphold log management responsibilities, and so much more.
Can there ever be too much of a good thing? When it comes to the data stored in your logs, unfortunately, yes! Protected or confidential data may mistakenly be stored in logs, putting your company or users’ information at risk. Data breaches that expose your application’s logs — even just from errors — would leak this information to the attacker. The Open Web Application Security Project (OWASP) has a detailed guide on how to implement logging, and importantly, what data to keep out of it.
To complement your logs, it’s helpful to have insights into how your application performs. If you’d like to see a comparison of different Application Performance Management (APM) software, here’s a breakdown of popular services. Though these tools may come at a cost, some platforms offer free-tier accounts. Your pick can also help you set up alert conditions to inform you when something goes wrong, whether that be from some failing API calls, or errors you intentionally throw to raise alarm for suspicious activity.
Tie requests to users
If something goes wrong, you need to know which user(s) are causing the problem, which is why user authentication is crucial in your application. While network information is useful, like a user’s IP address or the requesting User Agent, there are ways that users can bluff that information to cover up their activity. Requiring users to be logged in and sending valid identifying information with their requests — that cannot easily be duped — can help you prevent the transfer of important data to somebody outside of your platform, and help you associate activity with a user in your logs. If you don’t already have authentication set up, you have several options.
JSON Web Tokens (JWT) are often used to authorize users and protect APIs. Encrypted with a secret, information used to identify a user and their set of permissions can securely be sent to your server with each API call. Check out this resource for more information on JWTs and how you can implement them in your app. It’s important to note that a JWT is too sensitive to be stored in your logs. If there were ever a log data breach, that token could allow an attacker to mimic the user it was originally issued to. Instead, a piece of non-personally identifiable information should be stored, like a UUID, such that only somebody with access to the application’s database would be able to determine the user account it’s associated with.
Authentication and session management don’t have to be homegrown solutions. For example, OAuth is “the industry-standard protocol for authorization” with open source and commercial solutions that abstract away implementation details better left to security experts. Whichever option you choose, ensure that your users are authenticated and authorized to access the data they’re requesting to limit the reach of malicious users, and ensure that you log a safe identifier to associate a user with each record of activity.
Establish error alerting that can lead you to malicious users
Another high-impact preventative is to ensure that your errors are not only caught and logged in your application, but that they are being tracked by your monitoring service with appropriate alerting set. What might seem like a one-off blip in your error analytics could actually be tied to a malicious user fine-tuning their program to your site.
This acts as another friendly reminder to be mindful of what information is sent in your errors and how easily it can be linked back to a specific transaction and user account. It’s great to know when something goes wrong due to user error, but if you have no way of knowing who caused the error, it leaves you with little to no action to take.
Be on the lookout
If you have caught scrapers or other malicious users in the past, you might already know what suspicious behavior looks like on your platform. If not, learning the behavioral patterns for your users in order to detect anomalies will take time. Let each case that arises act as a lesson: document it, consider how widespread this behavior could be, and plan how to either prevent it or address it moving forward.
Some general knowledge about malicious activity can help you know what to look for. Since malicious users may use automated processes, the frequency and volume of requests can be a giveaway that a bot is using your site. Repeated requests — especially erroneous ones — in quick succession could also be a sign of a bot. This article can help you to identify bots on your site and distinguish between the good and the bad. If web scraping is one of your top concerns, here’s a helpful guide that goes in-depth about scraping signals and preventative measures.
Automate for your own sake
It’s great that this information is out there for us to browse, but few have the time to manually pore through logs in search of potentially non-existent anomalies. An investment in automation upfront can help you passively detect suspicious behavior and protect your data in the long run. How you automate this process will be unique to your setup and what you want to monitor. This could be done through services offered in your APM software, or it could be homebrewed scripts that watch for behaviors you have identified as suspicious activity.
Final thoughts
You might not be a professional sleuth after digging around in application logs or metric dashboards, but you are hopefully better equipped to detect anomalies that might otherwise have gone unnoticed. Knowing what to send and exclude from your logs, when to send alerts, and what suspicious activity might look like can all help prepare you in the event of an attack. My hope is that with this information, you can have greater confidence that if or when a user comes along stirring up suspicious activity, you’ll be ready!