Posts tagged: 'information security'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.http://blog.logrhythm.com/tags/information-security/feed
The National Institute of Standards and Technology (NIST) has drafted a document that specifically addresses Personally identifiable information (PII). The document will become Appendix J of SP 800-53. This means FISMA is likely to change to include these new privacy controls.
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:
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;
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.
If it didn’t come across as mind-bendingly smug, I might describe the Sega hack as ‘old news before it even broke’. But it is. Old news. Another global digital meganame falls prey to malicious, possibly mafia- or triad-backed ill-doers.
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 3rd 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.
While the recent Hartford Insurance breach, the subject of an earlier post by Dave Pack, didn’t make a lot of noise, it’s interesting to see an old piece of Malware (first discovered in 2007) like Qakbot still making its rounds in 2011. There are a number of things about this malware that make it particularly interesting.
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