Why are there shelves, sometimes figuratively, sometimes literally, full of projects that money was spent on with little end result? Projects left incomplete, never verified as meeting their intended reasons for purchase?
For example, a logging system in which the logs are too cumbersome, an Intrusion Prevention System that allows attacks in, or a Group Policy that is only half complete. How did these projects get into this state? The typical response is “We didn’t have time to get back to that,” or “We intended to make that more secure”; however, such statements usually end with “ but it never took off.”
The IT department feels like they got sold on a product that is useless. The IT Director wonders why something that came so highly recommended by his own IT people now is getting bad mouthed as worthless. The CFO wonders why the IT department keeps asking for money for projects with little progress to show for them.
How does one fix this? The first step is to define clear, measurable goals for these projects. “Installing a SIEM,” “Configuring an IPS,” or “Implementing a Group Policy” doesn’t count.
Take, for example, a SIEM system. The first step is to outline all of the goals of the project. This might look like the following:
“We want to be alerted when attacks are occurring against the hosts in our DMZ.” There are four servers in our DMZ. These servers are:
- The primary web cluster
- The anti-spam appliance
- The DNS server
- The SIP gateway
After defining business critical applications, in this example the business is focused on providing online services and the web presence is of the utmost importance for both availability and integrity. Take the concern around how much downtime of this service costs the company over a period of time and quantify it. Put that number aside, it will come in handy later. Create a small goal for the most important service, and create a plan to monitor just that application. A sample small goal might be:
“Based on our application flows and the importance placed on our web presence, the goal is to, by Friday, configure notification level alerts to be sent to the System Administrators for security related events from the three servers in the front-end web server cluster, and configure emergency alerts to be sent to the cell phones for both the System Administrators and SQL administrators for any correlated events occurring between the web and SQL server backend.”
Before moving forward, is this goal SMART, or Specific Measurable Attainable Realistic and Time based?
Is this specific? Yes. Is how this will be measured clear? Not yet, let’s define that: If an attacker causes an alert to be sent out, and both departments respond in accordance with our incident response plan, this will be successful. Is this attainable? Yes. Is this realistic? Yes. Time based? Yes.
The next step would be to evaluate the successfulness of this objective. Are the alerts overwhelming or manageable? Did the System Administrators just create a mail filter for these notifications or are they being read? How do you know? The only way is to check.
In this scenario it would make sense to schedule a penetration test, again, to see if the logging is being reacted to as planned, indicating the goal set forth is being met. Once you meet a goal, then it is OK to move along to the next service, but not until then. At this point, there is a small tangible step toward progress. So far everyone probably still is happy.
And if the penetration test isn’t being responded to, that is OK!
Maybe there are too many false positive responses, the application tripping off alerts on expected behavior? If so, it probably can be tuned. Maybe Quality Assurance needs to run through the application to figure out what creates unwarranted alerts. By meeting small goals, no one should be overwhelmed.
By doing things one step at a time, the project can stay alive, and can meet its end objective.
The IT department can show how they reacted well against a third party assessor; the IT Manager can show he is making good decisions on where he is spending his budget; and the CFO can show he is not wasting money on shelved projects.
Remember the cost of downtime? This number can be used to show the CFO the value in completing this project.