Meet Ug. Ug is a caveman who works for Company, Inc. He has been tasked with running the Fire Management Program at his organization. It's a daunting task and Ug knows he's going to need to get some help.
So he's gone to multiple vendors to ask about their technology solutions to help create fire. Rock Corp uses rocks to create sparks to ignite fire. Sticks Unlimited uses friction and heat to accomplish the same thing. After a long process, Ug's company bought the Rock Corp solution.
After a couple of weeks, Ug found that he was good at making sparks and setting things on fire but couldn't get a sustained blaze going to do anything meaningful. He spent a lot of time just putting out the fires he did start. And striking rocks together, as it turned out, required quite a bit of his time. So far he had reached the random, sporadic success phase of his Fire Management Program
So Ug called up FireWorks to see if they could help with striking the rocks together maybe automate his current process or get someone to do it for a couple of weeks. FireWorks asked some basic questions to see how far along his Fire Creation Program had matured. They asked what his intention was with the fires, what his firewood gathering process was, how much he knew about kindling and tender, how he kept his wood dry, etc. But he insisted that he just wanted someone to strike the rocks together eventually he'd get a sustained blaze. So he hired a guy to start fires and one to help put them out. Progress.
We see the same things in Information Security. A lot of companies buy the latest wonder products DLP, NAC, IDS/IPS, IAM without considering that these are tools to use in their program, not the extent of the program. But a lot of times they don't realize this until they've got a failed project or two under their belts. Many organizations never integrate technology with their people and processes. They never get past the random, sporadic success phase in their program, and management ends up accepting it as just par for the course.
At SecureWorks, we run a lot of cases where Clients bring us in to fix a failed implementation of a specific technology, without asking the bigger picture questions. For example, most companies that implement DLP do it by throwing a box on their perimeter and pulling the logs every week. But they don't stop to consider that before you can really know what to look for you have to know what you have, where you have it, how important it is, how it's protected, what are the ingress/egress channels, etc.
It's better to instead ask what problem you're trying to solve, then use a combination of people, process and technology to address that problem. Going back to DLP, most people want to restrict the flow of sensitive information out of their environment. That's the goal. To accomplish that they first need to know what data is sensitive and where it should be stored. And odds are in the process you'll find data in places it was never meant to be portable devices, unencrypted laptops, backup tapes, network shares. If you keep the data in a tightly controlled area it is much easier to protect, and you don't necessarily need that expensive product.
These larger projects, especially, are more likely to fail because the work of asking those big questions is so much more daunting. It is often helpful to precede large projects like this with a strategy project take three to five weeks where you look at the overall strategy, rather than just tactics. Formally set requirements and get tentative buy-in from all key stakeholders. Determine an appropriate budget, milestones, outcomes, deliverables, maintenance, etc. Then, build a business case to present to management and get their formal approval for the project. This way all expectations are set for all parties. We've found that this approach ends up increasing the success rate of projects, shortens the timeline and often drives down the cost of implementation.
And if you need help with this, we can provide it. We have performed several of these strategy projects and can help you with yours. We've even rescued some failing programs by doing this work during the technology implementation phase, rather than before it. Our goal is to help your program become mature and consistent, rather than just setting fires and putting them out.