Posted by Tate Hansen
Fri, 08 Dec 2006 18:02:00 GMT
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.
Tags ClearNet Security, compromise, customer data, point solution, security, Tate Hansen | no comments
Posted by Tate Hansen
Fri, 10 Nov 2006 05:55:00 GMT
Full compromises are crazy – it happens, but nearly every one I touch still sends a little shiver down my spine mixed with a “holy shit” moment.
Case in point: we got a call last week to help out with an incident and to do an investigation of some Linux based security devices. Financial industry, lots of customers.
Their engineers were working feverishly to scope the incident and to learn all the details then slam – they hit a wall. Their firewall logs everything. Their only-way-out-is-via-a-proxy-server logs everything.
And their security point solution in the DMZ? Oops, it only logs locally (it also happens to be a party to the fully compromised club inside this trusted net). And what about their desktops which appear to have offered free remote admin VTYs? Well, this all has a kicker for an answer.
It happened a year ago. Ouch. Talk about sensing a cold sweat and suddenly not trusting anything. By the way, the desktops exhibiting the worst behavior traveled the evolutionary path and have been wiped clean and rebuilt, upgraded, or replaced since the break-in. No substantive logging or backups of mischievous desktops; no way to reconstruct the perpetrator’s methods. Security point solution in DMZ had standard local logging (i.e. full rotation in weeks), therefore it is unlikely things we're looking for are there (still investigation). No network device logging. There are lots of unanswered questions.
The details of this should strengthen your neuron paths connecting logging to your “holy shit” moments. That is to say…
-
If you got important data to protect, log everything you reasonably can. All the “security” in this scenario failed and failed to help reconstruct events.
-
Do you have one of those semi hands-off security appliances that you presume is working fine because you can connect to the web admin portal? Make it forward logs to somewhere.
-
Do you have workstations which touch sensitive data anytime? Yes. Then boost the priority to configure central logging, stop procrastinating, then take comfort you’ll be in better shape than the poor souls at this company fighting to salvage their pride, and maybe their jobs.
Tags ClearNet Security, compromise, forensics, logging, security, Tate Hansen | 2 comments
Posted by Tate Hansen
Tue, 25 Apr 2006 08:13:00 GMT
I shouldn't be shocked, but I am. A piece of the conversation today we had with a client went something like this:
client: yeah, we also just found out we have an ex-employee logging in from the internet to our servers and helping other nurses with some computer tasks
us: um, you have an ex-employee logging into your servers remotely?
client: yes
Talk about scary. I wish I could say more. Let's just say this is relatively minor compared to other illegitimate activities this particular client is suffering from (e.g. knowledgeable attackers with clear targets). It is quickly turning into one of those scenarios whereby you can’t trust the integrity of anything electronic.
On top of that, it’s another flare on why it is so important to just know what is and should be happening on your network. Forget about all the fancy security solutions; what is important first is to understand why and how devices talk. Do these systems over here need to talk to these systems here? No. Why are they talking then?
This client has security point solutions in place, but they haven’t a clue what is happening or why. If you spend the time to define the relationships, catching potentially illegitimate activity is a LOT easier.
Tags ClearNet Security, compromise, employee, ex, security, Tate Hansen | no comments
