Are Your Disaster Recovery Plans Ready For A Disaster?

One Data center just found out that theirs wasn’t, and a lot of their customers were also caught with no backup servers, only relying on the Data center’s disaster recovery. On Saturday ThePlanet Data center experienced an explosion in their power room that knocked approximately 9,000 servers offline, effecting over 7,500 customers. ThePlanet was unable to get power back on to those servers for over a day, due to the fire department not letting them turn the backup power on.

Two separate issues can be seen from this, one, the Data center’s disaster recovery plan failed to recover them from a disaster. While quite unlikely to happen, an explosion in the power room can happen, as seen here, and they were not prepared for it. Perhaps they could have worked with the fire department during the disaster recovery policy creation to identify ways that backup power could be served while the power room was down. Or possibly with 5 Data centers (as ThePlanet has) they could have had spare hot servers at the other sites to send backups to. We don’t know the details of their policy or exactly what happened yet, so we can only speculate ways that the downtime could have been prevented.

Secondly, many customers found out the hard way to not rely on someone else’s disaster recovery plans. These sites could have failed over to a site at another Data center, or even a backup at their own site, but they weren’t prepared, assuming that nothing could happen to the Data center their server is at.

The lesson learned from this mistake is that disasters happen, and you need to be prepared. No disaster scenario should be ignored just because “it’s not likely to happen”. So take a look at your plans, and if you host at a Data center, if your website is critical make sure there is a backup at a separate Data center or on your own site.

Time to Play Some Offense…

To quote, Allan Bergen, it sure looks like it might be “time to play some offense”…

Not surprising to me, I read today that the primary security concern of IT managers is the inside threat. It doesn’t surprise me because I have been working on educating organizations for several years about the seriousness of the insider threat. In fact, I would suggest that there are very very few threats that are NOT insider threats. Why? Because there really is no inside or outside. Thanks to disruptive technologies and evolved attacker capabilities – just about everything is exposed to attack. Just ask some of the recent vendors who were compromised in high profile “PCI-related” cases how well they feel that their “perimeter security” protected them…

The truth is, there are three powerful things that can be done to combat modern attacks, whether internal-based or executed by attackers half a world away.

1. Implement and enforce data classification – Know where your critical assets are, how they move around your environment throughout their lifecycle and then use tools like access controls, encryption and integrity verification to make sure that they are protected. Use logging analysis and event management to detect issues and make sure all of the controls, including role-based access controls, are HEAVILY and PERIODICALLY tested.

2. Embrace enclaving – Enclaving is like defense in depth throughout the whole network. Establish proper need to know boundaries, then build enclaves of security mechanisms around the data. Don’t build networks that trust user workstations with access to databases and other servers, segregate them with firewalls, detection mechanisms and access controls. Build as much security for the users as makes sense, but design the environment so that if users make bad decisions (which they will) and get popped – so what! Client side exploits and malware are only a concern if users have access to inordinate amounts of data. The problem is making sure that you get your controls and practices tight enough to limit the exposure that user compromise presents. That alone should go a LONG way toward minimizing your risk if done properly.

3. Move up the security stack to Threat Management and Risk Assessment – Use processes like risk assessment as a factor in business decision making. Security can truly empower business, but you have to let security teams stop being the “patch patrol” and “net cop” and let them get to actually helping you manage risk. They have to be able to identify threats, model threats and understand attacks and exposures. That requires education, dependable tools and upper management support. Encourage your security team to mature and begin to take real-world risk into consideration. Help them to resist the cult of the arcane technical security issue…

Of course, MicroSolved can help you with all three of these areas. We have the experience, insight and expertise to help you build effective enclaves and design data classification systems that make sense. We can help your team find security assessment goals that make more sense and provide ongoing assessment to keep them focused on the real-world risks. Our HoneyPoint products can help them model threats, frequency of attacks, understand the capability and intent of attackers and even give them deep insight into proactive risk metrics that they can leverage for “more science than academic” metrics of risk measurement. All of these things help your organization protect against the insider threat. All of them are available today.

The bottom line is this – if you are an IT manager looking to defend against the insider threat – give us a call. Together we can apply these strategies and others that your organization may need to effectively manage their risk and protect their assets.

At MicroSolved, we think differently about information security. So should you.

Apple Releases Security Update

If you’re running an OS X version below 10.5.3 it is time to upgrade or install security update 2008-003.
This update fixes multiple issues that could result in system access, security bypass and privilege escalation, DoS, Cross Site scripting and a number of information exposure issues.

The original advisory is available at: http://support.apple.com/kb/HT1897

Snort Issues In Case You Missed Them and Malicious SWF

In case you missed it last week, Snort seems to be suffering from a problem with odd TTL values, which could allow an attack to get by Snort without detection. 2.8.1 has been released and includes the fix for the issue. Users of Snort should upgrade as soon as possible or apply the following workaround until they can update:

/From iDefense/

In the snort.conf file, set the ttl_limit configuration value to 255 as shown below.

preprocessor frag3_engine: ttl_limit 255

This will set the allowable difference to the maximum possible value, and prevent fragments from being dropped.

/End iDefense Content/

Also, SANS is talking about malicious SWF files that have been found online. Looks like they are using some encoded images that can cause some issues with what may be a previously known flash player vulnerability. Advise your users to be wary of flash enabled sites that they would consider “untrusted”. Of course, your milage may vary with this one, but at least awareness might help….

Lastly, as refresher, if you are a Notes/Domino user, it might be a good idea to check out patches that have been released lately. There have been a number of issues in the last few weeks and we are seeing an increase in Domino fingerprinting on some of our non-US HoneyPoints. Looks like quick scans for names.nsf and a couple of other common Notes files. So far though, we have not seen any attacker activity out of the norm, but it may be the precursor to an attack or other activity. Just an FYI…

What is “Defensive Fuzzing”?

Since the release of HornetPoints with the newest version of HoneyPoint Security Server, I have been getting a lot of mail asking about “defensive fuzzing”. I thought I would take a moment and talk a little bit about it and explain a bit about its uses.

Defensive fuzzing is a patent-pending approach to network, system and application defense. It is based on the idea of using techniques from “fuzz testing”, but applying them against incoming connections in a defensive manner rather than as a test mechanism for known software. The idea is that attacker tools and malware probably fail to meet established best practices for software development and thus, are likely to have issues with unexpected input just as normal professionally developed software does. Further, “defensive fuzzing” lends itself to using fuzzing techniques as a protective mechanism to cause attacker tools, malware and other illicit code to abnormally terminate. Basically, by fuzzing incoming connections to a HornetPoint (which should have no real world use, thus all incoming connections are illicit) we can terminate scans, probes, exploits, worms, etc. and reduce the risk that our organization (and other organizations) face from these attacks.

For those of you who might not be familiar with fuzzing, you can read more about the basics of it here. However, keep in mind, that defensive fuzzing applies these techniques in new ways and for a protective purpose rather than a software testing process.

HornetPoints simply embody this process. They can be configured to fuzz many types of existing connections, emulating varying protocols and applications. For example, targeting spam and relay scanners can be done by implementing the SMTP HornetPoint. It listens on the SMTP port and appears to be a valid email relay. Instead, however, it not only captures the source and traffic from the spammers, but also fuzzes the connection as the spam is sent, attempting to terminate the spammer scanning tool, bot-net client or other form of malware that is generating the traffic. Obviously, success rates vary, but our testing has shown the process to be quite effective against a number of tools and code bases used by attackers today.

That is just one example and many more are possible. For more information about defensive fuzzing or HornetPoints, please leave us a comment or contact us. We would be happy to discuss this evolution in security with you!

Lotus Domino Cross Site Scripting and Buffer Overflows

At least two injection attack vectors have been discovered in IBM’s Lotus Domino Web Servers versions 6.x, 7.x and 8.x. These can lead to a stack based buffer overflow which may allow remote code execution and Cross Site Scripting attacks that can allow the execution of arbitrary HTML and script code. We recommend that you update your web servers as is appropriate.

The original advisories can be viewed at:
http://www-1.ibm.com/support/docview.wss?uid=swg21303057

and

http://www-1.ibm.com/support/docview.wss?uid=swg21303296

CA BrightStor Vulnerabilities

CA BrightStor has been found to contain several vulnerabilities. The issues identified are buffer overflows and directory traversal vulnerabilities. Both vulnerabilities exist in ARCServer Backup versions 11.0, 11.1, and 11.5. The buffer overflows exist in the xdr functions in the ARCServer server. The directory traversal could potentially also be used to execute code by writing to a startup or configuration file. CA has released updates for these issues, and they should be tested and deployed as soon as possible.