The Sky is No Longer the Limit: Thoughts from the Cloud

Kevin Nikkhoo

Subscribe to Kevin Nikkhoo: eMailAlertsEmail Alerts
Get Kevin Nikkhoo: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Security Journal, SOA & WOA Magazine

Blog Post

Risk versus Threat

It's more than just semantics

I was chatting with an IT professional about the benefits of cloud-based security and he kept referring to a recent risk assessment he performed. (And if you haven’t done this lately, you should) But what got the gears in my head turning is how interchangeably he used the terms “risk” and “threat.”

Now on the surface they seem like the same component of security management. I tend to disagree. In its simplest of terms, risk the probability or frequency of doing harm while threat is the actual or attempted infliction of that harm. Tomato, tomahto? Splitting hairs? It’s all about keeping your IT assets protected, right?

Well…yes…and no. Call it a pet peeve, but I believe risk and threat, although related, are two different beasts altogether. Risk includes variables. It overviews vulnerabilities, weighs challenges and opportunities to come up with an outcome. And there is risk in every action you take; some of it is so low that it poses no challenge to your architectures. For example, let’s say you note traffic pinging on a SQL server from a Bangladesh IP address. Let’s further assume there is unique or proprietary data living on that server. Is this a threat? Could be; but there are too many variables that must play out to properly assess its risk value. What is the source of the IP? Is this traffic normal and follow predictable patterns? Does it happen on off hours or during the course of business? Does it bypass any layered protocol or does it use authenticated means? Now, if I said this was a customer or vendor, does this change whether it is a threat? It might based on your definitions, but the point here is there is risk with every event or log, but whether that event is a threat is debatable.

And if you add “vulnerability” into the mix it creates a third dimension when assessing risk--vulnerability is a state of being--a weakness or gap in your security. A threat can exploit (intentionally or unintentionally) a vulnerability that is determined by a risk assessment.. Then of course you add likelihood. How realistic is this event to actually happen? Going back to our SQL example: if your SQL server has no external endpoints, the likelihood of an attack is considerably smaller than let’s say malware finding its way to a web or email server. Think of it another way. Sharks are a threat. Sharks live in water. You own a pool. What is the risk of finding a shark in your pool? But you also have a toddler. How realistic is it to think that the toddler might wander past your security gate (when was the last time the locks were checked?) and fall into the pool? Maybe it's time to buy a pool cover. Just because you make an assessment and recognize certain gaps in protection doesn’t mean you have taken steps to mitigate it. Now let’s put it all together…

Threat x (Vulnerability + Likelihood)/Impact = Risk

Let’s put a face on it. Emails come to your enterprise workstations hundreds or thousands of times a day. As the user is typically the weakest link in the security chain you have to depend on education and good sense to keep them from clicking on something potentially harmful. If they click on it what is the probability or likelihood that it will have some degree of negative effect on your IT environment. How quickly and where would it spread? And lastly what is the damage done, what resources will be lost at what cost? Apply this to every security circumstance and there you have a risk assessment. And once you have a risk assessment you can start planning to shore up vulnerabilities against threats.

But rather than debating semantics, let’s look at this as best practice. How do you best put together a risk assessment and/or a threat assessment? There are a great many experts who can spend endless consulting dollars answering that question, but bottom line is that you weigh each risk to determine whether it poses enough of a hazard to take action. And these hazards can all be quantified in terms of dollars. If the pain threshold is high enough, then certain steps are taken to mitigate the threat.

So how does this intersect with the cloud? It all goes back to resources. Do you have the technology, the budget, and/or the manpower to analyze every blip or define/escalate every event? Security–as-a-service helps lift that burden by employing 24/7/365 monitoring and using your applying your risk assessments to best defend your IT assets in real time. Once you define what events that pose the greatest threats, you can prioritize response and take appropriate action without impacting your departmental staff.

In short, even the best risk assessment and mitigation measures leave a certain amount of residual risk, either because one can’t mitigate totally against all the risks or because of the element of chance. But, by better understanding the difference between ‘threat’ and ‘risk’ can help you make decisions that will keep your systems safer and avoid unnecessary costs.

More Stories By Kevin Nikkhoo

With more than 32 years of experience in information technology, and an extensive and successful entrepreneurial background, Kevin Nikkhoo is the CEO of the dynamic security-as-a-service startup Cloud Access. CloudAccess is at the forefront of the latest evolution of IT asset protection--the cloud.

Kevin holds a Bachelor of Science in Computer Engineering from McGill University, Master of Computer Engineering at California State University, Los Angeles, and an MBA from the University of Southern California with emphasis in entrepreneurial studies.