We all know technology is neither evil nor good in and of itself. Unless it is a killer robot that has been designed to take out innocent kittens. Hmmm…wait…dogs and small rodents might disagree.
Okay. A new personal record as far as early digressing.
Technology typically allows us to free up time for other things, sometimes good and sometimes bad. For instance, it allows us to communicate openly with one another. On the down side, we can now instantly tell everyone when our soft serve ice cream was a little too soft, and we can then tell everyone that we are upset enough to not feel like communicating again for another 5 whole minutes.
In the Information Technology world, the technology half is often advertised as being able to do a plethora of things for us. Product X will solve all your problems, just sign on the line and don’t whine. If that were true, why is it so difficult to sell technology? The typical answer is that this new thing will take time and focus away from current efforts. It seems that when an IT function acquires new technology there are a couple of factors that come into play:
- It doesn’t quite do everything it was touted as able to during the sales pitch.
- The Return on Investment (ROI) is unclear until actually implemented.
- There is a learning curve for the integration and adoption process.
- The operational use of it can be somewhat daunting.
I recently visited a friend of mine at his company. He is the CISO of a midsize company and resource challenged. Not enough people, and his on-hand talent pool has a wide variance of capabilities. I told him he is unique, just like every other CISO in an organization of his size and in a company on that particular growth curve point.
The interesting thing was the box sitting by the desk. It was a network scanning tool device, one you plug into the infrastructure to scan systems and determine vulnerabilities. When it was sold to him it was the greatest thing available on the market…capable of scanning, baking pies, reporting, tracking trends, washing cars, modifying initial risk factors, emptying trash cans, blah, blah, blah. Truly a wonder only comparable to hoverboards that can start a bonfire for your beach party in two seconds flat.
Back to the scanning appliance…it had been sitting by his desk for about eight months collecting dust while the organization collected billing statements for it. About $150K worth in fact. This was beyond shelfware….this was a malignant piece of deskware that stared at him day in and day out, daring him to touch the box.
So why did this happen? Was it a bad purchase? Was it unsuitable for his purposes? Did it not work correctly?
The answer was relatively simple. None of the above, by the way.
Technology, particularly in the security realm, is supposed to enable, protect, simplify, or provide deeper understanding of what is going on in our networks. Sometimes it does all four at once. Yah, I know….some security products out there don’t even get one out of four right. Anyways, back to them:
Think of things such as log aggregators. Enablers allow you to do something to solve a problem. No, not talking about drug users versus drug sellers. Let’s keep the discussion on IT.
This is relatively easy to understand. Think of a firewall or something else that is essentially putting trash can lids around an asset so if anybody tries to sneak up on it, they will make a lot of noise.
Think single dashboard for managing those firewalls. Or a log filter feeding into a Security Operations Center solution. Something that provides efficiency for your precious security folks, removing manual labor from the equation (as much as possible, anyways).
Some examples of this might include the malware sandbox that pulls in bad stuff and blows it up so you can study the behavior of it. Or the firewall event analyzer that automatically sifts through piles of data to give you the so-what.
I’m sure we could get pretty granular on what things do for us, but sitting here (with no reference of what someone else thinks open in front of me) and thinking about this slice of this particular universe makes me think the four items make sense as far as the ‘what’. Wail away on the rebuttal if you disagree. Sorry about adding a numbered list as a result of this article. As if there aren’t enough. Lately I seem to get inundated with the list thing….a few notable examples being:
- The 41 least intelligent Presidents ever
- 14 foods that will kill you if you even think about them
- 8 ways to improve your goldfish’s short term memory
I was in a meeting with a customer a while back, talking through health information protections, and a very sharp technology guy had been thrown in the mix with me. He could talk bits and bytes a mile a minute, and was somewhat hard to contain during the 4 hour workshop. By ‘somewhat’ I mean ‘impossible’. He would run over any attempt to bring the conversation into a how, only wanting to talk about what was technically available and the neat new ways of doing whatever he thought they needed to do. During a break he even went so far as to poke me about not being able to keep up with him because he was just so darn smart and out in front of it all.
Unfortunately, it was the last time the customer met with us. Fortunately, it was also the last time I worked with that particular cohort and quite frankly miss him so very, very much. Little self-awareness and absolutely no situational awareness resulted in a missed opportunity to help an organization with a real problem. Their precious time was wasted listening to a lot of noise about ‘what’ but they really needed to know ‘how’.
Don’t misunderstand me…grasping concepts and knowing technology is a wonderful thing. I have a couple of degrees in it, and am overwhelmed by everything I do not understand on a technical level. Having folks that can intelligently speak to technology, deploy it, and manage it is essential to my current survival and I stand in awe of them. But there is more to life than the bits and bytes.
Organizations struggle with a simple, core question…if I buy this what do I do next?!?!?
An organization’s security program typically consists of 3 layers. This might be over-simplifying things, and I know, I know. Another list. Anyways, the 3 layers are:
Running the show stuff. Organizational layout. Resource deployment. Budget. Strategy. Business alignment. Things of that nature.
This is what the security organization does for the business or the things it provides. There are literally dozens of them. Think along the lines of incident response, security awareness and education, business advisement, vulnerability management, policies, monitoring. When a business owner asks, “What have you done for me lately?” you should be able to point to this stuff. Proudly, I hope.
This is what enables all of the above. The technical tools we use to provide the business of security to the organization.
So we have requirements that flow downward from the governance layer to the technology layers, and metrics flow upward. From there the fearless security leader provides reporting and visibility into how well the organization performs in relation to the needs of the business. To graphically illustrate my point, here’s the messed up vision in my head:
You bought technology to do something. You need information, or to make things easier, or to enable something, or to simply protect your assets. There was a reason.
If we know why we bought it and what it needs to provide back to us, there is only one small thing left to determine. What is the process for using it?
A customer recently asked for a ‘what do I do now’ for a vulnerability scanning tool they had purchased. You can’t simply plug it in, connect it to the environment, and start running scans. Well…I take that back. Of course you can do that! You can also stand in a soup line somewhere until your resume (hopefully) gets a decent hit.
Even if you simply plug it in and start connecting it to some things within the infrastructure, there is a potential for a few things to happen:
- You bring down slightly volatile systems and interrupt critical business operations.
- You set off all sorts of alerts and alarms, interrupting business operations.
- You raise tons of questions as to what you are doing, disrupting business operations.
- You burden the networks with overloads, bringing down business operations.
Regardless, your boss ends up calling you in for a ‘discussion’. Afterwards, you walk around the organization with a large sign around your neck that reads ‘radioactive’. You and Chernobyl exchange Christmas cards every year.
Technology is somewhat useless without processes to guide not only its use, but also the management of it. The management of it can include things such as:
- Who can use it?
- Who has access to it?
- Who administrates it?
- When it gets updated?
- How are licenses managed?
- Who has responsibility for owning it?
- How is the technology governed and regularly reviewed for effectiveness?
Clearly defining how a technology is managed is extremely critical. First off, it prevents the shelfware issue by assigning ownership for the proper management and use of the asset. Someone, somewhere has been identified as being ‘it’ for having responsibility for the technology.
The next part is a little larger. How to use the tool has to include integration into daily operations, deriving the benefits from it (such as those metrics), and providing the broader business value. The how-to also typically includes integration into other business functions.
For instance, if we were to take a few simple samples from a Security Operations Center (SOC), we would have a technology management facet. This would be focused on maintaining the tools used to feed information into the environment. But the how has to be viewed both from within the SOC operations and externally to the business. In order for us to receive information, the primary technology has to be present to show us what is going on. In the background, the server and networks folks have sensors and collectors in their environments, possibly managing them separately from the SOC watchers. It is all part of management planning and identification of who does what.
The internal SOC operation processes are readily identifiable, with some simpler ones including:
- Ensuring the green lights are lit for everything that is supposed to be connected/functioning.
- Watching any red lines for unusual or reportable activities, such as spikes in a firewall log for login attempts.
- Performing forensics and investigation procedures, to include limits – when to call the big dogs in type of stuff.
- What person is responsible for watching what pieces and what they do when the pieces go to pieces.
The list could go on and on, but you get the idea.
There is another component to this that is equally important. In order for the technology to be effective and useful across the organization, it also has to extend out to other processes and integrate with the broader operational environment if it is to be truly effective. If the technology is not dovetailed into the business operation, it will limit the business value (and visibility) while reducing the effectiveness of it. Consider the following external integrations that could also be done with a SOC implementation:
- Connection to the IT ticket system. If known vulnerabilities are noted as a result of observation, the SOC personnel can initiate the fix using the ticket system workflow generator.
- The workflow generator integrates with the organization’s Systems Development Life Cycle (SDLC) processes.
- Connection to the risk management register for known issues, preventing dropped risk items.
- Automated reporting to business units for their specific systems status.
- Higher law enforcement contact procedures for certain sever incidents. Probably filtered through the CISO for sanity reasons.
And again, the list could go on and on.
This blog is running a little long and I didn’t really want it to. To get to the bottom line, let me say that technology is great, it is wonderful, it is necessary. But it is completely useless without process.
Process provides the business value, the metrics, and the visibility into how the technology performs in solving business issues. Process allows us to tune and refine that technology to ensure it is efficient, effective, and valuable to the operation.
Make sure that when you buy technology you are doing so with a business goal in mid, an idea of how it integrates and fulfills your security strategy, and a clear view of how it will integrate into the security program and broader business from a processes perspective.