Compliance

LogLogic-Exaprotect deal reflects SIEM-log management bond

It’s not exactly a surprise that LogLogic acquired Exaprotect. The two partnered up in February to add Exprotect’s SEM engine as a module riding atop LogLogic’s log management/analysis platform.

The pending deal, announced Wednesday at RSA, is something of an indication that the log management and SIM/SEM/SIEM markets are becoming too closely integrated to distinguish. (Pick your acronym. At RSA this week, Forrester’s John Kindervag suggested “SIRS” — Security Information Reporting System, suggesting that these tools’ primary value was in reporting and compliance, rather than security).

In the end it’s all about collecting and analyzing information analysts can use for compliance, operational efficiency, forensics, and, maybe, security.

Regulatory compliance, particularly PCI, has driven sales of both log management and SIEM, transforming log management from a niche market to something of a must-have. Major SIEM vendors like ArcSight, seeing these hungry upstarts doing well, were quick to spin off separate log management products or modules to get a piece of the action.

Meanwhile, log management vendors have had some SIEM-like capability, a sort of SIEM Light. It makes sense that LogLogic is building on its success to provide a fuller package. Along with the SEM offering, the company announced  a database monitoring and auditing module (partnering with an unnamed DB monitoring partner) and Compliance Manager, automating compliance approval workflows and review tracking.

The Exaprotect acquisition also brings in Solsoft Change Manager, providing configuration management capabilities, which will round out the LogLogic package nicely for both compliance and operational control once the products are integrated.

SANS Log Management Survey is looking for the ROI

Good information security requires…good information.

That’s why logs are so important and why so many regulatory and industry directives require companies to not only gather but monitor, read and analyze them.

By the same token, if we’re going to get this log management thing right, we need to share our experiences and pain points with each other and the vendors who want to make their log management products more responsive to our needs, so we, in turn, will keep giving them money.

So, if you have not yet taken the fifth annual SANS Log Management Survey, please take a few minutes. The survey will be up through January. Obviously, the more respondents SANS gets, the more reliable the results.  The findings will be released at SANS WhatWorks Log Management and Analysis Summit to be held in Washington April 6-7.

The survey has evolved as organizations experience with log management has evolved, said Stephen Northcutt, SANS CEO. Compliance is now well established as a driver for developing and improving log management programs and deploying automated tools. In fact, the 2008 report showed that compliance was only the second highest reason for collecting log data, behind detection and analysis of security and performance incidents.

With this year’s survey, SANS wants to emphasize getting full value to leverage log management for security and operations.

“The biggest thing in the survey that’s new and different is looking for the ROI,” Northcutt said. “We’re trying to see what the biz case for this is; the compliance case is established.  Two years you had to go to the CFO and say, look, I need 200,000 bucks.  Here are the findings of the audit report. So, you spent the money and now you’re saying, ‘Gosh, what can I DO with this?’”

HIPAA violations cost Seattle health care provider

Interesting news on the HIPAA front. Seattle-based Providence Health & Services has agreed to a settlement over HIPAA security and privacy violations, the U.S. Department of Health and Human Services (HHS) announced last week. In what HHS called the first of its kind “resolution agreement,” Providence will pay $100,000 and implement a corrective plan after losing backup media and laptops containing personal health information in 2005 and 2006.

Previously, HHS’ Office for Civil Rights (OCR) and the Centers for Medicare & Medicaid Services (CMS), which enforce HIPAA’s privacy and security rules, settled complaints by requiring organizations to make changes to their security and privacy practices. A CMS spokesman said last fall that the agency preferred resolving problems rather than punishing mistakes, but this agreement with Providence may indicate that the government is stepping up HIPAA enforcement. A statement by Winston Wilkinson, OCR director, certainly seems to signal a change: “We are committed to effective enforcement of health information privacy and security protections for consumers. Other covered entities that are not in compliance with the privacy and security rules may face similar action.”

In the Providence case, backup tapes, optical disks and laptops containing unencrypted personally identifiable health information were taken out of two Providence home health care operations and later lost or stolen. More than 360,000 patients were affected. In addition to the fine, Providence agreed to revise its policies and procedures regarding safeguards for off-site transport and storage of electronic media containing patient information. It also must train employees on the safeguards, conduct audits and site visits of facilities, and submit compliance reports to HHS for three years.

Why are security pros dealing with compliance?

The dawn of the age of IT compliance has had any number of consequences for IT staffs in general, and security teams specifically. Now, instead of simply worrying about whether the network is running properly and the good guys can get in and the bad guys can’t, security specialists have to consider how every modification, deployment and installation they make might affect the company’s compliance with PCI DSS, Sarbanes-Oxley or HIPAA. Not only that, in many organizations, the security team is explicitly responsible for the overall compliance effort itself, on top of its regular duties.

At a seminar on compliance that SearchSecurity.com put on this week, I asked for a show of hands among the attendees on who was a trained security professional and who was more of a compliance and policy specialist. Somewhere north of 90% of the people identified themselves as security pros. And yet, here they were at a seminar on compliance, learning the ins and outs of every regulation under the sun and how to stay on the auditor’s good side. Many of these same people said that their companies also had a separate compliance group, but the security teams still shouldered a lot of the day-to-day compliance burdens. And these were professionals from some of the larger financial services, health care and retail companies in the world.

What this tells me, and what the attendees said themselves, is that even the biggest, most highly regulated companies still don’t have this compliance thing licked. A lot of the talk I hear at conferences and trade shows is about how to become compliant with one product, or framework or set of policies. Those things are certainly vital components of a compliance program, but the ugly truth is that regulations and networks change and shift constantly, and even if you passed an audit this morning with flying colors, you were probably out of compliance by the time you got back from lunch.

I would wager that the number of security professionals who got into the industry hoping to work their way into a compliance role approaches zero. But, virtually every expert I talk to about this tells me that there is more regulation coming in the near future and that things are going to continue getting more and more complex. This means more time poring over arcane legislation and industry requirements and less time solving interesting security problems. At that same seminar, I asked our two speakers whether they thought compliance should be the job of the security staff, and the they both said no, compliance demands its own dedicated staff and the security people are too busy. Ah, well. It’s certainly not pretty, but there it is.

Orphaned accounts overlooked

User accounts that stay active after an employee leaves an organization are a big problem in the enterprise, according to a survey released today by security software company Symark.

Forty-two percent of the 850 executives surveyed said they did not know how many orphaned accounts exist in their organization. Thirty percent of the respondents, which included IT and human resources executives, said they had no procedure in place to find orphaned accounts.

The survey, conducted by eMedia USA for Symark, also showed that for 30 percent of survey participants, terminating an account after an employee leaves takes more than three days. For 12%, the process takes more than a month. About 27% of the respondents said that more than 20 orphaned accounts currently exist in their organization.

In a prepared statement provided in Symark’s survey announcement, Sally Hudson, a research director at IDC, said the orphaned account problem often is a result of overworked IT staffs. Obviously, organizations would do well to give them time to shore up this glaring security gap.

Fighting security FUD

I recently tripped over a blog write-up from independent analyst Eric Ogren about his irritation with security vendors using FUD to sell products. It’s an older posting from 2006 but his message is as relevant today as it was two years ago.

Building his case around a threat report Websense released at the time, he wrote, “I’m not sure that the world is better off with yet another security vendor telling us that Phishing, malicious websites, malicious code, hacking tools, P2P, IM and Chat attacks have all increased.”

He dismissed the report as FUD marketing designed to create demand for security products, but that he believed the reports could actually have the opposite effect by pointing out the futility of security products to stop attacks.

He’s not the first security expert to rail against the FUD factor. Security luminary Bruce Schneier has devoted huge chunks of his time speaking out against security ‘theatre’ — policies and products that are more about offering the perception of security rather than addressing the actual risks.

And, rightly or wrongly, the Apple crowd is constantly crying FUD whenever something is written about a security flaw or malware affecting their beloved Macs.

I bring up the issue because it’s long been a source of irritation for me. As a security writer, I’m constantly buried beneath tons of voicemail and email from vendors looking for attention, and the PR machinery almost always uses FUD to make a case for buying the latest compliance-out-of-the-box appliance or the “first of its kind” bot/spyware/worm/common cold zapper.

Along the way, the PR community likes to invent new words or phrases to define the threat, many of which start with the letters “ph” (phishing, pharming, phlooding).

I’ve been looking back through four years of writing for the sake of nostalgia. The big thing that strikes me is that we’ve written a lot of stories about the latest flaw or exploit and someone is always banging on the alarm bell with a hammer.

In the final analysis, it’s prudent to flag the latest flaws and exploits because IT security professionals need to be aware of these things and incorporate the information into their patch management process. Heck, alerting them to these things is what we’re here for. But the tone and level of alarm that should go into these stories is always something we wrestle with.

Everyone has a role to play in information security, from the IT pros to the vendors, analysts and media. But from the content I look back on, I see little evidence that vendor-generated fear has ever made a difference.

Warnings about some flaw or exploit opening the door for a catastrophic Internet-ending event are never followed by the big doom. On the other side of the spectrum, the epidemic of data security breaches shows that all the FUD and security spending in the world can’t prevent the bad guys from punching through. The recent Hannaford supermarkets breach proves you can respond to the fear and spend a lot of money on new technology and still get whacked.

I recently asked Rhode Island-based network engineer Edward Ziots whether he jumps at every exploit warning. Here’s what he told me by email:

“We don’t jump, it would be imprudent to do so. Basically I read up on how the exploit works, even look at the code offline to ascertain if it would be available to be downloaded or how much effort would it take to be in a working exploit. Next, you basically need to adjust your risk assessment based on the controls you have in house, and how many systems could be affected and in what manner.

“Lastly communicate the adjusted risk assessment to management, security and await decision on whether to raise priority for patching, or to deploy other security measures to mitigate until all systems can be patched.

“Honestly, it makes it very difficult with exploit code in the wild and reports of working exploits not to raise your risk level and deploy extra manpower and time and effort to get all systems patched. It’s just due diligence.”

My advice is to take the FUD with a grain of salt and remember that while cyberspace is a dangerous place and you’ll sometimes have to raise your level of alertness as Ziots does, most enterprises will survive with the proper mix of security tools, policies and a calm awareness of the risks.

About Security Blog Log: Senior News Writer Bill Brenner peruses security blogs each day to see what’s got the information security community buzzing. In this column he lists the weekly highlights. If you’d like to comment on the column or bring new security blogs to his attention, contact him at bbrenner@techtarget.com.

RSA 2008: Firm makes log management a priority for compliance

Ira Hanson-Ralph of EnCana explains why the oil and gas exploration company made log management a priority as part of its compliance program. Hanson-Ralph is EnCana’s group leader of IS compliance and controls monitoring. The interview was conducted at RSA Conference 2008.

RSA 2008: Financial industry security challenges

(ISC)2 Executive Director Ed Zeitler talks about the unique security challenges facing the financial industry and whether the current turmoil in the financial markets could put a strain on IT budgets. Zeitler has 23 years of experience in developing, implementing and managing information security programs at financial firms. Most recently, he served as chief information security officer (CISO) for Volkswagen Credit, where he created and implemented its information security program. He also served as CISO for Charles Schwab & Co., Inc., Fidelity Investments, Bank of America and Security Pacific National Bank.

Your PCI questions answered

nbsp;SearchSecurity.com recently conducted a virtual trade show on PCI DSS. It was a great success. During his live question-and-answer session Security Curve Founding Partner Ed Moyle had an overwhelming number of audience questions. Ed followed up on all the questions in this PCI DSS Q&A we posted on the site this week. He touches on some pretty in depth questions on private networks, self-assessment, segmentation and more. By the way, our PCI DSS compliance topic center is a great place to find a wealth of information about how to solve your PCI compliance issues.