What's this... it's changing? Well, not really. The title of my blog is going to be changing (domain name still the same) to reflect the new direction I plan to take this blog. I try to focus on security, but with the project load I have, I'm finding not everything focuses on security. I'm learning a lot, much like everyone reading this. I want to share the ups and downs, and I think by lifting the security-focus of this blog, I can discuss topics on some of the newer systems I work on. You've already seen some posts about wireless and VoIP. I consider Chris over at The Unofficial MARS Blog the man to go to about everything CS-MARS. I'd hate to take away any attention from him by having a competing blog (I never saw it as a competition), when he has a wealth of knowledge on MARS to share. I'll still post about MARS and security, but now you'll see some topics I previously saw as not necessary on a MARS/security blog. Stay tuned...
-Mike
Saturday, April 26, 2008
Sunday, April 20, 2008
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
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
Saturday, April 12, 2008
Data Breach: Are You Next? - Part 1
I thought I'd take some time to have a little talk about the growing trend of data breaches at organizations. There's no lack of these in the news, with the most recent being the loss of over 4 million credit cards by Hannaford. This gained a lot of publicity due to the scale of the breach. Just look at this month alone... there's already been 9 reports of data stolen from companies/organizations. I think it makes this an appropriate time to talk openly about breaches like the one at Hannaford, and what options network professionals have to combat these attacks.
If you're on my blog, you're at least starting in the right direction. Not every issue can be solved with money though, and that's the same with IT security. Security isn't something you implement or buy, security becomes a methodology by which you deploy all systems. The most secure networks can be ridden with applications that can leave holes open that firewalls can't protect against. These type of attacks are becoming the fad of data breaching. Previous hacks involved finding a way to DoS (denial-of-service) attack perimeter security measures, then breaching the systems behind them. The latest wave of attacks are much more intelligent and stealthy. These attacks actually target application vulnerabilities and inject malicious code on systems that are trusted by perimeter application servers. A common form of this is SQL injection. SQL injection allows the attacker to execute raw SQL code against backend database servers. Within a few steps from the initial SQL injection attack, the attacker has access to system level commands deep within the backend database servers. The most hardened perimeter ASA (Cisco Adaptive Security Appliance) won't block these ports, as the traffic is passed via standard web ports.
So what can we do? Is the answer to write more secure applications? That's one important change that can happen, but defenses cannot be left to the applications alone. Looks to part 2 of this series where I'll talk more in details about the logistics of these attacks and how you can defend with little investment in current technology. Part 3 will look at how we secure the environment end-to-send, and use MARS to correlate the massive amount of security data into actionable events. Happy defending...
-Mike
If you're on my blog, you're at least starting in the right direction. Not every issue can be solved with money though, and that's the same with IT security. Security isn't something you implement or buy, security becomes a methodology by which you deploy all systems. The most secure networks can be ridden with applications that can leave holes open that firewalls can't protect against. These type of attacks are becoming the fad of data breaching. Previous hacks involved finding a way to DoS (denial-of-service) attack perimeter security measures, then breaching the systems behind them. The latest wave of attacks are much more intelligent and stealthy. These attacks actually target application vulnerabilities and inject malicious code on systems that are trusted by perimeter application servers. A common form of this is SQL injection. SQL injection allows the attacker to execute raw SQL code against backend database servers. Within a few steps from the initial SQL injection attack, the attacker has access to system level commands deep within the backend database servers. The most hardened perimeter ASA (Cisco Adaptive Security Appliance) won't block these ports, as the traffic is passed via standard web ports.
So what can we do? Is the answer to write more secure applications? That's one important change that can happen, but defenses cannot be left to the applications alone. Looks to part 2 of this series where I'll talk more in details about the logistics of these attacks and how you can defend with little investment in current technology. Part 3 will look at how we secure the environment end-to-send, and use MARS to correlate the massive amount of security data into actionable events. Happy defending...
-Mike
Subscribe to:
Posts (Atom)