IDG Contributor Network: The new definition for threat prediction

In “ Redefining threat prediction ,” I discussed the various ways “prediction” is often misunderstood when discussed as a part of security tools, and three ways security analysts can address these misunderstandings. Now I would like to focus on how security teams can begin mapping this new understanding of security prediction into a practical framework that can be tailored to suit the needs of any organization. First, let’s revisit the concept of prediction.

Seeing the future

Here’s a quick thought exercise for you. Tell me what happens next: one of your business-critical internet facing web servers has a known, critical vulnerability. What happens in the next day, the next week?

Your response to that question is rooted in your experience, knowledge and your business’ mission. Given just a little bit of information, you probably devised questions and answers in your mind. You anticipated lots of things emails, phone calls, you and your team making small and large decisions, meetings - lots of meetings.

This is a silly example, but my point is, we can see the future when our expectations are concrete. The concreteness comes in part from two basic, overly simple, principles: anticipation (of risk or reward) and decisions (based on context).

For the time being, let’s set aside the term ‘prediction’. You already know how to anticipate, let’s build on that understanding to show some practical applications.

Anticipation: visibility and context

How did you anticipate the web server scenario? You had key pieces of knowledge: first, there was a critical vulnerability, and second, it was internet facing. There are lots of words for these two points of knowledge in the security buzzword bingo, however we aren’t building a taxonomy. For our purposes, we’ll call these two points of knowledge, visibility . Visibility into the asset’s configuration.

The purpose of visibility is to enable decision making. Whether these decisions are made by a security operator, who will make the decision of whether something should be a high or low priority alert; or the decision is made by a security leader, who will decide if it’s necessary to notify law enforcement or the legal team; one thing remains the same- good decision making comes partly from your judgment and partly from context. In our scenario, that context is that there is a business-critical web server. Or, the context could be that there are public reports of of that vulnerability being exploited. The more context you have, the higher your confidence in the decision. And the more relevant context you can provide to yours peers and other leaders, the more likely they are to trust and follow your decisions.

Visibility and context are not confined to threat prevention. They are critical in incident response scenarios too. These two together can enable a team to anticipate a threat’s movement in your network or enable an operator to make decisions to make configuration changes, preserve evidence or kick off additional analysis. Some people use the term playbooks to describe the actions an analyst or security leader may take given certain events. It is the lack of visibility and context that makes completing those actions more time consuming.

Setting up for practical prediction

Now let’s map the concepts of anticipation, visibility and context to requirements so that your organization can operate in a predictive way.

Anticipation

Establish an expectation. Recall that anticipation is rooted in desired outcome or expectation. Identify your business priorities. I encourage you to challenge your teams and peers a little on this. It’s not about ‘no breaches’. Or ‘keep me out of the papers’ - those are hopes and wishes. It’s about having meaningful targets such as detect and respond to a mission critical issue in 30 minutes or less.

Visibility

Once you have the agreement on the expectation, you can begin to determine what visibility you need to achieve the objective. So, in our web server example, you’ll want visibility into the network, and you’ll want visibility into the web server itself. You may also want visibility into web applications or authentication services. It’s good to understand what assets the web server can access. With this knowledge, you’ll have a better understanding for what is exposed and what to anticipate.

Context

Recall that context is a decision driver. Just like your senses, context comes from connecting disparate systems together. Developing context requires integration of multiple systems such as business applications or third-party security resources. Ask yourself, given an IP address, how long does it take your team to identify whether it’s a mission critical asset? Or who it belongs to? Or how many people or how much revenue will be impacted if it was pulled offline?

Think back to the web server scenario we started with. Can you identify two or three pieces of visibility or context that were missing? As security continues to move into the spotlight for businesses across the world, analysts and teams have an opportunity to reframe what prediction and security means for their organization. Ensuring every team has an accurate understanding of the strengths, weaknesses and definitions of the vulnerability approach to risk management moves the expectations for a security team’s performance away from the movies and back to reality. Because in the real world, adversaries don’t jump through walls, they use the same terrain as the user. A security team’s job is to know that terrain and use that knowledge to effectively place the majority of their risk mitigation resources in the most valuable (or vulnerable) areas.

This article is published as part of the IDG Contributor Network.Want to Join?