Three reasons why IPS and WAF won’t converge anytime soon

Continuing on the IPS vs WAF theme, one might consider the notion that WAF will just converge with IPS. I wanted to point out three reasons why I think this will NOT happen anytime soon. The reasons center around demand, performance, and implications, and feed into each other.

It’s akin to Chris Rock’s joke about driving a car with your feet: You can drive your car with your feet if you want to, that don’t make it a good __ idea!

1) The key reason why we won’t see IPS and WAF converge anytime soon is the associated performance implications and potential to decrease IPS security protection.

Typical IPS deployments are inline, which makes the IPS’ performance critical in order to avoid network delays. Take for instance an IPS that is ASIC-based with Deep Packet Inspection, performing inspection at wire-speed across multiple interfaces.

For an IPS, the filtering and packet inspection happens in memory through packet disassembly and analysis as the packets come through. Each packet related to a stream is tagged and the IPS compares the stream to its signatures, using the usual statistical mojo employed on these devices. The IPS is doing this for all TCP and UDP packets. Once the stream is analyzed it is discarded, most IPS perform this assembly & inspection task in parallel with multiple packets and streams.

For the IPS to work as a WAF, it now has to do extra work for the web-based streams. The IPS will now have to parse the stream, decrypt the SSL (which is another conversation entirely), normalize the HTTP portion, and process the elements inside looking for the usual battery of web threats. This also has to be done for the corresponding web server HTTP response data coming back. The IPS would then need to apply some method of learning to this traffic and reference it for future use. This entire sequence has to happen for ALL the web application traffic in parallel, without impacting all the OTHER protection the IPS is providing.

2) No market drivers: customers aren’t asking for it and no product evaluation is scoring for it!

Independent lab testing criteria is a good metric of (a) what customers are looking for in a technology, (b) broad index of what to look for during product selection, and (c) how products in a technology segment perform. I found it interesting and relevant to note that the NSS Labs criteria, and this is true of ICSA Labs as well, does not include SSL decryption as a requirement or even optional evaluation criteria. Gartner isn’t looking for it in their IPS Magic Quadrant. No SSL decryption would limit a WAF. In addition, the criteria isn’t geared toward application footprinting or analysis.

If product evaluation criteria and market forces aren’t calling for or driving toward integration, no vendor is going to develop a product that combines the two. No vendor wants their IPS product to score a 17% effectiveness in lab testing. If you applied the ICSA Lab’s WAF criteria to any IPS on the market, I dare say none would pass.

3) Typical WAF configuration lends itself to producing a much higher volume of events/detects than an IPS!

An IPS performing WAF duties would likely not provide identical coverage of a dedicated WAF, so there would be even more events / detects generated with the IPS because the vendor is going to ensure their solution identifies as many threats as possible. Each event has to be stored and likely alerted to another system. Alerting is not a trivial task on any platform and web session event data is more resource intensive to store and forward than a typical IPS network event.

For anyone who hasn’t managed or monitored a WAF deployed in a high traffic environment or even a custom web application environment, let’s just say that the Positive Security model of a WAF is very chatty. The log and alert data contain the HTTP elements relevant to the event/detect, like HTML form elements, HTTP method, URL, Response Code, etc. After all, just like an IPS, on a WAF we typically block what we know is bad and alert on anything we aren’t 100% sure about for further analysis by a human.

Wrap-up
The overhead associated with the inspecting web sessions and processing the resulting event volume is enough to tax most dedicated WAF hardware, but to implement this same amount of workload on an IPS that is having to work at wire-speed, protecting ALL network traffic, is likely to degrade the IPS performance and jeopardize security protection.

What are your thoughts?

WAF vs IPS (or Four Things Your IPS Can’t Do)

I see this often and I am always amused at the topic. I have worked with IDS/IPS for 8 years, so I know IPS when it was just a flavor of IDS that no one wanted to enable for fear of blocking access to users and customers. I chuckle at the thought of WAF being a glorified IPS. My how times have changed.
Here are four things that your WAF can do that your IPS can’t. I tried to keep this vendor agnostic.

Please feel free to pile on or comment, just no flames please!

WAF vs IPS?
Web Application Firewalls, as the name implies, work with web applications almost exclusively. Most WAF are often not best-of-breed traditional firewalls, and should not be implemented in place of a traditional network firewall. Typical WAF deployments feature SSL decryption of web application traffic and blocking of web-based threats after the WAF reassembles each web session. This is possible because the WAF operates at the application layer where HTML, XML, Cookies, Javascript, ActiveX, Client requests, and Server responses live.

Intrusion Prevention Systems, as the name implies, inspect packets in an attempt to prevent attacks and therefore intrusions. IPS, which evolved from Intrusion Detection Systems, are packet inspection systems that analyze traffic for signatures or policy violations. These all-purpose devices typically do not decrypt encrypted traffic but instead apply a predefined policy or signature set across all network traffic presented to the IPS.

Four Key Differences
As packets are inspected by an IPS, they are often discarded to improve performance. This is a key differentiator, because a WAF must retain packets in order to keep the context of a client web request and the subsequent server response. Thus you could say that IPS’s deal with packets, while WAF’s work within sessions.

WAFs must understand not just protocol behavior, like HTTP GET, POST, HEAD, etc, but also JavaScript, SQL, HTML, XML, Cookies, etc. This application layer logic is fundamental to the operation of a WAF but not required for IPS functionality, and therefore not typically implemented on an IPS.

Baselining is available on IPS and WAF, but the similarity stops with the name. IPS baselining consists of statistical deviations in throughput and traffic flows. WAF baselining involves URL, Parameter, HTTP Method, Session, and Cookie mapping. A WAF knows no concept of bandwidth utilization for baselining, just an IPS doesn’t know if a given URL is supposed to accept HTTP POSTs or GETs.

IPS signatures are looked at by companies as a means to virtually patch their PC’s ahead of an actual being patch or update being available or fully rolled out. This level of protection isn’t available on an IPS when specific application-layer vulnerabilities exist or when custom written web-application code has some new vulnerability. This is where the WAF provides a measure of protection not available on an IPS, due to the application-awareness of the WAF.

Wrap Up
WAF deployments are focused on web applications and web application traffic, while IPS deployments are typically done at the network level inspecting all packets. I’ll grant you that there are Host-based protections are blur the lines of IPS and WAF, but these don’t qualify as IPS or WAF and probably won’t be living in large multi-OS datacenters or deployed across the tiers of your n-tiered applications.

These are complimentary technologies, just as traditional firewalls and IPS compliment one-another. See Akamai announcement of new WAF service that compliments existing IPS features.

Thoughts?

CCNP Wireless – Not for the Faint

I recently had the privilege of reviewing some CCNP Wireless material. Although my CCNA expired a long time ago, I’ve worked with a lot of CCNP’s, CCIE’s, and Cisco gear (including wireless) over the years. I expected the material and content to be similar to other Cisco material I’ve read/studied. I have a CCNP Study Course sitting on my desk, if I can ever get to it.

Anyway, after reviewing the syllabus for CCNP Wireless, I can honestly say that you’re a Cisco Wireless Guru if you can pass all four of the exams without doing at least one cram course or buying the soon-to-be on-the-market Study Guides. You’ll need some strong experience and a good instructor to tackle this beast.

On a side note: I will say that from a security and manageability perspective, Cisco Wireless Solutions are hands-down the most secure, total solution I have seen.

For the CCNP Wireless, you’ll need to know about cool things like Cisco Mobility and a variety of acronyms like: WLAN, WLC, WCS,WDS, MSE, MAP, RAP, MAR, MFP, LWAPP, RMM, EIRP (no G), NMSP (and SNMP), and LOCP.

There is definitely some cool technology at work in the Cisco Wireless Solutions that allow RFID tags to be tracked, mobile routers to appear as wireless clients, a myriad of security features, and multicasting over wireless networks. Of course, you’ll be questioned on all the cool stuff too!

Actually, the high-end features of the Cisco Mobility Solution are what makeup a lion’s share of the certification. If you read through the focus areas for the exams, you’ll see: WCS Navigator, Mobility Groups, Mesh Applications, VoWLAN, Chokepoints, WCS Mapping, CCX Versioning, Radio Roles, and various QoS options/settings.

Luckily, CCNP Wireless is broken down into 4 parts: implementing Mobility services, implementing wireless voice networks, conducting site surveys, and implementing wireless security.

The Configuration Guides and Design Guides for the Controllers and the various WLAN Solutions will be very helpful along with some virtual lab time, unless you’re building an actual lab or attending the Cisco courses. I’d still recommend some practice questions and a review of the Cisco guides.

Good luck!!

Five Classic Web Attacks

While reading through my blog inbox and writing up my 2010 Wishlist for work, I thought I’d drop a quick post to highlight five web security ‘problem areas’ that still exist after at least a decade of patches, pleas, and regulatory requirements. I often find myself explaining what these are and providing examples, in order to gather support for remediation.

SQL Injection:
The most common attack against web sites! Our data is stored in databases, massive databases in most cases. In order for nearly all online web applications to function, they must be tied to a database somewhere. This is true when you access your bank statement, access iTunes, read the news at MSN, or even google something.
Databases use a standard language for developers and users alike to enter and retrieve data, this is the structured query language (SQL). If a web application doesn’t validate the information being put into those queries, then someone can enter or retrieve as much information as they like about anything in those databases!

Hack the Web Server!:
The granddaddy of them all! Most servers are vulnerable to some list of attacks, either directly or indirectly. When a 3rd party is able to takeover a server and compromise it, they are able to upload malicious software and act as if they are directly connected to the server. It becomes possible for massive fraud or identity theft to occur as the server is accessed or updated.

Cross Site Scripting:
We trust the sites we visit and yet Cross Site Scripting takes advantage of that trust in order to trick a victim into revealing their sensitive information. If you’ve ever seen phishing or pharming attacks you’ve seen Cross Site Scripting (XSS).
When a web site doesn’t validate the information it accepts, it becomes possible for someone to enter programming code into fields instead of usernames, passwords, or email addresses. The user sees a normal looking link or URL for a site, but that link is laced with programatic code that can steal their sensitive information without even being noticed.

Cookie Tampering:
Cookies are special files stored for use by a web browser that typically contain an identity, an access level, or even account information. Although the cookies are stored on end-user (customer) web browser, attackers have become very adept at harvesting cookie contents.

Session Hijacking:
Web applications track each connection with an end-user as a session, using Session ID’s that are usually just a long string of characters. Sometimes these ID’s aren’t long enough to avoid duplication or aren’t random enough to avoid being guessed.
When a SessionID is discovered, it allows a 3rd party to assume the identity of the end-user. In most cases, this happens without notice by the end-user or the web application. The 3rd party is able to conduct transactions as though they were the actual end-user.

What other threats or attacks are you dealing with?

Your INNER WAF

I wanted to cover some WAF topics I haven’t seen covered much. Most WAF vendors talk about the security their product provides in terms of blocking attacks. I would like to delve into these WAF Blockings as well as mention some ideas for alternative uses for your WAF through it’s interactions with web clients.

Web Application Firewalls are interesting bits of technology. Depending on the product and deployment method you chose, they can transparently protect your web infrastructure using various protections by generating blocks when threats are identified. Depending on the product, they can Vulcan mind meld with your Apache instance, live as another F5 device in your network, take over a slotin your XBeam, or live life as a network appliance inside your datacenters.

This intelligent device COULD interact with the client in additional ways outside generating BLOCKs. For example: developers could leverage a WAF to provide additional protections, send notices to connect clients under specific conditions, or even prompt a client for confirmation before performing a specific function if certain criteria are met. After all the BLOCK a WAF generates doesn’t have to be a BLOCK at all, at least not in the context of traditional firewalls or even active-response IPS devices.

If WAF interaction with the client is a concern because you’re trying to keep your WAF invisible to the bad guys, you should know that that’s not a realistic expectation.

WAF’s block threats to your web applications identified through various security methods, but what does that mean?

There are a few options, largely dependent on the vendor and deployment method (transparent bridge, proxy, router, offline sniffing): TCP Reset, Request/Response DROP, out of band Reset via 3rd party. There’s no hard-fast requirement to only use a TCP Reset that’s sent to client and server, like IPS or active-response causing the TCP session/connection to be terminated, but this is controlled by deployment method.
The DROP method is like a virtual trapdoor inside the WAF where malicious traffic falls into a dark pit, never to be seen again.

Some WAF products can send a web coded response back to the web user inside their active session indicating their request could not be completed, some WAF can be configured to quarantine an IP Address or terminate a web session, in addition to dropping the client request or server response. The use of WAF generated error pages to interrupt and/or stop the web session alongside Request/Response dropping is more graceful than TCP Reset. Depending on your environment, TCP Resetting could create unexpected results on your web servers and typically this requires your WAF to be operating in Proxy mode.

In traditional transparent WAF deployments, these BLOCKs generated by a WAF are typically nothing more than a standard error page or a redirect to a logout sequence coded within the web application being protected.  Some WAF’s allow you to customize the page, insert scripting, and push it seamlessly to the end-user inside the existing SSL session. Alternatively, the client could be redirected to a destination within the protected application to log out their session, collect additional information, or open a support ticket (although the last one of those I saw, was more for looks than functionality).

If the WAF can generate web pages in response to client interactions inside an existing SSL session, the client would be interacting with the WAF. The Imperva Application Defence Center (ADC) has an interesting web fraud paper on enabling clients to interact with what I would describe as a security control panel, to help with CRSF/XRSF attacks and web fraud. I have played around with this a little and found some interesting uses – sorry saving that info for my next contracting gig!

The idea of using policies to trigger BLOCKs takes on a new meaning, if the WAF can be leveraged to a generate unique or controlled web pages when a specific policy is triggered or even redirect a user to a specific function inside an application if certain criteria are met, before continuing on inside an application. Don’t get me wrong, TCP Resets are good too – but this path offers much more robust options for a company from multiple perspectives.

Now the WAF can be used to not only BLOCK pure security-centric threats but also control the application behavior and client interaction if something fraudulent, abusive, or irregular is detected. For example you could leverage the behavior deviation capabilities of your WAF (profile violations) and construct a temporary input validation error handling process inside your WAF while your coders developed the handling inside the application. This would be a straight forward use of the acquired knowledge of the WAF, a simple error page containing the prohibited characters, and a method for the client to have a “do over” on the prior page.

Once again, the WAF is providing additional capabilities that an IDS/IPS cannot!

Top 4 WAF Protections

The traditional network security approach to securing your web servers and database servers is more than likely going to get you in trouble some day. Think about it. Network Security preaches deny everything and permit only what you need. Great, open up port 443 and send encrypted traffic to your web server. KaBOOM gotcha!

Think about your Web Application Firewall and the reasons for your investment in web application security.
Regardless of the technology you have selected, here are four protections your WAF investment needs to be providing:

#1 Enforce decryptable web communications.
This might seem counter-intuitive but first and foremost, if your WAF can’t see it – then the WAF can’t intelligently PROTECT your assets! You need to disable any encryption not supportedby your WAF. It’s a long-standing double-edge sword securing web communications but still being able to inspect the communications. No more pre-shared or temporary key SSL sessions, sorry Diffe-Hellman, most WAF’s only support pure RSA. In addition, this is a good time to make sure your servers negotiate at a respectable bit length.

#2 Enable Correlation.
Attack signatures are great, but correlation is better. If your WAF doesn’t offer some form of correlation of multiple signatures and security events before triggering an alert, you might consider picking one up that does. Web Intelligence is a good product, but it’s not an F5, Breach, or Imperva WAF, and that difference could cost you.

#3 Serve & Protect, becomes Learn & Protect.
The best offense is a good defense. If your WAF knows what the application it’s protecting looks like or even better, how it behaves, then the application’s very own structure, coding, and URL/parameter make-up becomes it’s shield against malicious attacks. You don’t need to wait for a signature to protect your web application from new SQL Injection or XSS or Fuzzing attacks, if the WAF is stopping anything that doesn’t conform to expected behavior!

#4 Assess THEN Customize.
When you build a new house, you might expect to have certain things done specific to your requirements before you ever set foot inside the house but you’ve at least looked at the blueprints and seen sketches of the final product. For a WAF guarding a Web Application, custom rules really should be the last thing you do, and ideally AFTER you validate existing protections aren’t enough through penetration testing or code scanning. The major WAF vendors support the inclusion of vulnerability assessments in their products for custom policy creation.

Obviously enabling any of these are subject to your risk exposure / tolerance, but I wouldn’t advocate running for any length of time without these protections regardless of the organization or the other protections you may in place to guard your web applications.

Consider what every online entity is up against, there is more money to be made hacking your protected assets by nefarious (hopefully external) sources than you have resources or funding – short of government entities. If that wasn’t bad enough there are newly coded applications and updates released every minute than there are security fixes going in. If you’re not fully leveraging what you have and not securing as you go, then your company is leaving something undone for the bad guys to come along and exploit.

How is your WAF being used? Is it being used? Need help getting more out of your WAF?

Imperva Placeholders

I had an email asking what placeholders I usefor logging platform integration. Rather than reply in a comment or email, I thought I’d just make a post out of the response.

Looking at placeholders, here are some of the ones I use the most:

• ${Alert.dn}  this is the alert id
• ${Alert.createTime} this is the time the ALERT was created (note this can be misleading)
• ${Alert.description} this is bound to the alert, so you may see “Distributed” or “Multiple” appended due to aggregation of events
• ${Event.dn} this is the event (violation) id
• ${Event.createTime} this is the time the EVENT was created (this is when the event happened}
• ${Event.struct.user.user} this is the username from a web or database action
• ${Event.sourceInfo.sourceIP}
• ${Event.sourceInfo.sourcePort}
• ${Event.sourceInfo.ipProtocol}
• ${Event.destInfo.serverIP}
• ${Event.destInfo.serverPort}
• ${Event.struct.networkDirection} which way is the traffic flowing that triggered the event?
• ${Rule.parent.displayName} this is the name of the Policy that was triggered

There are other placeholders you can leverage, but these are the core I start with. I like these because they’re used on the web gateway AND the database gateway. This lets me have a consistent intelligence feed to my log monitoring platform and my SIEM product.

The trick here is that I can see how may events roll up underneath a single Alert. In the syslog feed, I can track the duration of an attack as well as tell you when I last saw the activity, because I track Alert.createTime and Event.createTime.

There are lots of options for how you build your syslog feed:

• You may be interested in the response time of the query or web page
• Perhaps the response size is of concern to you
• You may treat threats differently depending on where they occur in a database table or URL
• You may be interested in the SOAP action or request

Last but not least, in addition to security events you can also push system level events in the same manner using different placeholders.

• Configuration events can be syslog’d on complete with the user making the change
• Gateway disconnect messages can be sent via syslog (snmp might be better, but you need to load the custom OIDs)
• Excessive CPU or traffic levels can be sent via syslog

How are you using placeholders?

Imperva: Alerts and Events

I received some emails overnight on the Imperva DIY Syslog posting asking when to use the alert placeholders versus the event placeholders.

For anyone not familiar with the Imperva SecureSphere platform, the system has a handy feature that provides aggregation of events on the SecureSphere management server detected by the gateways. This works whether you’re using the web or database gateways but for today I want to focus on the relationship between the data coming from the gateways and the aggregated data on the manager,  I’ll let ImperViews get into the other details - you can read more in the Imperva documentation.

The first thing you have to take note of is the Imperva hierarchy for violations/events and alerts. When the Imperva detects a condition that meets the criteria of a policy, whether that’s correlation, signature, profile, custom, etc., a violation is triggered on the gateway and fed to the management server. Everything in the management server for reporting and monitoring builds off this violation/event detail from the gateway, the gateway is where the enforcement and detection takes place so that should make sense. This is how we know the gateway is taking action on our behalf!

Assuming you haven’t disabled aggregation on the SecureSphere settings, each violation is aggregated into an alert. There are several criteria that the management server uses when aggregating a violation, so you’ll want to check the documentation for your version. The basic idea is that the SecureSphere manager will aggregate similar violations against a server group, an IP Address, a URL, a policy, or some combination of thereof in a 12 hour window. An alert in SecureSphere will have at least one violation/event tied to it, but depending on your aggregation settings it may have more.

So???

So! When you push security events to an external log monitor, you have to decide if you just want the initial Alert information or if you want each violation that occurs! If you build the Action Interface using ALERT Placeholders you’ll only get the Alert data with no additional details in the underlying violation/event stream. This could be problematic, if you’re trying to figure out if something is still going on because remember the SecureSphere aggregates violations under a single Alert for up to 12 hours!

In addition to using the correct placeholders, you also have to enable the “Run on every event” checkbox in the Action Interface/Action Set.

I tend to mix the Alert and Event placeholders so that I get relevant Event details wrapped in the Alert context. I see no reason to make my logging solution work extra hard to establish the same correlation of the Events into Alerts that SecureSphere does automatically.

How do you manage your SecureSphere alerts and events?

Imperva’s DIY syslog format

I have had the fortune to support a few WAF installations, my preference is Imperva’s WAF solution. For any security product, being able to know what it’s doing and what is going on within the product is as important as the actual security being provided.

One of the features of Imperva’s solution that I find tremendously useful in an enterprise setting, and possibly an MSSP as well,  is the ability to construct custom syslog formats for triggered alerts and system events in almost any format. I like to think of this as a Do-It-Yourself syslog formatter because the feed can be built and sent anywhere, using any number of options. More importantly, the feed can be bundled with specific policies or event types to provide limitless notification possibilities that often require professional services engagements to develop and implement.

In Imperva terminology, any policy or event can be configured to trigger an “Action Set” containing specific format options for among other things syslog messaging. If your logging platform (PLA) or SIEM requires a specific format, there’s a very strong chance that, with no more effort than building a policy, you can build the ${AlertXXX} or ${EventXXX} constructs necessary for your needs.

You can model the alerts to look like the Cisco PIX format, ARCSight’s CEF format can be used, or you can make your own as I’ve done in this screenshot:

Basic Syslog Alert Format

In addition to allowing customized messaging format, Imperva’s SecureSphere platform allows unique message formats and destinations to be specified at the policy and event level. For example, a “Gateway Disconnect” or ” throughput of gateway IMPERVA-01 is 995 Mbps” message can be sent to the NOC’s syslog server for response, while XSS or SQL Injection policies can be directed to a SOC or MSSP for evaluation. Additionally, the “Action Set” policies can be setup so that the SOC is notified on both of the  messages above as well as security events.

The configuration of the custom logging format is very straightforward, using placeholders to build the desired message format.  The document ”Imperva Integration with ARCSight using Common Event Framework” provides a number of examples, including a walk-through for building a syslog alert for system events, standard firewall violations, as well as custom violations. The guide is directed at the integration with ARCSight.

Depending on the version of Imperva SecureSphereyou are running / evaluating, the alert aggregation behavior will differ. Newer versions (6.0.6+) better support SIEM platforms with updated alert details, where older versions push syslog events on the initial event only.

You can request a copy of Imperva Integration with ARCSight using Common Event Framework to get additional ideas on customizing your syslog feeds for your SIEM product.

Getting more from your WAF (Sensitive URL Tracking)

I have had the fortune to support a few Imperva installations, alongside other WAF solutions. I would like to illustrate one use for logs available on the Impervaplatform that can be leveraged to augment website trend reports and monitor “exposure” on key URL’s.

If you’re not familiar with the Imperva platform, it is possible (as with other WAF vendor’s products) to build custom policies that must match specific criteria and upon triggering these events can feed data into various syslog feeds. The entire purpose of a WAF is to protect your web application from threats, although some argue this point, so it stands to reason there may be facets of a given web application that are more sensitive than others.

Take for example the check-out page for an online retailer where the customer enters credit card data and confirms their billing information. This location of a web application might benefit from heightened logging under certain conditions by a Web Application Firewall, such as: forced browsing, parameter tampering, XSS, Server Errors, etc. The application may be vulnerable to fraud activities, the business may want to keep a tab on who’s accessing these URLs, or there some other risk criteria than can be measured using this approach.

Traditional webserver logs will provide: client information such as user agent info, username, source ip, method, access URL, response time, response size, and response code. The logged data sits in the access log file on the specific web server by default, but this information is for the entire website.

The Imperva SecureSphere can provide some of the same information: username, IP, Port, user-agent info, accessed URL, response size, response time, etc – but in addition, the Imperva can track whether the session was authenticated, correlated database query (if you have Imperva database protection deployed), SOAP information, security details relevant to the specific policy. The kicker is that this can be sent in a format configured by the admin to a syslog listener in a format supported by web trend tools or SIEM products without engaging professional services.

I’m not advocating the replacement of web server logs for trend analysis, but I am suggesting the deployment of targeted logging for sensitive areas inside an application where this information would prove useful either in a fraud capacity, security monitoring capacity, or even in an end-to-end troubleshooting capacity where a WAF would have visibility beyond traditional network tools from the frontend of a N-tier web application. Deviations in response times, excessive response sizes, and unauthenticated access attempts to sensitive URLs are ideas that come to mind for leveraging the visibility a WAF can bring to the table.