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.
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.
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.
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.
- Are those three processes (in)appropriate or am I missing any step/process of the whole thing?
- Is it really better to have one process addressing all these issues, or should they be kept as three (or more) separate processes?
- 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.
- Is there a better way of doing this?
- Finally, how should be business' grounds for making a decision of whether to block an IP or not?