I attended a security conference recently and it was interesting to hear about the various breaches that companies suffered and how failures in their information security programs lead to those breaches. Following the usual round of Monday morning quarterback type of discussions, I could not help but wonder just how much of what I was hearing was wishful thinking as opposed to a solid security service. I have no doubt that each one of the individuals was sincere in their description of how their security program would protect them from the breach du jour. Even so, I could not help but wonder how many of them have actually sat down and analyzed just how thinly they are slicing their resource pies, and more importantly, how many of those wonderful descriptions are, in reality, facades.
Anyone who has worked with me knows that I have managed my way through a number of information security service facades. In fact, my previous blog clearly highlighted a vulnerability management service that could only be described as a facade. We fixed that one particular problem, but in doing so we ended up having to back away from providing other information security services. That is, we had to declare, and get agreement from our executive staff and internal audit, that in addressing this problem we did not have the resources to provide other security services.Such a proclamation seems inconceivable given the risk adverse environment in which we operate. Still, not uncovering and dealing with the limitations in your information security program will ultimately hurt the company you are professing to protect, and prove ruinous to your career.It is a hard admission. Too often we see the broken security program as a personal failure when it is likely nothing of the sort. It is a reflection of limited resources, poorly defined priorities, and broken processes.
Am I Running a Facade?
So how do you know if you are running a security facade? Not an easy question to answer. For me, the approach I elected to take required four things.
- A comprehensive, agreed upon catalog of information security services
- A prioritized listing of information security’s services from most important to least important
- A mapping of how my department’s resources are allocated to the identified services in my catalog
- Communicating the results (i.e. we will provide these services and, equally important, we will NOT provide these other services).
As I noted above, we started down our path of discovery by creating a comprehensive list of information security services. It is important to note that I did not limit the list to just those services I thought we were providing. Rather, I included all the services that we, collectively, believed information security should be providing.
We created the list using a spreadsheet. The resulting list was not in any particular order and once completed, we then began to estimate how many hours per week it would take, on average, to fully deliver that service. We decided to work on a weekly average because staffing is based on a 40 hour week. We discussed each of the services, laying out all the various subcomponents of that service that would need to be provided to declare the service fully delivered and then based our hours estimate on that.
Once completed, we were able to roll up the number of hours we needed in total (again a weekly average) to fully deliver the information security program as defined by our service catalog. The number was big! From the resource side, we began with the observation that we had “X” number of information security professionals and that each of them could contribute 40 hours per week to support the services in the catalog. Well, anyone who has managed a team for any length of time will quickly tell you that the 40 hour estimate is dead wrong. There are a number of hours that the company pays for that are not spent doing actual work. For example, vacation time, team meetings, company meetings, training, and so on. When we subtracted from each person the average number of hours they accrued for vacation, meetings, travel and training, we ended up with a weekly average closer to 35 hours.
When compared the available resource hours to the hours required from our service catalog, a thinking person could only conclude that there were things we were not fully doing. This was our first sign that we may be running a security facade.
Prioritization: Were We Working On What Was Most Important?
With the realization that we were not capable of delivering everything in our service catalog, the question became; “What are we delivering?” and “Are our priorities correct?”
Companies and departments all have stated priorities. In the department I managed, we too had priorities. The problem is that in many cases, the stated priorities are not based in reality. More accurately, priorities are not what you say; they are what you do. Looking at priorities from that perspective, where and how we allocated resources would be the most accurate reflection of our true priorities.
Our first step was to take our catalog of services and order the services from most important to least important. A great deal of discussion went into this exercise as some team members believed one service merited a higher ranking than others. In the end, we reached a consensus and published a prioritized listing of security services.
But did our newly prioritized list accurately reflect our priorities? To fully expose our priorities, we created another column in our spreadsheet and entered in, for each security service, the actual number of hours per week we worked on that particular service. A third column was created next to this which calculated the difference between the estimated number of hours it would take to fully deliver that service and the actual number of hours we allocated to delivering that service. Finally, we added a fifth column and calculated the percentage of that service we actually delivered. With those additional columns, we were able to create multiple views of our services. For example, one view we created by reordering the service catalog based upon percentage complete. The order went from greatest to least. This view showed us what our actual priorities were.
Needless to say, our ideal prioritized list and our actual prioritized list did not agree. Some of our gaps were driven by attempts to address squeaky wheels. Other gaps were generated by our attempts to be check box compliant. Regardless, it was pretty clear that we were sprinkling a few hours here and there in an attempt to appear to be addressing all expectations.
Deconstructing the Facade?
With the light of reality now fully illuminating our facade, we realized that we needed to change. We had agreed earlier that the ideal prioritized listing was where we wanted to be. To move in that direction, we needed to reallocate our resources based upon that prioritization.
We had all the information we needed. We knew what was most important; we had a good estimate of how many hours per week each of the services would require; and we knew, on average, how many hours per week each person on the team could contribute to the effort.
With that information we began to allocate hours beginning at the top of our list and moving down. We allocated the full number of hours each service would require to be fully delivered. As we moved down the list we reached the point where we simply ran out of hours. It was here that we inserted a red line.
Those services that appeared above the red line would be what the company could count on receiving from us and those services that fell below the red line would not be provided.
The “Red Line Document” which is what it became known as, evolved to become a great discussion tool. Internal Audit came with their opinions regarding priorities, as did our CIO. In the end, it was a question of arithmetic. If the executives decided that a service that was below the Red Line needed to be provided, we moved it up. However, absent additional resources, some other service or services would be forced down below the Red Line.
The reality, from a staffing perspective, was that we could not support everything. In the end, those services that fell below the Red Line were business risks that the company now understood and agreed to accept
We would regularly revisit our Red Line document. As you become more efficient at providing a service, you would free up time. New tools that automated some of what was previously a manual effort would, likewise, provide some resource relief. Even growth of staff, contract labor, or outsourcing would change the equations. The good news is that all of those changes were bumped up against our model and were done according to what was most important.
Do gaps still exist in the organization? Of course they do. But now the gaps are known by all the decision makers, and decisions are made based upon knowledge and not upon a facade.