Planet SCM

In my post earlier this week on the latest FISMA ranks, I referenced a quote by Virginia Rep. Tom Davis.

He posted further comments on the Hill Blog Monday that are worth reading. He lets the Department of Homeland Security off the hook a bit, but really expresses frustration with the Department of Defense.

Good to hear directly from our legislators, rather than in a press clipping.

The latest grades are out for the Federal Government when it comes to information security. According to Government Technology, Rep. Tom Davis, ranking member of the House Government Oversight and Reform Committee, gave the federal government an overall grade of C-minus when it comes to safekeeping information on government computer systems. After being mired with D's for the past three years, a C- shows some improvement, but still leaves a lot of room for growth.

While the Department of Justice and the Department of Housing and Urban Development showed the most improvement, with Justice jumping from a D to an A-minus, and HUD from D-plus to A-plus, there were also some significant declines. NASA fell from B-minus to D-minus and the Department of Education, which fell from C-minus to F.

As Rep. Mike Turner, ranking member of the Information Policy, Census and National Archives subcommittee, said in the Government Technology article, "It's troubling that some of the agencies with the most sensitive information continue to score poorly on this. The report identifies problems in federal agencies which include the Department of Defense, the Department of State, and the Nuclear Regulatory Commission."

However, on closer inspection, two of the biggest grade improvements came as a result of simply documenting the inventory of systems. You'd think this was a very elementary step to take for securing sensitive data.

As the article points out, "more improvement is needed in how systems are configured from a security standpoint and for training for employees with significant information security responsibilities."

Nobody in government IT should be satisfied with this improvement. Average compliance scores are one thing, but they most likely mean better than average vulnerability to exploits.

The Health Insurance Portability and Accountability Act, better known by its acronym (HIPAA), was passed by Congress way back in 1996. Yet, in spite of its being on the record books as long or longer than almost any other major regulatory compliance mandate facing IT departments, it has clearly been the proverbial "red-headed stepchild" when it comes to enforcement.

The Office of Civil Rights is actually tasked with enforcement of the law. According to a post by Rebecca Herold, "The Department of Health and Human Services (HHS) Department Office of Inspector General (OIG) appears to be making movement on their promise in their Fiscal Year 2007 Work Plan to 'review HIPAA privacy and security implementation under Medicare and Medicaid to identify key issues in the HHS information technology initiative.'"

Herold cites two references in the April 9 issue of Privacy and Law Report, from the Bureau of National Affairs (BNA, a subscriber site) as potential signs of increased enforcement. The report states auditors will reportedly assess Piedmont' Hospital in Atlanta's compliance with the HIPAA security rule and indicates the Centers for Medicare & Medicaid Services (CMS) are also planning increased enforcement.

Yet, in the same post, Herold shares these paltry statistics from the Office forCivil Rights, the governing body responsible for HIPAA enforcement. "Through February 28 [the department] had closed 77% of the 25,662 complaints it had received. The OCR referred 373 of the complaints to the Justice Department for criminal investigation."

If my math serves me correctly, that means that, of the nearly 20,000 complaints the OCR "investigated", less than 2% were worth further action?  COME ON!!

Oh, and why is Health and Human Services promising any improvements if it's up to the Office of Civil Rights is the one that has got to be the ones to step up and make improvements in enforcement?

Sounds like a pretty empty promise to me.

Publicly-traded companies in America have been through a couple rounds of SOX audits, but companies in other parts of the world will be getting their first taste of similar compliance requirements in the next year.

J-SOX, the Sarbanes-Oxley-inspired name for the Financial Instruments and Exchange Law, will go into effect in April 2008 for approximately 3,800 companies listed in Japan, along with their foreign subsidiaries. Like SOX, the Japanese regulation was also enacted in response to accounting scandals involving companies like Seibu Railway Co., Livedoor Co., and the Murakami Fund.

According to an article by Thomas Hoffman, some companies are already being proactive. Fuji's largest North American subsidiary is documenting its hardware, their IP addresses, and the software running on them. In addition, they are documenting the controls it has in place for several IT processes that could affect the company's financials. Tokyo Electron America, Inc., based in Austin, TX, is tracking and monitoring their global IT systems and documenting the security safeguards they have in place for each system.

If there is any lesson Japanese firms can learn from the first two years of SOX, it is to not procrastinate, particularly with getting the people, processes, and technology in place that will weave compliance into the overall fabric of daily activity in the IT department. Otherwise, it becomes an almost total interruption to the IT department's responsibility to overall business services.

Sounds like some American subsidiaries may be heeding the lessons learned from other American companies and passing it on to their Japanese counterparts...and that's a good thing.

Luther Martin made a case for the repeal of SOX in a post last week. His case was based on a 1947 ruling by Learned Hand that, in effect, said the cost of mitigating risk should not exceed the cost of the risk itself. Martin goes on to compare the cost of SOX compliance to the potential risks to make his case.

I agree that costs for SOX compliance have been unnecessarily high. The compliance law was intentionally vague in what controls it would measure, which has led to a lot of guesswork by IT departments and auditors alike as to what are reasonable controls to audit. Companies were also ill-prepared to face the first few rounds of SOX audits, so a lot of manual effort was required.

However, the SEC, through the PCAOB, is putting a lot more emphasis on ensuring greater consistency in SOX audits. On the IT side, many organizations have implemented automated solutions to identify and manage information on key IT controls. These investments should significantly reduce the cost of SOX and other regulatory compliance audits, as well as provide other benefits to ensuring the security, availability and performance of business services provided by IT.

I disagree with his estimates for potential fraud. $1 million is too low, in most cases. Most fraud cases that are disclosed have the potential to reach into the tens of millions. 

Eliminating SOX would be a step backward. A better course of action would be for legislators, the SEC, and PCAOB to follow the lead taken by credit card companies with the PCI DSS or NERC with its new standards. These regulations are more comprehensive (PCI still needs to work on physical security measures as evidenced by the recent PIN pad fraud at Stop n Shop) and specific in exactly what they will require and audit, giving organizations a real roadmap to achieve compliance objectives.

One area where I do agree with Mr. Martin is in making sure organizations don't lose sight of information security, just for the sake of compliance. As he says in his post, "While SOX addresses risks that are perceived to be important, at least by the US government, many information security projects can address risks that are very real. But with the reallocation of funding from information security to compliance, many of these real risks are going unaddressed."

Can and should SOX be updated and better defined? Yes. Should it be eliminated? No

Over the four years, the 25 member draft team of the North American Electric Reliability Council worked to craft the Permanent Cyber Security Standards (CIP). The standards were released in May and, according to many sources, including Michael Fitzgerald's article in CSO magazine, appear to be the first set of security standards to address every aspect of cybersecurity, including operation, management, and even the physical safety of cyberassets.

The standards aren't just written well - they have a couple of other huges pluses on their side. One, they were adopted by 88% of the NERC members. I think in political terms, they'd call that a mandate!

Second, the standards have serious enforcement with both NERC itself as well as the Federal Energy Regulatory Commission being able to impose fines.

Even other industries are paying attention. The nuclear power and water industries are both interested in possibly adapting the standards for their industry's needs.

So, what's the problem? For the standard to really have legs, it needs to be approved by the FERC. They've had the standard in front of them since August - more than six months ago. Given the rigorous process the draft team undertook and the overwhelming adoption among NERC members, it's time for FERC to move this forward.

For ongoing commentary on this subject, I recommend reading Dale Peterson's blog. Dale has been writing on the entire process since the draft team was first formed.

The failure of many federal agencies on their FISMA audits has been widely publicized, especially those who have the dubious distinction of getting an "F". Back in school, getting an F usually wasn't an issue of comprehension in most cases. It was usually a failure to do the basics - like show up to class or study.

In Wilson P. Dizzard III's article on the State Department's efforts to improve their failing FISMA grade, CIO James Van Derhoof clearly says it was the failure to do the basics that was the Achille's heel for the department.

Van Derhoof sums up their failure by identifying three key areas of weakness:

1. No centralized patch management procedures
2. Configuration management was a static, "once every three years" process that didn't account for configuration changes at all
3. Lack of training of information systems security officers

Good to see they recognize their problems; bad to think that we're still struggling at such an elementary level of infrastructure security and compliance.

Wouldn't it be nice to always be in compliance? Why should an audit always be an event where everyone has to drop everything important they were doing to franticially start preparing for anything the auditor might throw at them?

In today's world of explonentially growing compliance regulations, organizations must automate their compliance-readiness activities. It just becomes part of the business. This is the only way for organizations to get beyond the time-consuming event compliance audits are today. To read more on the value of automating compliance reporting, David Greene of BMC has a nice article addressing this issue on itworld.com this week.

Wouldn't it be nice to always be in compliance? Why should an audit always be an event where everyone has to drop everything important they were doing to franticially start preparing for anything the auditor might throw at them?

In today's world of explonentially growing compliance regulations, organizations must automate their compliance-readiness activities. It just becomes part of the business. This is the only way for organizations to get beyond the time-consuming event compliance audits are today. To read more on the value of automating compliance reporting, David Greene of BMC has a nice article addressing this issue on itworld.com this week.

I will continue with my posts on securing VMware ESX servers tomorrow, but wanted to give some attention to the recent comments made by Alan Paller of SANS on the need to overhaul how government assesses security - starting with FISMA.

Paller offers two broad fixes for the security challenge facing government. The first is to stop blaming the user for problems, and require that vendors ship well-designed products that are securely configured by default. He also called for using "attack-based" metrics in measuring security compliance.

Overall, I agree with Alan's approach. Certainly, the poor grades federal agencies have received the last few years on their FISMA report cards make it clear something needs to change. It is refreshing to see his recognition that configuration settings play in security. I do have to take some issue with the idea of "products securely configured by default."

The reason for configuration settings, by their very nature, is because "one size fits all" doesn't work when it comes to how IT environments operate in different organizations. It is simply impossible to expect any product to come "securely configured out of the box." It's automating controls around configurations and the ongoing changes to them that is critical to improving security and, in the case of the federal government, compliance audit results.

I will continue with my posts on securing VMware ESX servers tomorrow, but wanted to give some attention to the recent comments made by Alan Paller of SANS on the need to overhaul how government assesses security - starting with FISMA.

Paller offers two broad fixes for the security challenge facing government. The first is to stop blaming the user for problems, and require that vendors ship well-designed products that are securely configured by default. He also called for using "attack-based" metrics in measuring security compliance.

Overall, I agree with Alan's approach. Certainly, the poor grades federal agencies have received the last few years on their FISMA report cards make it clear something needs to change. It is refreshing to see his recognition that configuration settings play in security. I do have to take some issue with the idea of "products securely configured by default."

The reason for configuration settings, by their very nature, is because "one size fits all" doesn't work when it comes to how IT environments operate in different organizations. It is simply impossible to expect any product to come "securely configured out of the box." It's automating controls around configurations and the ongoing changes to them that is critical to improving security and, in the case of the federal government, compliance audit results.

It's been 5 years since the Enron scandal was exposed, eventually leading to the passage of Sarbanes-Oxley and increased scrutiny of the controls surrounding corporate financial information. A lot has been written about the effort that has surrounded complying with Sarbanes and other regulatory compliance laws. With several years of history behind us, some of the real costs are coming to the light of day - and it's not cheap.

In a recent interview on baseline.com, Gartner analyst French Caldwell shared a recent conversation with the CIO of a large bank who said his IT Managers are spending roughly a third of their time on compliance issues, triple the amount of time spent a decade ago. That's a phenomenal amount of time being spent on something that is not driving business initiatives.

In a Gartner survey on Sarbanes-Oxley released this past September, it was reported that 82% of organizations are investing at least 5000 hours a year on compliance, with 46% falling between 5000 and 20,000 hours annually. Based on any reasonable hourly rate, this represents a significant investment of IT time. Of concern to small and medium sized business facing their initial SOX audits, the size of the firm had no bearing on the amount of hours invested. Proportionally, that should mean a far greater percentage of IT staff will need to be devoted to compliance, barring a better alternative.

The survey found that many organizations found the controls required to be far broader in scope than they'd anticipated and the majority of deficiencies or weaknesses (36%) were related to IT Systems, Policies, Controls or Documentation. Of those deficiencies, a full 20% revolved around weakenesses in identity and access controls.

These figures are alarming, especially now that we are several years into SOX audits and vitually every organization is now facing multiple audits.

As the survey report concludes, "Compliance does not generate profits, but it does take up lots of management time and attention.The more that compliance can be automated and made inherent in systems, the more time then that management can direct to those activities that advance the company's performance and profit."

Couldn't have said it better.

They're coming fast and furious. The latest federal compliance rule went into effect last Friday, December 1st.

The new rules are related to electronic discovery of documents in civil cases. The rules specify requirements for submitting electronic documents - likely to include e-mail and possibly even instant messaging logs, depending on future case law - as evidence in civil litigation.

According to an article in Computer World, the rules require companies involved in civil litigation to meet within 30 days to decide how to handle electronic data - including what must be shared and in what media format.

Failure to preserve electronic information could prove incredibly costly. In May 2005, Morgan Stanley was fined $1.5 billion when a judge ruled they'd failed to preserve electronic information adequately. Yes, that really was billion, not million!

This new rule just adds to the growing nightmare for IT departments. Now, you're being asked to store everyone's communications for an undetermined amount of time or face huge fines, while knowing full well that these communications are going to be loaded with personal information that you're required to protect by some other regulatory compliance.

In our litigious-happy society, you're going to want to pay attention to this one.

I was on Tim Whitehorn’s blog site on Electronic Payment Security this past week. Whitehorn is the founder and CEO of ServiceU Corporation, a Level 1 Payment Card Industry Service Provider, so he has first-hand experience with just how demanding PCI compliance is becoming.

In a recent post, Visa Issues Alert and Steps Up PCI Enforcement, Tim shared that Visa, in conjunction with the US Chamber of Commerce, has published an alert that identifies the leading causes of data breaches.

The five leading causes of card-related breaches are:

1) Storage of mag stripe data
2) Missing or outdated security patches
3) Use of vendor supplied default settings and passwords
4) SQL injection
5) Unnecessary and vulnerable services on servers

Recent news stories make it clear Visa is going to be vigilant in ensuring merchants and service providers comply with PCI data security standards.

Robin Sidel, of the Wall Street Journal, reported that, beginning October 1^st, Visa began focusing on compliance among its largest US merchants – a total of 334 merchants who collectively represent nearly 50% of Visa’s annual US volume. The GreenSheet reported that Visa has already cited approximately 20 level 1 merchants with fines ranging from $10,000 to $100,000 per month for failure to comply.

It is clear that Visa and all of the other major credit card companies are serious about ensuring merchants and service providers implement controls in their IT infrastructure to protect consumers and their privileged credit card information.

I’ve spent a great deal of time reviewing PCI Data Security Standard 1.1 released in September. I’ve taken my findings and created a four-part web presentation detailing each of the 12 requirements and how you can ensure you are prepared to pass your next PCI DSS audit.

After you’ve viewed these presentations, I’d like to hear your feedback.

Back in the spring, I brought to light a new regulatory compliance requirement that would affect the nation’s energy companies by the beginning of 2007. With the deadline just a few months away, it appears that energy companies are finally trying to come to grips with what they must do to achieve compliance.

To bring you up-to-speed a bit, back in August 2003, the Northeast was hit with a massive power blackout that left nearly one million people without water and 50 million without electricity, and closed down twelve airports. In response, in August 2005, Congress and the Bush administration enacted the Energy Policy Act, which mandated new security regulations for the industry.

Now, energy companies are scrambling because some of the new rules will become effective January 1, 2007.  Complicating matters is the fact that most energy companies rely on massive systems control and data acquisition (SCADA) programs, which weren’t really designed with security as a consideration, to manage their resources. These programs make it challenging to work with antivirus software and are tough to patch. And, increasingly, the SCADA systems reside in the same network as other business applications, increasing the percentage of the infrastructure that must meet regulatory controls.

Securing these systems is a serious matter. In a recent article, Jay White, global architect for information protection, policies, and standards in Chevron’s IT division, said, “SCADA systems manage valves and pressures. They’re mission-critical. If you lose control over them, you could have an irreversible environmental impact.”

The problem remains the same as other current regulatory compliance laws—acceptance. Too many companies are doing everything they can to avoid having to comply, rather than embracing the value setting IT controls will add in streamlining their IT services and providing improved security, performance, and availability for their business services.

Duke Energy, a diversified energy company with a portfolio of natural gas and electric businesses, both regulated and non-regulated, and an affiliated real estate company, acknowledged in the article that they’d fought the imposition of CIP (Critical Infrastructure Protection) rules, the nine rules created and enforced by the North American Electric Reliability Council (NERC). “There’s a lot of push-back from industry on this,” said Sharon Edwards, project manager for implementing cyber security guidelines at Duke Energy.

Given the significant risk if an energy company’s SCADA systems are exposed to hackers or terrorists, wouldn’t you think they’d be more proactive about this? I’d love to hear your thoughts on why organizations aren’t taking compliance issues more seriously.

This month’s edition of Information Security magazine reveals that the North American Electric Reliability Council (NERC), the oversight body for the U.S.’s bulk electric systems, will unveil new compliance standards focused on procedural changes related to the protection of critical infrastructure.

According to the article, security managers at electric utilities will see the biggest change in the area of documentation. “Security managers will have to demonstrate that processes and procedures are in place, policies are enforced, and assets are tracked. External and internal security audits will also become a way of life”, the story states.

Lynn Constantini, NERC chief information officer, states, “As long as you have a good understanding… of your operational networks and commercial networks, and put controls in place…, that’s what is important.”

It is clear that if you are not currently faced with complying with a government regulation centered on protecting electronic data, you soon will.  Taking the initiative now to invest in an automated solution for identifying, tracking and reporting on your critical configuration controls will not only save you from a costly manual exercise in the future, it will provide you with a more efficient IT operation today. Remember, it’s only a matter of time before it’s your turn anyway.