I was on a train recently, heading to customer meetings.  I would only have paid cursory attention to the couple standing in the aisle had it not been for one small detail.  While the man was clearly very enamoured with his partner and was demonstrating it, the woman looked ready to commit murder.  Specifically HIS murder.  The visible deficit in their respective levels of engagement amused me, but on second glance, I was interested to see another detail.

The woman’s work identity badge was clearly on show.  Her employer was a major bank. The woman had a very common surname, but a distinctive first name.  We’ll call her Mrs P.  As I was online at the time, I jumped out to LinkedIn.  No profile for that name at that employer.  Facebook was a different story.  There she was, with a completely open profile.  All it took was a couple of clicks to ascertain her husband’s name, her home town, the names of some of her family and the fact that she had a pair of terriers called Fred and Ginger.

OK, so the names have been changed to protect the guilty, but the highlights are true.  Role playing for a second, I’m a criminally inclined social engineer who rides the commuter lines looking for clues like these.  All it takes is a couple of calls to some colleagues and Mrs P receives a call threatening Mr P and the dogs, and all of a sudden a vector has opened up into one of the largest banks in the world.  This is the thing about Social Engineering.  A vector is a vector – whatever intelligence you can gather about a possible target is, literally, gold.  The manipulation of human factors involved in corporate operations remains the single easiest thing for a criminal to do in order to make money from YOUR company.  Even if Mrs P’s blissful unawareness of the risk she has created doesn’t result in tangible losses, I would certainly never bank with this organisation, because they have no pervasive culture of security.

Which brings me to my final point. Security is cultural.  Let me say that again.  Security is cultural.  Unless you’re absolutely aligning the use of enterprise class tools to support your security professionals with regular training to people like Mrs P., on how she’s putting her company and her personal life at risk, then you’re nowhere.

What does this mean to you?  In the short term, nothing.  The standard will be in a public comment period until September 2, 2011, and is not scheduled to be included in SP 800-53 until December 2011 when Revision 4 gets released.  After that, it still needs to be updated in FISMA and other regulations derived from SP 800-53.

However, the controls outlined in the draft are significant, and will eventually add extra layers of complexity to an organization’s plan to become compliant.  I’m still fully digesting the draft, but something that initially stands out is that NIST is treating PII data similar to how PCI-DSS treats card-holder data, and to how NERC-CIP treats Critical Cyber Assets.  For example, control SE-1 in the NIST draft states:

The organization:
a. Establishes, maintains, and regularly updates a PII inventory that contains a listing of all programs and information systems identified as collecting, using, maintaining, or sharing PII;
and
b. Provides each update of the PII inventory to the CIO or other information security officials to support the establishment of appropriate information security requirements for all new or modified information systems containing PII.

This sounds very similar to the approaches in PCI-DSS for defining and securing the Cardholder Data Environment (CDE), or the NERC-CIP Critical Cyber Asset identification.
The draft also adds on all the standard process and procedure requirements, auditing requirements, monitoring, roles and responsibilities, etc, that are seen across the board in other compliance regulations.

While there will still be quite some time before organizations are mandated to adhere to this draft standard, getting a head-start now will save headaches in the future, and protecting PII is simply the right thing to do, regardless of whether it’s mandated by compliance.

Recently I sat and watched a trusted colleague deliver a presentation to a roomful of security personnel and liken their industry to an air wreck.  I believe his exact words were ‘if this were a plane, I’d be running up and down the aisles screaming that we’re all going to die!’.  Needless to say this was not well received on the day, but I can’t help but think that he had a point.

Now, I work for an SIEM vendor – the best on the planet, in my opinion, but I’m not going to ambulance-chase this one.  There are crucial issues raised now.  This raises questions about whose responsibility personal privacy actually IS.  As I’ve said before, Amazon, Barclays Retail, Dell, Dabs – any of these guys could get hacked tomorrow and lose YOUR data.  What then?  It can take weeks to recover from a personal identity breach – resetting email accounts, changing card numbers, suppliers and addressing the huge numbers of interconnected services and locations where your identity converges.  This is not to mention the consequences if you actually lose money.

What more can individuals do?  Most of us are getting it right:  Don’t throw old business cards in the bin.  Go for strong passwords, changed at least monthly.  Don’t show identity badges in public places (watch out for my next blog on this!).  Speak to everyone about the need for security.  Educate the less technically literate about malware.  Don’t respond to emails or phone calls about online matters unless you initiated the conversation.  Keep one eye on the security blogs.  Learn the language.

Can companies say the same thing?  What about the people who I entrust my identity to?  Invest in security – with all that entails.  Infrastructure.  Dedicated FTEs.  Education.  Compliance.  Regular reviews.  Fire drills.  Specific executives whose job IS security.  Clearly the people who take online privacy seriously are being let down by the companies who don’t, and the more companies that are breached, the more excusable it seems.

My own view on Sega and the bi-monthly additions to the ranks of large companies who didn’t make the grade, is that it’s time to think of security as a multi-partite affair.  Your strategy should start with compliance, then loop through infrastructure best practise, via rigorous HR policies and finish by directly addressing social engineering.  The modern breach is a blended affair.  Only a blended security strategy will work.  One that centres around human factors.

Ten years ago, I was put into the position of having to figure how to manage a serious gap in enterprise security for a vitally sensitive environment.  The problem was introduced to me like this:  “The team can read 3,000 pages of logs per day but they receive 55,000 pages.”  Adding more heads to the problem wasn’t the right solution- they were losing context, were inaccurate, under-trained, and bored.  The success stories from this team were few and the needle-in-a-haystack factor was high.  This process needed to be automated.

There was another serious problem besides log volume.  I explained the systemic issues to my supervisors like this; “The security controls in our organization are like musical instruments in an orchestra.  We have firewalls, anti-virus, intrusion detection devices, file integrity monitoring, content filters, anti-spam, host security, and application security.  But right now each does security ‘solo’.”

Each control was managed by a different group.  Reporting was all hand constructed and carried to the security team.  The firewall manager would deliver the firewall report daily, intrusion detection was handled by the incident handling team once a week, anti-virus reports were delivered monthly by the IT staff, and so on.

The whole of the system was as reliable as clockwork: each piece did its part exactly as planned and yet each was still ineffective.  The whole process was too high-level to determine if a problem existed, too low-level to see the problem as it happened, incomplete because not all data was reviewed, and lacked the context to determine if a threat was real even if it was suspected.

The bottom line?  All controls play a different piece in the same symphony.  They need to work together to turn noise into music.

The promise of SIEM was that computers can solve large, complex and tedious problems faster and more accurately than people; as such they are the ideal tool to police themselves and their users.  We wanted the entire system of security controls in the enterprise working cooperatively, in harmony, and armed with the intelligence needed to protect the organization.

The emerging SIEM (SIM, SEM, or ‘master console’) technology was often focused on specific tools such as Intrusion Detection or Host Security that ‘extended’ into logging. Many critical systems had no logging whatsoever and companies withheld such features in an attempt to keep their proprietary systems closed.  It would take most of the 2000′s to get the message to vendors that 3^rd party auditing was a requirement.  Now SIEMs can be practical and more creative means of using them can be applied.

Once the orchestra is together, the Conductor can lead. It’s of utmost importance that the managers, investigators, analysts, engineers and operators hear the same song.  What SIEM needed and has achieved today the ability to connect logs to organizational regulations, policy, plan, procedures, organizational divisions, and even by individual project requirements.  Alerts can be tailored to correlate between identified events, known threats, and critical assets.  Reports can be automated and customized to fit any manner of output requirements rather than being limited hand-made spreadsheets.  And valuable metrics can be mined from the official record of events that the SIEM establishes.

Thanks to SIEM technology, logs can be reviewed properly, human resource requirements to review them are less, and can handle volumes that now may exceed tens-of-millions of pages of data per day rather than just 55,000.  Coverage now extends to the entire networked enterprise and information can be presented in a timely manner and in ways that are useful to all stakeholders.  There is no doubt to me, SIEMs are a key innovation for information technology and will be critical for what is shaping up to be a brutal future for security problems.

Although certain Trojans like Zeus that target banking credentials are put up for sale on the black market as crimeware kits, Qakbot does not seem to follow this pattern. While many kinds of Trojans take a more blanket approach to stealing data and passwords, Qakbot is actually designed to differentiate between the data stolen from target devices and other passwords it may have collected on non target machines. Another interesting behavior of the Qakbot is that it also acts as a worm in its attempts to spread via network shares. While this combination of worm/Trojan behavior is not unique, it certainly makes it more dangerous. And if that isn’t enough, Qakbot reportedly employs up to 7 different methods to ensure that it’s not being reverse engineered by security researchers.

Evidence points to the idea that there is a dedicated group of people behind this piece of crimeware. If that’s true, it seems logical that The Hartford Insurance Company will not be the last business to be targeted by the Qakbot.

With that being said, let’s take a look at what a typical Qakbot infection looks like.

First, the Trojan is VMware and if it detects that it’s being run on a VMware virtual machine it will simply not run. Once running however, a dump of the file’s strings from memory gives us quite a bit of insight into what the file will try to do. Evidence of the file’s attempts to thwart security researchers’ attempts can be seen in various places.

Here it checks for the presence of various .exes running:

And here’s another check:

Here we see references to URLs where stolen data will be dumped. Notice the DNS query?

Some information on the data it will be sending out including the version of qbot (qakbot) running:

Out bound IRC traffic:

Based on what we’ve seen in the strings, we can expect to see a variety of logged behavior generated by the Qakbot. Monitoring for unexpected outbound FTP, IRC and port 80 traffic is one way to identify potential Qakbot activity. Also, a shared folder on the network that’s designed to always be empty can be monitored for the presence of new files to capture worm-like behavior.

If you want to know more about how we can help you detect malware with log data, feel free to
contact us.