Follow-up on full compromise

tate@ClearNetSec.com (Tate Hansen) — Fri, 08 Dec 2006 11:02:00 -0700

This is a follow-up from this post: (recap: large financial org w/fully compromised internal systems)

The path of the compromise was pegged to an errant firewall rule put in place during the pilot/testing phase of deploying a security point solution: SSH was open to any. The password lacked sufficient strength to avoid brute force guessing and the system was compromised from the external side within days.

Check this out - this security point solution is a device that sits on a SPAN port and looks for any confidential information on its way out. It records anything that triggered a “hit” in simple flat text files on the local system. It was a gold mine: text files with first name, last name, SS #, mother’s maiden name, account #s, addresses, and phone information.

The catch on all this is this is one of those vendor point security solutions designed to be deployed near the perimeter. It lacks the defense in depth muscle used to protect this type of sensitive data. Even if SSH was closed this org did not protect it as if it contained customer data.

Additional lessons learned:

Remember to consider anything (security product or not) eavesdropping and recording traffic as potentially holding super sensitive information and take the necessary precautions.
This org was told by the vendor the data was safe. If you hear that, sit back and think for a few minutes then fire off some questions that will help you understand what they mean by “safe”.

I keep thinking how offering a simple and cheap continuous port scanning service would’ve saved this org big time. Maybe I’ll add that as a feature to nmapTweaker.

ClearNet Security: Tag customer data

Follow-up on full compromise