Pratum Blog

It happens every 3-5 years, especially at larger organizations. I'm talking about the switch from a centralized approach to IT and information security to a de-centralized approach. Then, a few years or leadership changes later, courses are reversed. It's an endless cycle I see regularly. So much time is wasted implementing the model of service delivery that sometimes not much service is ever actually delivered.

Why can't we pick a method and stick with it? Or better yet, blend the two so no matter who's in charge or what the analysts say, you can simply point out that we're somewhere in the middle and "leaning" one way or the other. Executives, I talking to you here. You need to think long and hard about changing the service delivery model at your organization. Is the change being called for by the organization's business units? If so, a change may actually be in order and it might stick after your departure which if current trends tell us anything will be in approximately 3-5 years. If this is simply something you want to do to put your mark on the organization, take a step back and re-evaluate.

While nobody wants to be stagnant, there is a fine line between change for improvement and revolutionary change. Now obviously I can't say one or the other isn't needed in your organization but what I can say is that sometimes we don't stop to evaluate which type of change we're making and why.

So…I know all the arguments on both sides of the centralized/de-centralized debate. Cost reductions, agility, consistency, compliance, integration, yada-yada-yada. Tell me your thoughts. Where is your organization, do you like it, want to change it? Go ahead…vent a little. You'll feel better.

A friend of my sent me this link recently about some researchers at UC Santa Barbara who took control of a botnet for 10 days earlier this year. I'd seen the report but never read the entire thing. (http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf). He indicated that his company had been affected by a similar problem and suffered a leakage of data. This got me thinking about the principle of defense in depth.

Our information technology ecosystems are complex. There's no getting around that fact. As we build more functionality into them, we're loading the gun of our adversaries with ammunition to shoot right back at us. Trying to defend against an attack using only one defense mechanism is bound to fail. My dad was a career Navy man. I remember asking him one day why the aircraft carrier he was attached to had a "strike group" surrounding it. His explanation was…you guessed it…defense in depth. The submarines, destroyers and frigates that sailed with them were layers of defense to protect the carrier. Each had its own mission which overlapped with the other ships. This created a mesh for miles around the carrier which was designed to identify, intercept and if needed destroy any threats to the carrier. Should any of these defense layers not be deployed, there would be a gap or weakness in that mesh of security.

Companies often decide to only deploy one layer of security which targets specific threats that are seen as high probability. These companies often find themselves in a world of hurt. If that end node is compromised there is nothing to stop the trouble which is sure to follow.

If you rely solely on desktop malware protection then monitor your outbound traffic logs for inconsistencies such as lots of traffic to an IP or domain, spikes in traffic during off peak hours, etc. At least this way you'll know you have a problem and can begin to plan your response. Better yet…layer up your defenses at the network perimeter, interior network core and then at the end node. Hopefully through a layered approach you'll be able to identify, intercept and destroy any threats before the even come close to your data.

Through the years I've had to opportunity to help many organizations with their regulatory compliance programs. It's been very enlightening to see the approach each organization has taken in their effort to become "compliant". Many of the differences have been explained by quoting the industry profile or size of an organization. Other times it's the budget or process maturity that has defined their process or lack thereof. Each time I have challenged the business leaders with this thought. Compliance is not a technology problem, it's a business problem.

Over the next few postings I'll attempt to provide some practical advice for how to approach the complex issues of implementing information security in an effort to meet compliance "mandates".

TIP #1: Do a risk assessment…

So many times we look to technology to solve our problems. This harkens back to the early days of IT integration into the business process. Back when technology could be applied to most processes and the efficiency gained would be off the charts. There wasn't a lot of thinking or justification needed for those projects. You just knew if they came in on time and on (or close) to budget you'd have a winner.

We've moved into a new age though and our thinking must transition with it. Gone are the days of all technology projects being a plus for the organization. We really need to identify which projects are worth the time, effort and expense.

Compliance is no different. Most of the regulatory environments your organization will fall under, SOX, HIPAA, FISMA, GLBA, etc., are not specific in how you meet the requirements. One thing they do however require is a risk assessment.

The underlying principle of each of these regulations is the reduction of risk. Notice I said the "reduction" or risk and not "elimination" of risk. When talking about business you've often heard the phrase "No risk…no reward" right? If you eliminate all of your business risk and can still make tons of money wouldn't everyone do what you do? Where's the market in that? What we really want to do is reduce our risk to acceptable levels. From a business perspective we do this every day when deciding to open in new markets, launch new products, etc. We weigh the risk to the organization and determine if the risk is worth the reward. In the same vein then, if you could reduce your risk significantly with little impact to your operations and budget you'd be crazy not to.

Information security must be approached the same way. Don't put in firewalls, email encryption or costly intrusion detection systems because everyone else is or you think you're required to. Assess the inherent risk to your organization without those controls and compare that to the residual risk which would exist after implementing them and see which one you'd rather live with. Why spend $10,000 to replace something which can be replaced for $1,000. Some things though are harder to quantify such as reputation. It becomes much more complex to put a price on these items.

Now this isn't a license to be negligent and not do anything but there's certainly a difference between a $500,000 intrusion prevention system and a $50,000 intrusion detection system. Both might satisfy your compliance needs. Only after doing a risk assessment can you determine the level of risk your organization is willing to live with. Risk assessments will help your organization build a profile for risk tolerance and help you prioritize your investments in security.

Many times external consultants are better at leading these discussions as they can bring an objective viewpoint to your process, especially if this is the first time an assessment is being performed. Pick your assessors wisely though and make sure they want to take the time to understand your company, it's culture and how it makes (or looses) money. While there are best practices to follow, a cookie approach will only take you so far.

Next up…Information Security Policy: The Love-Hate Relationship

Get our blog posts delivered to your inbox: