Layers of Security: In Defense of the Web Application Layer

Written November 18th, 2015

Post Tags: cybersecurity, Enterprise Threat Management

By Marvin Marin
NetCentrics Technology Program Manager and Cybersecurity Expert

Security Operation Centers (SOCs) are built on the concept of managing and monitoring a bulwark of layered defenses. This works well as long as security personnel are mindful of defending all layers of the Open Systems Interconnection (OSI) stack, not just the first few. (Note: The OSI model is a conceptual model for how applications can communicate over a network, comprised of seven layers: physical, data link, network, transport, session, presentation and application.) When solid processes are in place, SOCs are generally proficient at monitoring, analyzing and responding to events at layers 2, 3 and 4 of the OSI stack – the data link, network and transport layers. When it comes to layer 7, however, they tend to rely too heavily on generic intrusion detection system (IDS), intrusion prevention system (IPS) signatures and “out-of-the-box” configurations. There are several reasons for this:

  • Specific, customized signatures for the organization’s web application(s) are hard to develop and tune, and false positives drive up research times of analysts or desensitize analysts to real threats due to the volume of false positives, as occurred with the Target breach.
  • There is a general lack of understanding of web applications, web security and application firewalls in general, as SOC personnel feel more comfortable with address resolution protocol, datagrams, internet control message protocol, and network sockets. Web security, on the other hand, is focused on SQL injection, cross-site scripting and authentication/session management. This situation is exacerbated by the fact that SOCs do not reach out to subject matter experts on web applications, if they even exist within the organization.
  • Analysts are well-versed (or more easily trained) to sift through data at layers 2, 3 and 4, as this data is fairly consistent across systems; layer 7, on the other hand, does not offer this “universal” consistency and is difficult to train on because so many “what-ifs” exist.

For the application layer, SOC managers tend to be overly dependent on data loss prevention (DLP) technologies and generic IDS signatures, which are not tuned to the specific application – or they assume the application is resilient enough to discard any “malformed” requests. Again, there are multiple reasons for these assumptions:

  • Putting in place a custom signature that “seems to work” may create a false negative condition where the SOC manager will assume that the system will trigger an alarm, but it does not because the signature may be too specific or too generic. With the system not reporting an alarm, the SOC is lulled into a false sense of security.
  • The SOC manager might make an assumption that even if a breach occurs, the DLP system will catch it as it exits the network; this is not always the case, however.
  • The SOC manager may assume that if the website is breached, he/she will see anomalous traffic exiting the network, which he/she can monitor, understand and react to. Yet, again referring to the Target example, one of the most serious retail breaches in history was a result of missed alarms.

So what should SOC operators do? I have one immediate suggestion: SOCs should encourage the use of and assist with the tuning and monitoring of web application firewalls (WAFs) or next generation firewalls (NGFW) to proactively defend the network space. This way, if the application is compromised, a properly configured WAF will notify the SOC, protect the resource and possibly impede data exfiltration.  Additional layers of protection can be added by leveraging source code reviews and web application security assessments through an organization’s governance or assessments section. Routine, scheduled layer 7 security scans via commercial software tools as well as source code reviews and scans via source code analysis tools also will aid in minimizing layer 7 vulnerabilities in the environment. With the majority of attacks to enterprises occurring at the application layer, not deploying a WAF or NGFW is a missed opportunity to decrease the virtual attack surface and provide an additional monitoring data point. In my view, focusing attention on layer 7 is not just a nice-to-do; it’s a must do.