Selecting Security Tools Based on Your Unique Network and Business Challenges

Principal Information Security Engineer
Gigamon

Pop quiz! Which of these sounds familiar?

  1. My security tools create false positives.
  2. My security operations (SecOps) team is overwhelmed by a high volume of security alarms.
  3. I’m not sure my tools are finding any badness.
  4. I feel like I need more tools to cross-check my other tools.

If you said yes to any of these, your current security tools may not fit your vertical industry.

While we may like to think that a “network is a network,” in truth, every network is bespoke – formed from accepted design patterns, business requirements, organic growth and designer preference. Consequently, it’s not feasible to choose security tools with the mindset of, “If I just had this network intrusion detection system (NIDS) and that user behavior analytics (UBA) tool, then I’d be secure for sure.” Why? Because it doesn’t address the unique challenges you need to solve to secure your unique network.

Figure 1: Unrefined data goes to all tools, resulting in poor detection.

Three Key Areas to Minimize Challenges and Maximize Security

My approach to choosing tools and architecting my network to minimize challenges and maximize security starts with three key areas IT staffing and talent, organizational tolerance and need and rate of change of business.

IT Staffing and Talent

With IT staffing and talent, my aim is to understand skillsets and resource contention to see if I can partner with IT to run security tools or if I’ll largely be on my own. Some questions and decisions that are important to consider:

  • Is your IT organization skilled or unskilled?
    If they’re skilled, you might consider more homegrown, OSS-based tools and customer infrastructure that IT can manage. This approach would leave SecOps using tools and it would change the staffing blend. If, however, your IT team is more of a help desk function with only a small number of engineer-level folks, you might need to staff SecOps to build and operate their own security infrastructure, develop their own tools and have the capacity to use those tools.
  • Is your IT organization staffed to take on security?
    Some organizations have large IT teams that can keep up with the change needed when running security infrastructure. If so, you might decide to have IT handle your tool deployment, management and architecture. If not, you might consider having IT largely handle getting you into the network, but with you taking responsibility for the tooling itself.

Organizational Tolerance and Need

In this area, it’s important to ask questions about the level of security risk that’s acceptable to your organization and to determine what needs to happen and what should never happen.

  • What specific industry requirements do you have? What certifications must you adhere to?
    If you’re a public company, a hospital or a juice maker, you’ll have a certain set of requirements that guide your tool selection and operation. If on the other hand, you’re a start-up with only reputation risk, you might choose a completely different path.
  • Are you starting from scratch or have you been in business for 40 years?
    If you’re a startup, have a new office or your old office burned down, you can do things the right way from the start. If your network is 40 years old and there are rumors that someone is still on token ring, you’re largely going to be trying to weave security in and pull apart the cruft.
  • Do you know what is most important to protect?
    If you know what your defensible space should be, you can super-tool around that small percentage that must not burn and you can allow some burning on the edge. For example, do you care most about crypto material, but not at all about employee Bob’s laptop? Answers to these questions can significantly inform your strategy.

Business Change

Finally, how will you weather change? Everyone does this differently. Even if you can’t predict the future, understanding how your IT and overall organization might react to a major change is a great way to inform your current tool selection and give you a glimpse into how you might need to react.

  • What happens if you’re acquired?
    Do you have an asset list today? If not, maybe you need to install some discovery capability onto the network.
  • What happens when there’s an incident?
    Do you know which tool got the data from VLAN13? Are you sure you collected both sides of the flow? There is nothing more depressing in an incident than realizing you didn’t collect the right data and that awesome vendor you need to fly in to help is going to remind you of your folly on the invoice.
  • What if your CISO leaves?
    Have you built a security infrastructure than can easily be explained and demonstrated to incoming leadership? What if the board wants an overview of how the company “does” security? You need to have not only a robust tool set, but a well-organized one. If you provide a network map that looks like a Jackson Pollock piece, you might find that you’re not going to get that new deception tool you want.

Security isn’t easy, and none of us should add to that challenge with a bad security infrastructure. If you start by asking questions related to staffing and resources, risk tolerance and business change, you can begin to hone in on what security tools can best meet your unique network needs.

SHARE