Chief information security officer

Podcast: OWASP’s Hess on security and compliance in the cloud

Today’s episode features an interview with Georg Hess about Web application security and compliance in the cloud. Hess is the founder of application security provider Art of Defence and current German chapter head of the Open Web Application Security Project (OWASP).

The OWASP membership includes corporations, educational organizations and individuals from around the world. OWASP’s community works to create freely available articles, methodologies, documentation, tools and technologies.

 

 Podcast: OWASP's Hess on security and compliance in the cloud [23:41m]: Play Now | Play in Popup | Download

When you listen to the podcast, recorded by associate editor Alexander B. Howard, you’ll learn the answers to the following questions:

• How are the security challenges that OWASP advises others on changing?
• OWASP recently published an Application Security Verification Standard. What does the standard mean?
• What does establishing such a standard mean for chief information security (CISO) and compliance officers who are considering cloud computing?
• What other security standards are being established for the cloud or need to be created?
• What compliance issues do companies face when implementing cloud computing?
• How can cloud providers offer secure cloud offerings?
• How can security and compliance officers confirm that they are doing so?
• What do banking and health care CISOs who are considering adopting cloud models need to know?
• How are threats to Web application security evolving?
• What do compliance and security officers need to know — and do — to respond?
• What other regulations do compliance officers need to be aware of in 2009?

Kodak CISO on meeting today’s compliance challenges

In this IT Compliance Advisor podcast from SearchCompliance.com, associate editor Alexander B. Howard interviews Bruce Jones, chief information security officer (CISO) at Eastman Kodak Co.

Over the course of the wide-ranging interview, recorded on-site at RSA Conference 2009 in San Francisco, Jones discusses the challenges he faces as the CISO for a global multinational company. Listen to the podcast to learn:

• What innovations he has introduced to meet today’s compliance challenges.
• How he aligns risk, compliance and security at Kodak.
• How Kodak approaches forming and following a compliance strategy.
• What his biggest pain points are in meeting compliance requirements, and how he is addressing them.

 

 Kodak CISO on meeting today's compliance challenges [11:18m]: Play Now | Play in Popup | Download

Database logging and privileged access control

Ship captains have long started their days by initialing log entries. As a former senior security executive at a financial services firm with $500 billion in assets under management and over 20,000 employees, my day would start similarly. Each morning, I’d take responsibility for reviewing lists of accounts with privileged access to high-risk data.

What defines “privilege” in the world of security access is really the ability to “write” or alter a database. It also includes the ability to alter the audit trail documenting who has “write” access. “High-risk” data includes customer balances and transaction values, for example. This morning ritual of personally reviewing privileged access should be a part of a compliance program before you attempt database logging. Both are fundamental controls that everyone should have in place. Reports that document identities that have privileged access need to be designed and implemented. Operational procedures for review and follow-up on those reports need to be put in place.

Every morning, automated reports would appear in my inbox based on tightly defined criteria. I reviewed them, printed them, signed them, and had them filed. Auditors checked these randomly several times a year. Once a week, I reviewed similar reports signed by my subordinates, my VPs, reflecting use of emergency IDs, temporary IDs, vendor IDs, and privileged transactions. In other words, even before the Sarbanes-Oxley Act (SOX) required senior executives to take a more proactive role in security, I was starting my business day the same way, monitoring the list of those with the keys to the company’s crown jewels, so to speak.

My daily morning executive-level review of high-risk access should tell you a few things:

1. Even at an enormous firm, the number of privileged IDs with access to high-risk data should be short enough for a busy executive to personally review
2. It is both feasible and reasonable for senior executives to personally review this information and record that they have done so
3. Anyone can expect this kind of review may be taking place in any major organization handling high-risk data, although it is not as universal as it should be

There are no specific standards or frameworks telling you how to create these reports or what to include. Don’t waste your time on a fool’s errand searching for detailed technical guidelines. COBIT and SOX frameworks indicate only that this type of review in general should be defined by each organization and put into place. Whether it is daily, weekly, or monthly, and what exactly it includes, will be up to each organization, compliance officer and CISO, depending on its businesses and risks.

Here are some general considerations for specifying these reports:

1. The number of individuals with write access to this data should be zero. If someone needs regular access to unlock or fix operational issues, you should know those people by name very well and they should number no more than three.
2. Revoke privileges after resolution. Anyone who was granted write access to resolve an issue should have had the privilege revoked after an issue was resolved. Thus, the only names showing up on your report would and should be individuals continuing to resolve issues which cross the timeframe of the running of the report, which should be timed around 3a.m. every day.
3. Turn off audit switches in identities. Don’t forget to include identities in your review that have the ability to turn “audit” on and off for each database or account. Unless you include this privilege, individuals can turn “audit” off prior to access and turn it on again immediately afterwards. You will have no idea of any change. Which means:
4. Include all changes to “audit” status in the prior 24 hours in the privileged transaction report: Was audit turned on or off?
5. Review emergency access for IDs. Did anyone check out an emergency ID with high privileges? Was it checked back in? Does it correspond to a change management ticket reflecting a valid reason for the use of the emergency ID?

Please feel free to comment or write to editor@searchcompliance.com with any questions on these types of controls.