Data Breach: Are You Next? - Part 2

So last time I talked a little bit about the current state of affairs in IT security. We've seen attack that have gone from D0S'ing perimeter system to application-based attacks that are stealthy and can cause equal or more damage. I wanted to dedicate this part of my series on Data Breaches to talking about way we can protect our data without spending money or burying ourselves in purchased solutions. Some of these may seem like standard practice, but take this opportunity to reflect on each of these and if there's a way to improve.

Data Classification
This long journey down the never-ending path of security starts with this key step. You must define what your organization sees as sensitive data. Something basic like SSN is practically a given in every company, but look beyond that and clearly define the data you consider sensitive. This can be credit card numbers, sales data, or any other type of data that is sensitive to your company. This is important, as you'll need to know the data to protect in order to define the rest of you security blueprint.

Policies
I can't speak enough about a good security policy. A policy defines a set of standards that yield repeatable results. So, if we take my definition of a policy and apply it to security, a good security policy will define security standards and yield results that consistently meet security standards. I don't think you can find a security book today that doesn't talk to having a firm security policy. I joke with one of my co-workers who is learning IPS, and just about every chapter he turns to talks to implementing IPS based upon your corporate security policies.

I see too often that policies are too broad and are open for too much interpretation. A policy must be exact in it's definition, and the sum of all policies should reflect the security goal for an organization. Where do you start though? If you must define policies for all systems, how do you begin and provide immediate protection for day one? If you must start from the beginning, I urge you to define you policies for protection of you sensitive data, which I'll talk about next. This can include something as basic as password policies and something more complex like all sensitive data cannot travel using clear text protocols (FTP/Telnet/HTTP). I can't define how each organization should write a policy, but as we move onto our next discussion, I think the proper policy design should come to light.

Know Your Data
I want you to memorize this: you cannot protect the data you do not know about. This is similar to data classification above, but goes a step further. All too often, systems are implemented on-the-fly as organizations expand. This can cause a centralized data model to become more of a mesh, where data must be passed from system to system during processing. This means that data you previously classified as sensitive, is being passed through multiple systems. Take your sensitive data classification, and now map out where the data travels on the network and where it stays at-rest. This is very important, as you'll need to define auditing around these systems so you can record data access and flow.

Audit Yourself
The final practice you can use is auditing. I could go on-and-on about this, but I'll keep it brief. Now that you have your data defined, understand it's flow, and have the policies to protect it, check you work.... and check it often. This is auditing. Plan to review server/network security logs periodically for any anomalies. Get your system to log to a common location (a basic syslog server will do), and use the central repository to audit access and flow of data. This is as important as every other step, because it keeps your policies and data in check, so you don't end up in the situation of not knowing where you sensitive data is again. Another great audit technique is trying to breach yourself. Take a security tool, such as Nessus, and scan the systems defined in your sensitive data map. Nessus will audit the system for vulnerabilities and give recommendations how to patch or mitigate the issue.

If you start this process by employing all of the above, you are well on your way to being secure. Some of these items may be trivial, but none of them are any less important then the others. I'll see you all next week for part 3 on this topic, where I'll talk about the current generation of security products to build a fortress around your data.

-Mike