In our introductory post we discussed how customers are looking to derive additional value form their SIEM and log management investments by looking at additional data types to climb the stack. Part of the dissatisfaction we hear from customers is the challenge of turning collected data into actionable information for operational efficiency and compliance requirements. This challenge is compounded by the clear focus on application-oriented attacks. For the most part, our detection only pays attention to the network and servers, while the attackers are flying above that. It’s kind of like repeatedly missing the bad guys because they are flying at 45,000 feet, but you cannot get above 20,000 feet. You aren’t looking where the attacks are actually happening, which obviously presents problems. At its core SIEM can fly at 45,000’ and monitor application components looking for attacks, but it will take work to get there. Though given the evolution of the attack space, we don’t believe keeping monitoring focused on infrastructure is an option, even over the middle term.
What kind of application threats are we talking about? It’s not brain surgery and you’ve seen all of these examples before, but they warrant another mention because we continue to miss opportunities to focus on detecting these attacks. For example:
- Email: You click a link in a ‘joke-of-the-day’ email your spouse forwarded, which installs malware on your system, and then tries to infect every machine on your corporate network. A number of devices get compromised and become latent zombies waiting to blast your network and others.
- Databases: Your database vendor offers a new data replication feature to address failover requirements for your financial applications, but it’s installed with public credentials. Any hacker can now replicate your database, without logging in, just by issuing a database command. Total awesomeness!
- Web Browsers: Your marketing team launches a new campaign, but the third party content provider site was hacked. As your customers visit your site, they are unknowingly attacked using cross-site request forgery and then download malware. The customer’s credentials and browsing history leak to Eastern Europe, and fraudulent transactions get submitted from customer machines without their knowledge. Yes, that’s a happy day for your customers and also for you, since you cannot just blame the third party content provider. It’s your problem.
- Web Applications: Your web application development team, in a hurry to launch a new feature on time, fails to validate some incoming parameters. Hackers exploit the database through a common SQL injection vulnerability to add new administrative users, copy sensitive data, and alter database configuration – all through normal SQL queries. By the way, as simple as this attack is, a typical SIEM won’t catch it because all the requests look normal and are authorized. It’s an application failure that causes security failure.
- Ad-hoc applications: The video game your kid installed on your laptop has a keystroke logger that records your activity and periodically sends an encrypted copy to the hackers who bought the exploit. They replay your last session, logging into your corporate VPN remotely to extract files and data under your credentials. So it’s fun when the corporate investigators show up in your office to ask why you sent the formula for your company’s most important product to China.
The power of distributed multi-app systems to deliver services quickly and inexpensively cannot be denied, which means we security folks will not be able to stop the trend – no matter what the risk. But we do have both a capability and responsibility to ensure these services are delivered as securely as possible, and we watch for bad behavior. Many of the events we discussed are not logged by traditional network security tools, and to casual inspection the transactions look legitimate. Logic flaws, architectural flaws, and misused privileges look like normal operation to a router or an IPS. Browser exploits and SQL injection are difficult to detect without understanding the application functionality. More problematic is that damage from these exploits occurs quickly, requiring a shift from after-the-fact forensic analysis to real-time monitoring to give you a chance to interrupt the attack. Yes, we’re really reiterating that application threats are likely to get “under the radar” and past network-level tools.
Customers complain the SIEM techniques they have are too slow to keep up with remote multi-stage attacks, code substitution, etc.; ill-suited to stopping SQL injection, rogue applications, data leakage, etc.; or simply effective against cross-site scripting, hijacked privileges, etc. – we keep hearing that current tools to have no chance against these new attacks. We believe the answer involves broader monitoring capabilities at the application layer, and related technologies. But reality dictates the tools and techniques used for application monitoring do not always fit SIEM architectures. Unfortunately this means some of the existing technologies you may have, and more importantly the way you’ve deployed them – may not fit into this new reality. We believe all organizations need to continue broadening how they monitor their IT resources and incorporate technologies that are designed to look at the application layer, providing detection of application attacks in near real time. But to be clear, adoption is still very early and the tools are largely immature. The following is an an overview of the technologies designed to monitor at the application layer, and these are what we will focus on in this series:
- File Integrity Monitoring: This is real-time verification of applications, libraries, and patches on a given platform. It’s designed to detect replacement of files and executables, code injection, and the introduction of new and unapproved applications.
- Identity Monitoring: Designed to identify users and user activity across multiple applications, or when using generic group or service accounts. Employs a combination of location, credential, activity, and data comparisons to ‘de-anonymize’ user identity.
- Database Monitoring: Designed to detect abnormal operation, statements, or user behavior; including both end users and database administrators. Monitoring systems review database activity for SQL injection, code injection, escalation of privilege, data theft, account hijacking, and misuse.
- Application Monitoring: Protects applications, web applications, and web-based clients from man-in-the-middle attacks, cross site scripting (XSS), cross site request forgery (CSRF), SQL injection, browser hacking, and data leakage. Commonly deployed as an appliance that monitors inbound application traffic.
- User Activity Monitoring: Examination of inbound and outbound user activity, application usage, and data. Commonly applied to email, web browsing, and other user initiated activity; as well as malware detection, botnets, and other types of ad hoc applications operating unbeknownst to the user.
We’ll follow that up with a discussion of the technology considerations for these enhanced monitoring systems, and talk about how to prioritize the collection and analysis of these additional data types, depending upon common use cases/attack scenarios. Each type of monitoring offers specific advantages, and many overlap with each other, so you’ll have lots of options for how to phase in these application monitoring capabilities.
Reader interactions
One Reply to “Monitoring up the Stack: Threats”
Great series, I’m late to the thread and am playing catch up. I’m looking forward to reading the next few posts.
Perhaps it’s my lack of experience with SIEM products, I work in a shop that uses one of the biggies and it seems to me we’re making good use of it. We use it for aggregating logs from devices throughout the enterprise including network gear, servers, workstations, etc. It provides us with hindsight, to see things that have already happened.
It does not give us the ability to interrupt attacks, nor do I think that’s realistic. If a user visits a well-known web site that is hosting malicious advertisements that compromise the user’s system via browser exploits, no SIEM is going to give its users the ability to interrupt that attack.
But if the right tools are in place and feeding data to the SIEM, the compromised host can be detected in relatively short order and remediated and the SIEM can be used to retrace the steps that led to the compromise and that information can be used to prevent further infections given corrective actions.
Perhaps you’re talking about multistage attacks that involve compromising a client at the edge and then pivoting into the rest of the organization, a SIEM, used properly may help interrupt that pivoting.
Personally, I’m looking forward to the day that our SIEM collects information from a WAF sitting in front of our E-Commerce environment. Standard Apache and IIS logging is woefully inadequate and unfortunately the concept of applications providing good security logging is new enough that it hasn’t caught on in developer circles and because it doesn’t generate revenue, I fear it may never go mainstream. A WAF feeding into a SIEM may be as good as many organizations get in terms of visibility into web applications.