Beat hackers with a vulnerability assessment process

Vulnerability risks come in many forms

Risk is commonly defined as the odds that something bad or unpleasant will happen. IT pros' challenge is specifying what form that negative occurrence will take.

Too many organizations end up thinking of risk as if it were a single "thing." In IT, risk is not a monolith. As I just noted above, there are multiple sources of vulnerability. Also, often a single risk in, say, an application, is a multifaceted liability. Failure to recognize multiple points of vulnerability makes it easy for expectations to be misset, and for the application to be deemed unsatisfactory as a result.

Making matters worse is that vulnerability detection and risk management software vendors in the space tend to position their applications as point solutions to their customers' self-described single problems. In these cases, organizations field what they believe to be a surgically-precise combination of policies and technologies that look fabulous in concept, but end up having little practical effect in a vulnerability risk assessment. In this way, it's not unlike dosing a hospital patient with a medicinal cocktail that was formulated to address a diagnosis of "he's sick."

Team approach best for vulnerability risk assessment

Friday, May 13 of this year, was called National Blame Someone Else Day. When it comes to software, system, data and other security breaches, every day seems like that day. Most investigations into "how did this happen?" begin with blame, with someone getting called on the carpet. Too often, who gets blamed has to do with where you appear on the organizational chart.

If you sit at the top, you have the benefit of simply telling folks to get to the bottom of things and appointing a leader of the pack. If not, then you'll have to win the support of a higher-up, as most vulnerability risk assessments have to be crossfunctional, reaching across organizational and technology platform boundaries. Executive say-so is often necessary to encourage cooperation across the board. Either way, the process works best when the culture is one of inclusiveness and collaboration -- something that is not always the case and rarely is within your control.

Three questions that cut risk down to size

There are three sets of questions that a vulnerability risk assessment team has to answer in order to whittle the big issue of risk down to a size and focus it can effectively tackle.

1. What kinds of vulnerabilities present risks?
   1. Breaches from outside the organization?
   2. Breaches from inside the organization?
   3. Reporting and audit irregularities?
   4. Privacy violations?
      
      
2. Where in our overall environment is the weak link in the susceptibility chain?
   1. Our network security?
   2. Our application integration architectures -- especially cloud-involved?
   3. Our authentication or authorization protocols and procedures?
   4. Our data management policies and our enforcement thereof?
   5. All of the above? (Hint: This is almost always the correct answer.)
      
      
3. What cost might we incur if we don't do anything about this weak link?
   1. Will it cost my organization, or me, money?
   2. Will it hamper our ability to achieve our goals?
   3. Will it result in legal exposure?
   4. Will it cause us harmful embarrassment?

These questions must be asked in parallel, because mapping the answers to each other will highlight the areas requiring the most attention. In most cases, the highest-priority risks will be those with the highest associated potential costs -- though there is a case to be made for starting with those that are most readily addressed in order to demonstrate responsiveness. (This can be especially important when the risks relate to court matters or compliance.)

Creating the risk busters team

Now that you have a sense of where you need to focus your energies, you can begin to determine who should be on the initial risk management team. In many cases, the nature of the risks under scrutiny makes this obvious even before the priorities are set -- e.g., vulnerability to a lawsuit means you'll have to include the corporate attorney -- and inviting these people to the table "early" is strongly recommended.

For sure, your list of candidates likely will contain the "usual suspects" when it comes to dealing with information issues:

• Senior executives.
• Compliance manager.
• Legal counsel.
• Records managers.
• IT staff (developers, architects, ops managers and others).
• Plus the person, or his or her department head, most likely to be called on the carpet if there's a failure.

Note that developing a vulnerability assessment process and team depends upon the context of risk and is complicated by the aforementioned multiplicity of concerns with each risk. Risk has less directly to do with information per se than it does with the ways that information is handled. As such, you may have to explore more meta-level issues that require a somewhat higher-level perspective than typical information management does -- e.g., less vocabulary-based and more business process-minded.

In addition, there are two other important roles that most teams need to fill in the vulnerability assessment process:

1. Records managers and IT people should be part of pretty much every team you put together. Records folk because they exist primarily to manage and protect critical business information, and come with a wealth of relevant knowledge and experience, and IT professionals because, well, pretty much everything runs on a computer.
   
   
2. When talking to and about IT, be sure the conversation includes any cloud providers you use. This reason may seem obvious, but you'd be surprised how often it gets overlooked. In these cases, the integrity of your information and infrastructure depends heavily on theirs because you're running your stuff through their system. So they have to be part of the team.

Act like Woodward and Bernstein

With the team assembled, the meat of the work can now begin. At the core, this process looks a lot like investigative journalism, in that the team is searching for evidence of a weakening or rupture of the informational pipeline.

Among the resources that can be invaluable here are the following:

• Email senders, receivers and attachments: Are all secure enough to be involved?
• System timestamps: log-ins and outs, files accessed, perimeter attacks.
• Noncompliance notices: from regulators, auditors and others.
• Web mentions of unauthorized material: public exposure of what' supposed to be private content.

A vulnerability assessment process inquiry should encompass both the people and the documents that are moving within and without your system, the first to ensure only those with proper authority are getting in and the second to ensure only authorized bits of information are getting out. Which people and which documents to concentrate on should reflect the nature of the risk you're mitigating -- a point that brings us back to the importance of treating risk in a non-monolithic way.

Simply acknowledging that a risk may exist is not nearly enough. With a vulnerability assessment process in place, an organization is ready to identify and nullify risks proactively.