Don't Let Your Security Program Get Hit by a Bus

Some people are tinkerers by nature. Whether it be cars, electronics, or security technology, some people just love to "roll their own". While rolling your own can serve a purpose as a way to meet certain niche operational needs, it does present certain challenges from a business perspective. It is certainly possible that operational needs may exist that necessitate home grown solutions, but it is important to consider a number of factors before going that route:

• Continuity: Continuity of operations is an important part of security operations. Stringing together a variety of home grown solutions may work well in the moment, but what if the one guy who knows how they work and how to use them gets hit by a bus or resigns? What if operational requirements change to beyond what the home grown solution was designed to do? Further, what if there is a prolonged outage that causes a network visibility "blind spot"? It's all fun and games until you can't see what's actually going across your network when you need to.
• Documentation: Documentation is not particularly fun to put together, but it is absolutely critical for effective security operations. Documentation needs to cover all aspects of security operations and incident response, including technologies that support the mission. If a home grown solution is necessary, it also needs to be documented in detail. Unfortunately, this is seldom the case in my experience.
• TCO: Total cost of ownership is another important factor to consider. Labor is a sly, hidden cost that stealthily eats away at the efficiency of an organization. I once sat through a presentation on building a $100 flow sensor. What the presenter strategically omitted from the talk was that it took him six months to build that sensor. With benefits and overhead, that's more like a $150,000 flow sensor. And that's before we include any O&M costs. Not so cheap after all. If scarce analyst resources are spending time tinkering instead of performing incident response, that comes at a large cost to the organization.
• O&M: I've previously blogged about how people often forget to include Operations and Maintenance (O&M) in their costing models. Every technology solution needs to be operated and maintained. It's merely a question of by whom and at what resource level. Solutions that include O&M by others or minimal O&M internally would seem to be the clear winners here.
• Scale: If I can "MacGyver" a solution to a problem in a lab or as a proof-of-concept, great. But what about scaling that out to an enterprise-wide deployment? Probably a bit more difficult and resource intensive of an undertaking.
• Loss of Focus: In security operations and incident response, skilled, qualified resources are incredibly scarce. Shouldn't those resources be focused on security operations and incident response rather than endeavors that distract from that?

Technology solutions cannot meet every operational requirement, but they can meet many. Before rolling your own solution, it is important to consider all of the variables factoring into the decision, including those that may be less tangible or somewhat hidden.