WAF Process Creation for Integration of IT and Business

Question

A client has asked me to help them out with their WAF processes. Currently they have a few critical web applications being protected by a couple of WAFs. I have managed to get the WAFs tuned and ready for production. The company is fairly large and is expanding. Thus, I want to tackle the manageability of their web applications’ security by creating a process which will integrate the IT department of the company with the Business side. At the same time, I am wanting to put together what so far appears to be three different processes I am about to create into just one.

Process 1

Say an XSS attempt is detected and alerted by the WAF: I don’t want the Operational Security to simply go ahead and block the traffic coming from that IP; this decision should fall under the Business’ remit, not OpSec’s. As the WAFs have been implemented not too long ago, I am reluctant to make it block anything it does not like by default. At the moment, they do not have a dedicated database for this purpose, so a spreadsheet Tracker should be created.

A process defining how this is to be done could potentially be as simple as:

 1. Operational Security is notified of an alert against one of their
    assets.
 2. Operational Security immediately checks their Security Information
    Event Management for signs of compromise.
 3. If there is a sign of compromise, an high-priority Security Incident
    is raised and the IP is blocked.
 4. If there is no sign of compromise, the IP is not blocked, but a
    low-priority incident is raised and forwarded onto the service owner
    of the web application being attacked.
 5. Business makes a decision whether this should blocked or not based
    on certain information such as “has this IP been seen before?”
 6. Security Management logs all the activity on their Tracker.

Process 2

Another process needs to be in place for whenever an application is added to their WAFs for protection, or for when an application is removed from the WAF’s protection. This process alone is a straight forward one. Security Management logs all the activity on their Tracker.

Process 3

Finally, a perhaps little more complicated process involves tracking significant changes to an application (such as pages/parameters added/removed) that is already being protected by the WAF. This would impact the WAF’s handling of alerts. So far I thought of something like:

 1. If a project is to change any of the application’s contents, they
    should notify and liaise with Security Management
 2. Security Management sends a Questionnaire for the project to fill in.
 3. Project forwards the filled Questionnaire to Security Management.
 4. Security Management can then tune the WAFs to reflect these changes.
 5. Security Management continues to monitor the application for say,
    one week and if so, the changes are consolidated.
 6. Should any issues occur, Security Management is to liaise with the
    project to address the problem.
 7. Security Management logs all the activity on their Tracker.

Questions:

1. Are those three processes (in)appropriate or am I missing any step/process of the whole thing?
2. Is it really better to have one process addressing all these issues, or should they be kept as three (or more) separate processes?
3. Does anyone ever come across of a Tracker and/or Questionnaire template or have any suggestions on how I should lay them out? So far I thought of having one Tracker workbook plus one Questionnaire with three different tabs each, one for each sub-process.
4. Is there a better way of doing this?
5. Finally, how should be business' grounds for making a decision of whether to block an IP or not?

Answer 1

1.Are those three processes (in)appropriate or am I missing any step/process of the whole thing?

Do you have a need to inspect SSL encrypted traffic? Depending on where your WAF is positioned in your network, you may need a process to handle certificate provisioning and renewal with respect to how the WAFviews traffic.

I separate it into these areas:

• Reacting to a potential incident

  • Research/forensics of detected event
  • Response to event
    • Determining correct approach to a true incident - your Process 1
    • Reducing the cases for false positives

• Managing Change

  • new apps
  • big changes to old apps
  • small changes to old apps

• Managing overall health

  • troubleshooting
  • upgrades
  • business continuity

2.Is it really better to have one process addressing all these issues, or should they be kept as three (or more) separate processes?

This has a lot to do with how you typically document processes. As someone who works in simply ENORMOUS infrastructures and organizations, I'm always working within a hierarchy of paperwork, process and documentation - and anything you might provide in such a world, is better when it fits with the existing model. Make it weird and people won't understand it or use it.

For a growing organization that is currently smallish, but hoping to be bigger - my big caveat is that the first breakout should be organization or discipline related, and each process is grouped by the trigger that causes it. So, ideally, you end up with chunks that are isolated as clearly as the people are.

My experience is that operational folks and developers are such different gene pools that they almost count as different species. They may use similar words, but how they approach a single tool, protocol or idea can be radically different. For this reason, my first breakdown would be there:

1 - Ops Guide - available to the operations team, preferably folded into existing processes for things like firewalls.

• what to do when an incident is detected by the WAF

  • known likely cases
  • unknown process (what to do when you don't know where to start)
  • includes handoffs to developers - where do you go to write a bug report for a false positive? What do you do when you need a developer to help you research the issue? etc.

• guidelines for scope of resonsibility

• guidelines for managing risk and when/where to get approval on a risk

2 - WAF Maintenance guide - for which ever team is maintaining this component. WAFs are funny - could be your boundary control guys (the firewall gang), could be web server support, could be something else. Depends on the architecture and the organization

3 - Software Deployment & Maintenance - for any server protected by a WAF - how to deploy software to a WAF protected site, how to help debug a WAF incident.

Basically separate process to the extent where you can link them to the places where people working with WAFs or web servers will normally look.

3.Does anyone ever come across of a Tracker and/or Questionnaire template or have any suggestions on how I should lay them out? So far I thought of having one Tracker workbook plus one Questionnaire with three different tabs each, one for each sub-process.

Not that I can share. I use corporate protected formats for most of this.

4.Is there a better way of doing this?

Realize, in addition, that what ever you create here is a living document. It may be an XSS attack today, it may be something different tomorrow. You want to create processes that build a knowledge store, automation where possible, and a way to clearly communicate (both in a crisis and to prevent a crisis).

5.Finally, how should be business' grounds for making a decision of whether to block an IP or not?

WAFs block a lot more than IPs - if you specifically look for IPs, I think you are trying to block individual trees in a forest. For IP blocking, specifically, I'd think that any organization using a WAF is also using a firewall, and IP blocking would be managed in a way consistent with any firewall type process for the same thing.

Risk-wise, across the board - there should ideally be a consistent structure regardless of the nature of the risk - blocking the behavior of known bad attackers, blocking vulnerabilities of known attack profiles, etc. - there should be an entity at a fairly high level whose job is to weigh the risks. The tradeoffs boil down to:

• the risk to security of the overall system and business to leaving the weakness in place (allowing what you are currently allowing)

• the risk to business operations in strengthing defenses - what can't you do when you block the threat?

• the cost to doing it/not doing it

The person making the decision is usually a high level person who can take accountability within the organization. Often it's the ISO - Information Security Officer. But someone who is high up enough to see the business and not just the IT side if it. Chances are that some stuff will boil up into general guidelines - so this person isn't going IP by IP - he's setting out some rules - if the IP attacks are bigger than some metric, definitely block... etc.