Last updated at Thu, 11 Jan 2018 15:44:23 GMT

Security products are often purchased to either mark a compliance checkbox, have the newest, shiniest tool on the market, or because of a great vendor pitch, but those reasons don’t support a strategic approach to security posture.

With so many technologies out there today, we put together a simple and straightforward framework you can use to make signal out of noise and select the technology that fits your unique needs.

1. Hire People First

A big misstep that many organizations make is picking out security technologies before hiring people who can operate them. Not only are security personnel best fit to evaluate these tools, they are the ones who can then ensure they’re implemented, maintained, and effective.

2. Put Technology Into Strategic Context

“Technology-first” initiatives rarely work.  Rather than saying, “we need product X”, approach technology acquisitions from a strategic perspective by developing a clear hypothesis about where you think the technology can help.  Generally, you are looking to supplement people and processes with technologies that can:

  • Decrease risk
  • Improve efficiency
  • Enhance visibility

A strategic hypothesis should look similar to this:

“Our business has a huge problem with ransomware. We think that by implementing endpoint threat detection technologies, we can improve visibility and prevent future ransomware attacks.”

Not this:

"We should buy an advanced endpoint threat detection solution.”

3. Identify Your Goals and ROI Measurement

Next, lay out what you are looking to achieve by implementing a technology and how progress toward those goals will be measured.  These goals should be specific and have a clear, measurable ROI.  For example, a goal could be to reduce risk across  your cloud environment with success measured by the percentage reduction in intrusions since the time of deployment.

(P.S. We have a guide on calculating the )

4. Weigh the Pros and Cons of Build vs. Buy

Put everything on the table. Not only should you be evaluating several vendors, but consider what it would look like if you built the solution in-house. Here are some things to consider:

  • Don’t build in-house unless you have plenty of resources and budget
  • Don’t reinvent the wheel if something’s already out there for cheaper
  • Understand the scale and customization limitations of a COTS (commercial off-the-shelf) solution
  • Talk to others in your industry about what worked for them

Usually, building ends up being more costly and time-intensive than buying, but never write it off from the get-go; sometimes organizations truly do need the flexibility of their own custom implementations. If you choose to buy, weigh the pros and cons of each solution, including the costs, time to deploy, integration capabilities, and other criteria specific to your organization.

5. Understand How Security Tools Will Work With Existing Tools and Infrastructure

All security teams operate under the constraints of existing network and organizational infrastructure.  Often security teams must deal with legacy enterprise network environments, old operating systems, or enterprise software deployments.

For example: it’s unrealistic to expect that your organization will be able to change a lot of their infrastructure simply because the security tool you are considering implementing operates best in a cloud environment, so make sure that the technology choices complement your existing tools and work well under your constraints.

6. Understand All the Costs

Costs don’t stop at the price tag of a solution. Consider what it will cost you in time and resources to both deploy and regularly maintain it. If it requires a week of engineering time to deploy, and a few hours a month to maintain, it’s important to factor those costs into your final decision.

7. Design a Realistic and Relevant Proof of Concept to Evaluate Solutions

As you narrow in on solutions, you should design  a realistic, but smaller scale proof of concept (POC) to evaluate whether or not the technology really will be able to address the goals you have identified. A POC should:

  • Have clear, objective, and measurable goals to determine success

    • Example: Increase threat detection accuracy by 100% while reducing response time by 50%

  • Be time-bound to determine if it can deliver on these goals in a realistic timeframe

    • Example: The above goal should be met or exceeded in three months.

The goal of the POC phase is to come out with a final decision. It’s realistic to do a few of these to be sure you find the best-fit solution.

8. Create a Deployment and Management Plan

Once you make a decision based on the success of your POC, it’s time to get tactical:

  • What does the deployment process look like?
  • Who needs to be involved?
  • What is the timeframe?

Having this planned out in advance goes a long way in ensuring a successful implementation. Then, lay out what needs to be done on an ongoing basis to ensure the tool is continuously fine-tuned to your organization’s evolving needs. Who is responsible for managing it, how often do rules need to be reconfigured, and so on.

Using this framework, you can more efficiently and strategically find the right security tool suited to protect your data, systems, and customers—and even meet compliance requirements.

Ready to learn more? We've got a cybersecurity starter bundle that includes 3 eBooks on how to approach people, processes, and technology in your security organization. Grab a free copy here.