For all you Cisco security freaks out there, the long awaited CSA 6.0 is now released. This latest version of Cisco Security Agent bring some great enhancements, including Vista agent support, an integrated signature-based anti-virus scanner, and a very cool data leakage protection (DLP) feature. I've been part of the beta the past couple months and have seen the terrific changes from 5.2 to 6.0. All you 5.2 owners with SAU, start downloading 6.0 and try it out. Checke the rather verbose release notes here, and enjoy. If there's enough interest I can do a few posts on the new features bundled with 6.0.
-Mike
Thursday, August 14, 2008
Friday, May 23, 2008
CCNP BCMSN: Passed!
Just thought I'd share my excitement on succesfully passing my BCMSN exam this past Monday. This is my first CCNP-level exam and gets me renewed on my CCNA until 2011! The certification exams have certainly gotten more brutal. I was expecting lots of spanning tree questions, but there ended up being a lot of focus on QoS and HSRP/GLBP. Just goes to show you that anything is up for grabs with these exams. What should be next: ONT, ISCW, or BSCI?
-Mike
-Mike
Saturday, April 26, 2008
Mike's Blog: A New Direction
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
-Mike
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
Saturday, March 08, 2008
CMPC v1.5 In the Wild!
I'm happy to announce v1.5 is now released and available to download here. This version includes a number of enhancements and new packages. Here's some snippets from the release:
- Added support for CCO tree-style release listing.
- Removed restriction on number of runtime arguments.
- Added the following package options for notifications:
- Cisco Wireless LAN Controllers
- Cisco Wireless Control System
- Cisco ACS (Windows Version)
- Cisco VPN 3000 Concentrator
- Cisco VPN Client for Windows
- Cisco CSS 11500
- Cisco WAAS
- Added the ability for CMPC to check your current MARS apppliance version via SSH.
CONFIGURING CMPC TO CHECK MARS APPLIANCE VERSION
================================================
CMPC now has the ability to check your MARS appliance version via SSH. This is made possible by use of libraries from the SharpSSH project (http://sharpssh.sourceforge.net/). There is a bit of configuration to make this possible. First, make sure the following dlls from the releases zip file are in the CMPC running directory:
DiffieHellman.dll
Org.Mentalis.Security.dll
Tamir.SharpSSH.dll
Now you'll need to add the following lines to your config.xml file:
SEE RELEASE NOTES
The "mars_check_version" field should be set to "1" to enable the processing of your MARS appliance. Switch to "0" (or anything besides 1) to disable this feature). You'll also need to make sure your pnadmin password is encrypted in the XML file. Run CMPC like so to have it encrypt your password.
Example: "C:\>cmpc.exe --encryptpass"
Now when you run CMPC with the --ciscomars option, it will get the current software version of your MARS appliance and add that to the e-mail notification.
Enjoy this latest release and any comments or issues let me know.
-Mike
- Added support for CCO tree-style release listing.
- Removed restriction on number of runtime arguments.
- Added the following package options for notifications:
- Cisco Wireless LAN Controllers
- Cisco Wireless Control System
- Cisco ACS (Windows Version)
- Cisco VPN 3000 Concentrator
- Cisco VPN Client for Windows
- Cisco CSS 11500
- Cisco WAAS
- Added the ability for CMPC to check your current MARS apppliance version via SSH.
CONFIGURING CMPC TO CHECK MARS APPLIANCE VERSION
================================================
CMPC now has the ability to check your MARS appliance version via SSH. This is made possible by use of libraries from the SharpSSH project (http://sharpssh.sourceforge.net/). There is a bit of configuration to make this possible. First, make sure the following dlls from the releases zip file are in the CMPC running directory:
DiffieHellman.dll
Org.Mentalis.Security.dll
Tamir.SharpSSH.dll
Now you'll need to add the following lines to your config.xml file:
SEE RELEASE NOTES
The "mars_check_version" field should be set to "1" to enable the processing of your MARS appliance. Switch to "0" (or anything besides 1) to disable this feature). You'll also need to make sure your pnadmin password is encrypted in the XML file. Run CMPC like so to have it encrypt your password.
Example: "C:\>cmpc.exe --encryptpass
Now when you run CMPC with the --ciscomars option, it will get the current software version of your MARS appliance and add that to the e-mail notification.
-Mike
Saturday, March 01, 2008
User Question: MARS on 3rd Party Hardware?
Another great question from the community. Fabio writes in and asks:
-Mike
Does Cisco Mars come only on box or could I get the software and install it onThe short answer: No. But why? I'm sure in a way it has to do with costs and how Cisco is able to required Cisco hardware to be used. There's also less cynical reasons. One that I know of is that MARS is using Oracle embedded for it's database. As part of using Oracle on an appliance and having it licensed as embedded, is that the distributor of the appliance must no allow users to alter the database or exploit it for unlicensed purposes. Mandating the use of a purchased appliance keeps greater control over how the software is installed and the experience it provides to it's users. Hope this helped!
my server?
-Mike
Subscribe to:
Posts (Atom)
