If you don’t have Integrity, What do you have?
In the last while, I haven’t heard much about Data Integrity in the news. I guess that’s a good thing. Nothing to worry about, right? I doubt it. What is one of the worst threat scenarios you could imagine in your enterprise? Identity theft, credit card fraud, data compromise? Maybe. But what if someone is able to gain access to a key database server in your operations zone? Has anyone considered what could happen if the culprit was sympathetic with your competitor, or had an axe to grind with your organization’s management?
In the old days, hackers broke in and defaced Web sites. Well, in a rare bit of nostalgia lately, they were at it again when they decided to hit the Canadian Nuclear Safety Commission Web site. But nowadays it’s usually for financial gain (selling information) or serious revenge. Most of the time, they do whatever they can to cover up their tracks. This makes it hard to tell if they’ve even touched your servers.
Most often I hear of people doing Threat and Risk Assessments or Incident Investigations, and they are concentrating on what the cost is, in relation to the resale value of identity information, or loss of credibility. These are important, for sure. But I rarely hear people considering what the cost could be to an organization if their operational information in live databases is altered maliciously. How long would it take to discover? How long would it take (and how many analysts) to identify the exact roll-back point? Of course, everyone is doing database checkpoints and journalling (are you?), so it shouldn’t really be a problem to recover systems to the point of compromise, reload all the subsequent transactions to the current date? And to top it off, what if the perpetrator was a malicious internal administrator who knows what safeguards are easiest to get around without detection? Could they plant some malicious code on a server that could continue to corrupt data long after they are gone?
OK, so you might say that these are really far out scenarios. And like Bruce Schneier’s “Best Terror Movie Plot” contest, it could raise some objections that we are just giving people ideas here. That’s really underestimating the imagination of the bad guys. But that’s a whole other discussion.
The real key is to incorporate layers in your security safeguards that not only try to prevent and detect at the perimeter, but inside more secure zones, as well. And it’s not just protecting against access for theft, you must consider ways to prevent and detect unauthorized modification of operational data that your organization depends on. Imagine having buy/sell limits changed for thousands of investment clients; or flight times and fuel quantities for an airline with thousands of aircraft moving around the world…
There are features in most database systems, and there are file system integrity tools that can let you know when unscheduled or unauthorized changes are made.
The key tools for protecting data integrity are access control and detection of unauthorized changes. These risks may not be as spectacular as losing a laptop with half a million identities on it. But, I think the impact to an organization can be just as devastating if all the layers aren’t protected against less obvious attacks against data integrity.
mroonie on 05 Mar 2007 at 12:00 pm #
I agree that as much as it seems like a “that won’t happen to me” situation, it isn’t that unlikely. Especially the scenario described at the beginning of this post. The possibility of such internal threats happens pretty often, unfortunately.
Hopefully with this new movement towards security (with RSA and Vista, etc.) more and more companies will recognize the need for security and really come up with the solutions necessary.
Simone D. on 25 Mar 2007 at 4:50 am #
The most dangerous scenario is when changes are not discovered. If i found something “not right” i can fix the problem (i hope to) … but if i don’t see anything strange the changes are a HUGE problem!
Probably the main problem is that the system was hacked … so the changes are possible … but i agree that is necessary another layer of security at data level.
Scott on 25 Mar 2007 at 10:10 pm #
@Simone - You are correct. However, an unauthorized change that isn’t detected could still be from an insider. I’m not sure if you are disagreeing with this.
The best way to counter unauthorized changes to files on operational systems is to use a “file integrity checking” solution, such as Tripwire. As long as the correct set of “sensitive files” are identified, which can only change under certain circumstances, this risk can be reduced.
If you are talking about unauthorized changes to a database record, this is more complicated, but logging of accounts performing updates (and when that account logged in, and on what terminal or session), can help here. You might be able to identify what type of accounts can cause insertions or updates to the database, and either prevent any other accounts from making changes, of flag them as being suspicious, raising an alert to an Information Protection Centre (Operations Monitoring staff).
Separation of Duty safeguards can prevent an insider from being able to make a change and cover his/her tracks.
Finally, if the sensitive data is kept in a properly isolated “Security Zone” with connection rules that break up sessions so they don’t penetrate multiple zones directly, the chances of a hacker making an unauthorized change are minimized. But an insider might still be a risk, without the other safeguards above being in place.
If these safeguards can be put in place, you should be able to increase the chances of prevention or detection, whether it is an insider or a hacker from outside.
Simone D. on 26 Mar 2007 at 3:47 am #
Sure an insider can be more dangerous than an outsider.
This topic is really interesting, thanks