The 2011 SF ISACA Fall Conference schedule for next Tuesday has been updated.

T2 In-Depth Seminar Risks and Controls in Cloud Computing, which I wrote about earlier, has the following changes.

1. The presenters will not be required to speak to NIST cloud audit guidance. Each is expected to present their own.
2. Amazon will now open and close the seminar. The panel moderated by PwC at the end of the presentations has been replaced by the PCI DSS QSA firm for Amazon, IO Active. In between the AWS presentations will be salesforce.com and myself.

Presenters:

• Chad Woolf, Compliance Leader, Amazon Web Services
• Scott Gregory, Information Security Compliance Leader, Amazon Web Services
• Robert Fly, Head of Product Security, salesforce.com
• Crispen Maung, Sr. Director of Technology Audit and Compliance, salesforce.com
• Davi Ottenheimer, President, flyingpenguin
• Robert Zigweid, Principal Security Consultant, IO Active

Session Abstract:

Do you want to know where data resides in the cloud? How data is protected and secured in the cloud? Who has access to your data? What happens when your cloud provider dissolves? Is there a disaster recovery plan. Find the answers to these questions and the latest risks, controls and audit guidelines in the Cloud Computing environment in a one day track that will be presented by leading cloud providers and control experts. Each presentation is interactive and will include a Q&A session. You will find yourself confident about your understanding of the risks and controls in Cloud Computing after this daylong session.

This should be a spirited and detailed look at the current state of compliance in the cloud. Hope to see you there.

vNinja.net poses the challenging question “Why Can’t I Syslog my VMware ESXi Installation?”

Since ESXi supports, and actively encourages, the use of an external Syslog service for log file safekeeping and monitoring, shouldn’t the installation logs for ESXi also be logged externally if configured?

[…]

I was very surprised to see that there is no option to configure syslogging until after the installation is finished and the host configuration script(s) runs (ks.cfg).

By using a ks.cfg script you can automatically configure syslog settings, but since that happens after the installation is done, and the host is potentially rebooted, the installation logs are lost (ESXi logs are not persistent by default) unless you run something that copies them over to another location before the reboot happens.

Philosophically this reminds me of what Sartre wrote in Existentialism and Humanism

What do we mean by saying existence precedes essence? We mean that man first of all exists, encounters himself, surges up in the world — and defines himself afterwards.

In other words it takes an external force to enable a remote log configuration at a point earlier than a system itself has any awareness. An upgrade is an easier situation to address, since the system is already aware of itself. A first build, however, at the early stages with few bits in place begs the question of when installation really begins. Before a system exists it will not be able to log remotely.

The RSA Beijing Conference has had many sessions on compliance and cloud. NIST guidelines have come up repeatedly along with FISMA and other regulation references. The American civilian organization is clearly a global leader in this field and followed closely in China; however, I have not seen any mention yet or discussion of yesterday’s announcement on 500-293:

• NIST Special Publication 500-293, US Government Cloud Computing Technology Roadmap, Release 1.0 (Draft), Volume I High-Priority Requirements to Further USG Agency Cloud Computing Adoption
• NIST Special Publication 500-293, US Government Cloud Computing Technology Roadmap, Release 1.0 (Draft), Volume II Useful Information for Cloud Adopters
• NIST US Government Cloud Computing Technology Roadmap Volume III – Technical Considerations for USG Cloud Computing Deployment Decisions (First Working Draft)

The PCI SSC has invited QSAs to send input after November 1, 2011 on DSS 2.0. They want to hear about areas that need to be “clarified, updated or changed to enhance the protections for cardholder data.”

An online tool as well as a spreadsheet are available but each QSA organization is allowed only 5 feedback items in this phase of the next three year period.

December 31, 2011 marks the sunset of version 1.2.1 for both the DSS and PA-DSS