Zen 2.0

According to this CNET news,

A Democratic member of the U.S. House of Representatives said Thursday that she plans to introduce legislation next week that would force Internet providers to record customer information for one year.

Personally I think it’s stupid for the gov’t to create such mandate, especially for the reasons they are citing.

because members of Congress have “learned that Internet service providers and social networking sites have information that law enforcement needs when investigating pedophiles online, and that is the IP address on a particular date and time that will help identify those involved,”

It’s one thing that ISPs retain logs as best practices, e.g., for forensic analysis and troubleshooting, it’s totally another for the gov’t to make it a mandate.

I certainly don’t want anyone to nose around in my stuff. Total violation of privacy if you ask me.

Have been reading quite of bit of stuff on the various best practices and frameworks such as COBIT, PCI, ISO17799, ISO20000 and ITIL.

I think one of the best description of COBIT vs ISO vs ITIL is the article The Big Picture: ITIL as an Integrated Framework written by Kevin LeBlanc:

All these frameworks can add value to just about any IT shop depending on the specific business needs of the parent organization. However, the best fit-for-purpose combination benefiting ITIL practitioners may point to CoBiT (audit), ITIL (improve) and ISO17799 (secure).

This description clearly defines the role of each of these frameworks and how they complement each other. Any organization wanting to improve operational efficiency should adopt these 3 frameworks.

So a few days ago, 9/7/06 to be exact, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International jointly announced the formation of an independent council, called PCI Security Standards Council, designed to manage the ongoing evolution of the Payment Card Industry (PCI) Data Security Standard.

As its first order of business, the PCI Security Standards Council released PCI DSS v1.1. The Payment Card Industry Data Security Standard (DSS) v 1.1 has replaced the DSS v. January 2005, and the PCI Security Standards Council will no longer recognize DSS v. 2005 after December 31, 2006.

Here are some of the interesting documents.

• PCI Data Security Standard v1.1
• PCI DSS Audit Procedures
• Summary of Changes

One change that everyone took notice was the language around data retention.

In v1.0, sub-requirement 10.7 said

An audit history usually covers a period of at least one year, with a minimum of 3 months available online.

In v1.1, it now says

Retain audit trail history for at least one year, with a minimum of three months online availability.

The change is significant. It now means everyone who processes, stores or transmits credit card information MUST retain audit trails for a minimum of a year. Whereas before in v1.0, it was not a requirement.

There are other changes worth noting.

Changes to requirement 1.2 and 1.3

v1.1 removed some of the specific protocols and is now using phrases like “necessary for the cardholder data environment.” The question is who determines what’s necessary for the business?

Addition of 2.4

This requirement basically put all hosting providers including ISPs, MSPs and MSSPs in the same categories as merchants. The hosting providers must now conform to PCI DSS.

In addition, the hosting providers must ensure that the hosting customers can only see data that belong to them.

Changes to 5 and 5.1

v1.1 both expanded and restricted the scope of systems that require anti-virus software. It expanded the scope by stating “all systems commonly affected by viruses” instead of the old v1.0 saying, “all email systems and desktops.”

It restricted the scope because it added a note saying that UNIX-based systems or mainframes are typically not ffected by viruses.

There’s also a new sub-requirement 5.1.1 that requires anti-virus software to also detect, remove and protect against spyware and adware.

Added clarification to 6

A note is added to requirement 6 saying that

Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations.

I am somehow seeing that many organizations will be using this as an out for not installing patches.

Auditor: “oh you don’t have patch X installed.”
IT Admin: “oh sorry, we haven’t tested it sufficiently to know if it will downgrade our security settings.”
Auditor: “but you are suppose to test this.”
IT Admin: “oh we know, but the PCI DSS doesn’t say when we have to do it”

Addition of 6.6

Sub-requirement 6.6 says you need to protect your web-facing applications by having someone do a code review of your application or install an appliation layer firewall infront of them.

I can just see a jump in sales for the Cyberguard, Symantec Enterprise Firewall and others.

There’s a very interesting thread being discussed on the log-analysis list. The topic is on “Log integrity handling on central logsystem.”

I think the general consensus is that log signing ALONE is not going to be enough, and that signing just the filtered log is also not enough.

Very interesting read. Should definitely check it out.

I agree with Marcus… log signing [alone] is not going to make or break
a court case — it [alone] might almost be asking for trouble.

As I pointed out later in my earlier response, the big deal is to get
all possible logs, even if they don’t appear relevant to the particular
matter — so you can show the trace, other anomalies (or lack of other
anomalies).

Register for this event

This is quite a webcast. LogLogic did one not too long ago and there’s such a demand that it will be re-broadcasted LIVE.

Ron Lepofsky from ERE Information Security had a great article, CFO responsibility to fund log analysis for Sarbanes-Oxley compliance, on SC Magazine.

Here’s a summary SC Magazine provided:

Corporations responsible for complying with Sarbanes-Oxley, face great hurdles with a basic compliance objective: analysis of their (server and security device) event logs. Some do not for lack of awareness, and others because of the difficulty (and cost) of performing the analysis. Further, issuers erroneously place the cost burden of SOX compliance on the IT security department, when the costs should be borne by the CFOs SOX compliance budget.

A couple of interesting and relevant articles from CSO Magazine.

• Trends 2005: Risk And Compliance Management by Michael Rasmussen.
• Clearing Up the Muddled Security Management Market by Andrew Braunberg

An eWeek article explains:

Beginning next week, companies that have public float, or publicly owned shares, exceeding $75 million and that have fiscal years ending on or after Nov. 15 must comply with internal control reporting and disclosure requirements per Section 404 of the Sarbanes-Oxley Act of 2002. Companies with less than $75 million in public float have until July 15 to comply with Section 404.

As my previous blog has mentioned, you need to make sure that

• records are logged in reasonable details, accurate and reflect the transactions
• assurance that transactions are being recorded
• assurance that prevention or timely detection of unauthorized acquisition, use of disposition of the assets that could have a material effect on the financial statements

Log management is a critical component in accomplishing this task.

Do you have an infrastructure and solution in place to review your logs?

p.s. Thanks to joatBlog for the article link.

One of the most talked about regulations these days is obviously Sarbanes-Oxley. Below is a quick summary of Section 302 and 404. Remember, if you are a CEO or CFO, don’t screw up. Otherwise you will be fined up to $1 million and/or up to 10 years in jail.

Section 302