You probably have heard of the “Stuxnet” worm or the “Flame” code that was presumably aimed at machines processing radioactive substances. (If you haven’t heard of either, you are working far too hard and need to look around at what is happening in the IT world.) These are specially crafted pieces of code designed to perform specific cyber-attacks, such as accelerating a nuclear centrifuge way past its breaking point while reporting all was well on the management screens. You may wonder what this has to do with Data Regulatory Compliance.
Consider the tactical situation; a program of malicious code (malware) was somehow injected into a closed foreign military system that had no physical connection to the worldwide Internet. Further, despite a high level of internal security, it was not discovered for years. In fact, it was not identified until it escaped from the “secure” facility (on somebody’s unauthorized laptop no doubt) and started flying around the world on the Internet.
So the question arises, since your company is always connected to the Internet, and your employees use their laptops outside of your network for personal email and surfing the net; how in the world could you believe that your company network could not be successfully compromised in the future?
Criminals are after your data, not your hardware. (Well some criminals steal hardware, but these are different criminals with smaller budgets.) Make no mistake; organized crime is knocking at all our doors all the time. Criminal hackers want to download whole databases and sort it later in their own sweet time. They get your data and your company takes the heat. This is bad.
You need a way to protect your most valuable, sensitive, and risky data within the corporate network even if the network is compromised. A reasonable first step is to understand the sensitivity and risks of the data you manage.
Identify which data are affected by regulations and contractual obligations (HIPAA, SOX, PCI, EU FISMA, EU DPD 95/46, PPI, etc.), and data comprising your “trade secrets” you would not wish to be public. You can’t protect what you cannot identify. Some data will be more sensitive than others, and some data loss will be more costly than others. You first need to know which data is sensitive, and next you will need to know one more thing.
You need to know where in your company this data resides; which servers and which databases and which laptops. Odds are you will find sensitive data mixed through all the less sensitive information. Thus, you should make strategic changes in these databases so that you can isolate and protect high-risk data. Lock the gold in the vault, not the pencils.
For example, you might want to put the most sensitive data in separate tables with different access rules, or encrypt them, or place them elsewhere in your network behind an internal firewall. This might slow down a query, but when the database is compromised the hacker will not be able to access your most sensitive data. Effort and latency must be measured against the cost to the enterprise if the data is stolen and published on the Internet.
This is not hugely difficult technically, but is difficult politically. You see, people in your company have been rewarded for years with raises and perks for making things happen faster and will resist additional system complexity and latency. You are paying them to resist it.
To make compartmentalized data protection a success your employees need to feel secure that they will not be penalized by the extra work to secure sensitive data. This is a management challenge opportunity. If you develop teamwork for this program, you now have a high-performing team to tackle your next big technological challenge. Got any of those?
Only with a good risk analysis can you determine the level of proper protection to use for Regulated Information within your data architecture. Don’t make it easy for criminal hackers: provide protection in depth. They will get in.