If you look across all of the regulations and mandates out there, like SOX, PCI, HIPAA, COBIT, ISO, etc etc, they all require essentially two things: transparency and control. Transparency is an absolute must. You need to know who’s accessed what data, when and where, and maybe why based on some documented evidence. That’s why you see big sections in these regulations/mandates requiring audit reports. PCI requirement #10 is a good example of this. (Ok, spare me the discussion on how PCI is useless. It’s not!) Control is also a must but transparency sometimes can be used as a compensating control. For example, a company MUST ensure that no shared IDs are used. Well, sometimes that’s not quite possible. So companies implement monitoring of all access to ensure IDs are not shared. Sometimes auditors will let that pass as a compensating control.

Then if you look at what you need to protect from a high level, at the risk of oversimplification, it generally comes down to data, applications and identity.

Identity information is what attackers are first after in order to penetrate the application and get to the data. This is why Identity and Access Management (IAM) is one of the top 3 security priorities for enterprises (source: Gartner) and they are spending ~11% (~$3B) of their IT security spending on IAM.

Then you have the applications which are being attacked left and right. The web application security market is red hot these days because of the prevalence of SaaS and other type of online applications.

And finally the attackers will get to the data. And there are a ton of different type of data. Data such as personal identifiable information (PII) are extremely valuable to some attackers and can be sold for anywhere between $25 to $100 per. You then have other type of data such as corporate financial information, intellectual properties and others that are invaluable.

What enterprises are looking for, regardless of in the cloud or on premise, are control and transparency on their data, applications and identities. Enterprise customers always need to make sure they are compliant with whatever regulations/mandates they are responsible for. In their own environment, they can do many things (defense-in-depth and other principles) to ensure they are “as compliant as possible.” However, in the cloud, they lose that control. In fact, it’s worse, in most cases, they lose transparency. They have no idea where their data is (in GAE, e.g.), or who’s accessing their info (most clouds), how their data’s protected (most clouds), and what data’s accessed for what reason (most clouds.) GAE is probably the worst offender in this case. During an interview with cloudsecurity.org, their GAE lead essentially said they cannot divulge ANY information around security. AWS is doing a slightly better job now in explaning. Though still, neither AWS nor GAE are providing ANY type of transparency through reports or logs (well, you could kinda get S3 logs.)

So in most cases, it’s not that AWS or GAE are less secure than most enterprise environments. They sometimes are probably more secure. However, the thing that most enterprise IT groups fear are losing control and transparency. They want to extend their audit controls into their cloud environment to ensure they are still compliant. Service providers need to step up to the plate and offer the reports enterprise customers are looking for.

As one of the former customer used to say, “you can outsource responsibility, but you can’t outsource accountability.” At the end of the day, the customer is still accountable for being compliant. If they fail the SOX audit, it’s not the outsourcer’s (or cloud provider’s) CEO that goes to jail. It’s the customer’s CEO.

My Twitter Comments

Page 19, not sure about the tie of “private clouds” and “single-tenant (dedicated). For example, multi-tenancy is important even for the on-premise cloud within the enterprise. Also, the off-premise cloud piece (essentially an extension of the customer’s on-premise cloud) could be on a multi-tenant cloud. Other than that, i am kewl with the definition of “private cloud”..or maybe i am just not reading correctly..

There seems to be some font size issues with the Governance portion of the doc…or maybe it’s just my adobe reader.

Domain 2 on Governance reads like a list of things that’s designed for an outsourcing check list…and maybe it should be…but i wonder how likely a customer will get that from like google. Apologies to @jsbardin in advance, but seems like this domain is rushed…there’s a lot more context that can help readers. Domain 2 should really be “IT Governance” and not Governance in general. For example, it doesn’t cover corporate governance.

Wassup with the domain 3 with copyright to Francoise Gilbert? Domain 3 on legal issues is quite well written i think…covered a lot of the issues folks have been talking about.

Domain 5 on compliance and audit is a bit light as well…good stuff in there…but i think there’s a lot more can be said.

There seems to be quite a bit of overlap from domain 2 to domain 6…especially around data/information mgmt. Not necessarily a bad thing to keep hammering it in..but i wonder if there might be a better way to structure these.

Surprised at the shortness of domain 7 on portability and interoperatility…there’s pro’ly more to it i am sure..good start. Pro’ly at least 3 layers to portability…data, app, and server image (in the case of IaaS)…i think only the first 2 are covered.

Domain 8 covers some of the same issues as b4..but good list…can def’ly be expanded..good stuff tho.

A bit perplexed bout domain 9…not sure what the goal is for this write up…maybe i just need more brain cells.

Good issues being raised in domain 10…not sure if there’s a lot of guidance…must re-read another time.

Domain 11, page 65, “In an Infrastructure as a Service (IaaS) cloud platform”?? is it a cloud platform or cloud infra? Top of page 66…”local data storage is not persisted across machine restarts”…HUH?! wah? seriously? EC2 only maybe. Page 66 under “IaaS Impact”, “comparable controls do not exist by default..” again…says who? too limted of a view. Think domain 11 author should be diligent in how they use the word “platform”…could be confusing. Top of page 68, Figure 4, actually in many cases dev & test are outside and production is inside. So while figure 4 is valid for some, def’ly not for all. Again..lots of good stuff in domain 11…not sure i agree w/ everything…good start and write up nonetheless. Paas and saas section somewhat light.

Skipping domain 12 [for now]

Scanned domain 13…raises many good issues. [Re-read later]

Domain 14 again raises issues…but seems to be short on guidance. [Again, re-read later]

Not sure what to think of domain 15…must re-read later.

A couple of days ago “[t]wo security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency.” See Revealed: The Internet’s Biggest Security Hole | Threat Level from Wired.com for more detailed reporting.

According to Wired.com,

The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination.”

. . .

Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed to target addresses, not from them, and it can’t always vacuum in traffic within a network — say, from one AT&T customer to another.

The clever trip the researchers have done is to

use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients.

All these core protocol exploits have direct impact to cloud computing as the nature of cloud computing is that computing will happen out there on the Internet somewhere. According to the article,

The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs.

After reading through it, I felt compelled to respond, even though it’s a been over a month since the post is up. Craig mentioned he won’t talk about the “flip” side of these benefits in this post, so I figure I will do that.
I have only quoted the headers from Craig’s article so please refer to the original article for all the details.

Overall, Craig has made a good list of potential benefits. However, we really need to distinguish the benefits of virtualization vs cloud computing. Many of the benefits listed here are really benefits of virtualization and not cloud computing. When I read the title, I was hoping to read about how the cloud could be more secure than enterprise environments. I think this list has a mix of that, and how enterprise could use the cloud for some security use cases. That’s fine but mixing them together can be misleading.

1. Centralised Data

• Reduced Data Leakage

  As Craig said, “this is the benefit I hear most from Cloud providers”. Unfortunately I have to disagree with Craig here. In my view, the cloud providers are dead wrong about this one. Many of the cloud providers talk about how laptops or backup tapes being stolen as the biggest threat to data leakage, and they are right about that. However, having enterprise data stored in the cloud doesn’t reduce these risks one bit. Travelers will continue to copy data to their laptops as they need to access them while on the road. Old habits die hard. Enterprises will continue to backup data to tapes because they can’t simply reply on cloud providers to backup their data. These will still happen no matter where the data is stored.

  In fact, there likely will be an increased chance of data leakage by using cloud computing because now the cloud providers will have to somehow backup their data (maybe on tape!!)

• Monitoring benefits

  Most enterprises, probably including the one Craig works for, have centralized file servers, content management systems, etc etc. However, we continue to see problems with data leakage. Having data stored in clouds is not all that different than storing on centralized corporate file servers. Centralized storage and monitoring is not an advantage for clouds. Enterprises had centralized storage/archiving solutions for years.

  In my opinion, cloud storage makes it even tougher to monitor data leakage. Think about the tools available to monitor enterprise file servers. Many of them monitors all types of access: read, write, via CIFS/NFS/etc, via local system. How do you do all of that in the cloud? Think S3, the only thing S3 provide you are http access logs. You have no way of knowing who else viewed your files if it’s done locally, for example.

2. Incident Response / Forensics

• Forensic readiness

  To a certain extent this benefits is real. However, it’s not a cloud-only benefit. You get the same benefit by simply doing virtualization on your infrastructure. VMware allows you to easily clone an image so that you can perform whatever analysis is needed on the image instead of the original virtual machine. Same as Xen.

  However, think about the cases where forensics require physical hard disk scan in case the attacker has “rm” the “bad stuff” such as audit trails or root kit. You now have NO WAY of getting to that in a virtualized environment. Granted, this is probably an issue with any network/san attached storage.

• Decrease evidence acquisition time

  Same as above, it’s not a cloud-exclusive benefit. It’s simply a benefit of virtualization. The only real benefit of the cloud, as mentioned by Craig, is not having to “find” storage. Though I would say that’s the least of your worries if there’s a real attack that happened.

• Eliminate or reduce service downtime

  First, if the server/VM is truly “0wn3d”, I am not sure you want to keep that system up and running. You may want to bring a good copy of the VM up and run that instead. (or just go back to a previous good snapshot.)

  Second, with the cloud, you don’t even have a CHOICE of using physical acquisition toolkit. So I am not so sure that’s a benefit.

• Decrease evidence transfer time

  Again, not a real benefit of the cloud. First, bit-by-bit copies of the VM in the cloud still takes time just like if you would in the real world. Second, this benefit can also be realized as part of the internal VM infrastructure, not cloud-exclusive.

• Eliminate forensic image verification time

  Ok, so this is a minor benefit, but not a security benefit of the cloud. It’s more about the performance and scalability of the cloud.

• Decrease time to access protected documents

  Both this and the next benefit are really about the elasticity and scalability of the clouds and not security.

3. Password assurance testing (aka cracking)

• Decrease password cracking time

  Same as above, this is about the benefits of elasticity and scalability, not security.

• Keep cracking activities to dedicated machines

  Same as above, this is about the benefits of elasticity and scalability, not security.

4. Logging

• ‘Unlimited’, pay per drink storage
• Improve log indexing and search
• Getting compliant with Extended logging

Ok, this is about the utility and scalability of the cloud. Not a cloud security benefit. It’s about using the cloud for security tasks.

5. Improve the state of security software (performance)

• Drive vendors to create more efficient security software

  I believe this is true for even software on dedicated machines. Not cloud-exclusive.

6. Secure builds

• Pre-hardened, change control builds

  This I agree with. Having pre-built images that are secure from the start is a HUGE benefit. Though it’s a benefit of virtualization and virtual machines, not cloud-exclusive.

• Reduce exposure through patching offline

  I don’t understand this one. Once the VM is running in production, I can imagine taking that down to do patching. You would have to manage the patching process like any other machine, no?

  Now image templates can be updated with patches so if new machines are started, they are pre-patched.

• Easier to test impact of security changes

  Again I agree. However, it’s still the benefit of virtualization, not necessarily cloud-exclusive.

7. Security Testing

• Reduce cost of testing security:

  Agreed. It’s a side benefit of economies of scale.

Here are some of the topics that I gathered based on the sessions I attended and people I’ve talked to.

The definition is very cloudy!

There’s no agreement on the definition of Cloud Computing. Reuven Cohen held a very popular session on “What is Cloud Computing?” There were at least 40 people in the room that was supposed to hold only 20. There were a wide variant of definitions, going from Reuven’s very open definition (internet centric software) to another person’s very restrictive definition (cloud computing must use web services, XML, SOAP, etc).

There were also discussions (and disagreements) on whether Google App engine is considered a cloud or not. Interesting enough, some of the people there didn’t consider GAE as a cloud. In one of the sessions, someone put an even more restrictive constraint on cloud computing. He said that a cloud MUST run any existing application without modification. So in that case, GAE would not be a cloud by his definition. I am definitely in the camp of that GAE is a cloud.

Some interesting questions were asked as well, such as the question from a Microsoft guy, “Does the operating system still matter, if the the application is running in the cloud. My answer to that was it depends on the type of application. If it’s a web centric application that has a web front end, uses a database for storage, and doesn’t use any of the low level file IO, then really there’s no need to know what the OS is. In that case, the OS doesn’t matter.

The term that’s used most to describe cloud computing is elasticity: the ability to quickly provision and de-provision computing resources on demand. Almost everyone I’ve talked to or listened to agrees to that. Some of the enterprise attendees also noted this as one of the biggest benefits of the cloud. When business units come to IT with new application requirements, IT now has a way to quickly spin up resources without having to wait weeks or months to procure equipment. The other thing that everyone agrees on is the utility model: the ability to pay for what you use.

Service level agreements

This topic was heavily discussed in the “No Cure for Cancer: Manage the Expectations of Cloud Computing” session. To summarize, there’s almost no SLAs provided by the cloud providers today. Even Jeff Barr from Amazon said that AWS only provides SLA for their S3 service. I haven’t researched the SLA issue so not sure how true that is. But if it’s true, I think this will be one of the biggest factor, if not the biggest factor, in enterprise adoption. Can you imagine enterprises signing up cloud computing contracts without SLAs clearly defined? It’s like going to host their business critical infrastructure in a data center that doesn’t have clearly defined SLA.

We all know that SLAs really doesn’t buy you much. In most cases, enterprises get refunded for the amount of time that the network was down. No SLA will cover business loss. However, as one of the CSOs I met said, it’s about risk transfer. As long as there’s a defined SLA on paper, when the network/site goes down, they can go after somebody. If there’s no SLA, it will be the CIO/CSO’s head that’s on the chopping block.

Security

Another topic that was discussed in Sam Charrington’s “How Cloud Impacts Enterprise Computing” session is security in the cloud. When Sam asked the group what are the factors that prevent enterprise from adopting the cloud, Ben Charian from ServiceCloud empathically said “security.” He talked about that the clouds must be certified or audited against standards or frameworks such as PCI. I’ve written about cloud security requirements here and here so I won’t elaborate on this topic. Needless to say, I am in total agreement with Ben. What I didn’t agree with Ben on is the need to rewrite these frameworks or standards specifically for the cloud. I believe many of the controls such as identity management and segregation of duties are the same in the cloud or out of the cloud.

Other observations and interesting tidbits

• As the enterprise use more cloud resources, there will be a point where it may make sense to bring things back in house rather than continuing to use the cloud.
• The cloud computing discussions are focused mainly on the infrastructure/platform-in-the-cloud. Applications-in-the-cloud or SaaS was hardly discussed. I get the feeling that most of the attendees don’t consider SaaS to be cloud computing, rather, it’s applications running on top of (or in) the clouds.
• Cloud computing spending is opex instead of capex, allowing business units to make their own decisions.
• Make sure you partner with someone who you trust and work with you on deploying to the cloud.

There are really two main topics in the discussion:

• Security and privacy issues around data in the cloud, which I have some detailed write up on here and here
• Moving the data into the cloud or moving the programs to the data

1. Data Locality – Where’s my data?
2. Data Segregation – How is my data segregated with other customers, potentially my competitors?
3. Data Access – Who can access my data in your company?
4. Access Audit – Who has accessed my data and where’s my access logs?

We are continuing this discussion with the following questions in part 2.

5. How are the users authenticated and authorized?
6. Web Application Security – How secure is the SaaS provider’s web application?
7. Data Breaches – How do you protect my data from insider breaches?
8. PCI DSS – Are you compliant with PCI DSS?

5. How are the users authenticated and authorized?

Companies have spent hundreds of man years and millions of dollars trying to setup single-sign-on systems inside the corporate firewalls. Most companies, if not all, are storing their employee information in some type of LDAP servers. In the case of SMB companies, a segment that has the highest SaaS adoption rate, Active Directory seems to be the most popular tool for managing users. In many cases, companies have designed their IT infrastructure so that all authentication, including VPN, web proxy, file server, and others will go through this single infrastructure. The process of employee onboarding and termination is much easier this way.

Just as companies start to have some success, the advent of the SaaS model changes the scenario again. With SaaS, the software is hosted outside of the corporate firewall. Many times user credentials are stored in the SaaS providers’ databases and not part of the corporate IT infrastructure. This means SaaS customers must remember to remove/disable accounts as employees leave the company and create/enable accounts as come onboard. In essence, having multiple SaaS products will increase IT management overhead.

SaaS customers will start asking questions on identity and access integration and providers would be wise to design such features in early on. For example, SaaS providers can provide delegate the authentication process to the customer’s internal LDAP/AD server so that companies can retain control over the management of users.

6. Web Application Security – How secure is the SaaS provider’s web application?

One of the “must-have” requirements for a SaaS application is that it has to be used and managed over the web (in a browser.) This creates an interesting scenario. In the on-premise scenario, when a vulnerability is found, at least you have your firewall protecting the application so you may get a bit more time to patch it (assuming the application vendor provides the patch in a timely fashion.) However, in the SaaS world, there is no such luxury. Any vulnerability identified can potentially have detrimental impact on all of the customers. Even leading security companies aren’t immune to security holes in their web applications.

Web application security is quite a hot topic these days and it’s discussed by many security researchers such as rmogull and RSnake. Here’s an interesting article on “What web application security really is“.

Verizon Business recently released their Verizon Business 2008 Data Breach Investigations Report. Of all the breaches, 59% of the breaches involve hacking, with the following breakdown:

• Application/Service layer -39%
• OS/Platform layer – 23%
• Exploit known vulnerability -18%
• Exploit unknown vulnerability – 5%
• Use of back door -15%

Attacks targeting applications, software, and services were by far the most common technique, representing 39 percent of all hacking activity leading to data compromise. This follows a trend in recent years of attacks moving up the stack. Far from passé, operating system, platform, and server-level attacks accounted for a sizable portion of breaches. Eighteen percent of hacks exploited a specific known vulnerability while 5 percent exploited unknown vulnerabilities for which a patch was not available at the time of the attack. Evidence of re-entry via backdoors, which enable prolonged access to and control of compromised systems, was found in 15 percent of hacking-related breaches. The attractiveness of this to criminals desiring large quantities of information is obvious.

Currently there’s really no mandate or requirement for SaaS providers to provide detailed security analysis of the SaaS application. However, it would be wise for the SaaS providers to start considering something similar to what PCI DSS has required of the merchants:

1. 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
   1. 6.5.1 Unvalidated input
   2. 6.5.2 Broken access control (for example, malicious use of user IDs)
   3. 6.5.3 Broken authentication and session management (use of account credentials and session
      cookies)
   4. 6.5.4 Cross-site scripting (XSS) attacks
   5. 6.5.5 Buffer overflows
   6. 6.5.6 Injection flaws (for example, structured query language (SQL) injection)
   7. 6.5.7 Improper error handling
   8. 6.5.8 Insecure storage
   9. 6.5.9 Denial of service
   10. 6.5.10 Insecure configuration management
2. 6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
   • Having all custom application code reviewed for common vulnerabilities by an organization
     that specializes in application security
   • Installing an application layer firewall in front of web-facing applications.

Additional sources of information provided as a starting point for more information on web application security would include

• OWASP Top Ten
• OWASP Countermeasures Reference
• OWASP Application Security FAQ
• Build Security In (Dept. of Homeland Security, National Cyber Security Division)
• Web Application Vulnerability Scanners (National Institute of Standards and Technology)
• Web Application Firewall Evaluation Criteria (Web Application Security Consortium)

Trey Ford of Security Spin Control has a fairly good explanation of the recently released PCI information supplement on requirement 6.6.

SC Magazine also has an article on Deconstructing PCI 6.6 for the management folks.

7. Data Breaches – How do you protect my data from insider breaches?

In the Verizon Business breach report blog, Verizon Business stated that

While criminals more often came from external sources, and insider attacks result in the greatest losses, criminals at, or via partner connections actually represent the greatest risk. This is due to our risk equation: Threat X Impact = Risk

• External criminals pose the greatest threat (73%), but achieve the least impact (30,000 compromised records), resulting in a Psuedo Risk Score of 21,900
• Insiders pose the least threat (18%), and achieve the greatest impact (375,000 compromised records), resulting in a Pseudo Risk Score of 67,500
• Partners are middle in both (73 39% and 187,500), resulting in a Pseudo Risk Score of 73,125

Many SaaS advocates claim that SaaS providers can do a better job at protecting the customers’ data. Unfortunately, just because the data is now in the cloud, it does not reduce the risk of insider breaches. Insiders still have access to the data, they are just accessing it a different way. Just because the data is in the cloud, the responsibility of segregation of duties and access authorization still fall on the customers, not the SaaS or cloud computing providers. So yes, it may reduce the chance of insiders getting direct access to, say, a database, it does not in any way reduce the risk of insider breaches. In fact, it may even increase the possibility as you now have to take into consideration of the cloud or SaaS providers’ employees. They have access to a lot more information and a single incident could expose information from many customers.

SaaS providers should be prepared to answer questions on what tools and processes are utilized to ensure segregation of duties and protect from insider breaches. Remember, in the case of the mult-billion dollar insider incident at Société Générale, IT management had implemented all of the controls recommended by auditors, but nobody was monitoring them. So it’s extremely critical to be able to show the processes around these security controls.

8. PCI DSS – Are you compliant with PCI DSS?

PCI DSS has a specific section for hosting providers (including SaaS providers):

Requirement A.1: Hosting providers protect cardholder data environment

As referenced in Requirement 12.8, all service providers with access to cardholder data (including hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entity’s hosted environment and data. Therefore, hosting providers must give special consideration to the following:

A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, as in A.1.1 through A.1.4:

1. A.1.1 Ensure that each entity only has access to own cardholder data environment
2. A.1.2 Restrict each entity’s access and privileges to own cardholder data environment only
3. A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10
4. A.1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not necessarily guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Simply put, SaaS providers must be compliant with PCI DSS in order to host merchants that must comply with PCI DSS.

We will continue with our tough security questions in part 3 of this series.

In the video blog, Mike tried to explain why customers shouldn’t have to worry about the loss of data control and security. First of all, as Mike said, “these companies invested in billions of dollars in infrastructures and security and have armies of security professionals.” Therefore, these companies will have greater control and better governance and do a much better job at protecting customers’ data than they can. Second, since “most security breaches are inside jobs”, cloud computing will “greatly reduce the risk” of such breaches. Even though there will still be some, but the risks are reduced. Third, companies are already putting their data out there, including payroll, accounting, CRM. Since this is already being done, we just need to “shift the way we think” because “this is the wave of the future” and it’s the “next game changer.”

I have to disagree on all three points. First, not all “cloud computing” companies that have sprung up can and will invest billions of dollars in infrastructure and security. If you just look at Amazon or Google, yes, maybe. However, there are plenty of cloud computing startups that have no such budget and they have the same problems as every startup when it comes to deciding whether to invest in infrastructure or security (i.e., infrastructure wins, security loses.) So a blanket statement like that doesn’t make any sense. Even in the case of Amazon and Google, just because they can have more security professionals, it doesn’t mean customers should just trust them and not worry about security and data privacy.

Second, on the topic of insider breaches, just because the data is now in the cloud, it does not reduce the risk of insider breaches. Insiders still have access to the data, they are just accessing it a different way. Just because the data is in the cloud, the responsibility of segregation of duties and access authorization still fall on the customers, not the SaaS or cloud computing providers. So yes, it may reduce the chance of insiders getting direct access to, say, a database, it does not in any way reduce the risk of insider breaches. In fact, I will argue that it may even increase the possibility as you now have to take into consideration of the cloud or SaaS providers’ employees. They have access to a lot more information and a single incident could expose information from many customers.

Third, the argument that because companies are doing it already and are already putting their payroll, account, and CRM information in the cloud, customers should just shift the way they think also doesn’t sit well with me. Just because others are doing it doesn’t mean it’s the right thing to do. Customers shouldn’t just throw away their security policies and adopt a new way without evaluating the risks.

So am I advocating companies not to adopt cloud computing and SaaS? Absolutely not. What I am advocating is that companies evaluate the potential risks and understand the business impacts before jumping into the “wave of the future.” Don’t just trust the cloud or SaaS providers to take care of security. At the end of the day, it’s the customer, not the providers, that’s signing off on the SOX report and go to jail (or fined) if the audits fail.

I am working on a series on “Tough security questions for SaaS providers“. It should serve as a good set of questions to ask when evaluating cloud or SaaS providers.

why not consider moving workload to wherever the current task is “most legal” using a combination of database sharding, database replication and vmotion/livemotion.

A lively discussion followed and there are opinions from both sides. Reuven Cohen also wrote a piece on The Geopolitical Cloud a while back. Definitely follow the thread and read more.

As we mentioned previously here, one of the biggest obstacle to enterprise SaaS adoption is the issue of trust. Customers are asking SaaS providers “Can I Trust You?!” The security analysts and warriors are asking similar questions.

Some SaaS advocates have argued that concerns for SaaS security are just red herring. It is true that, to date, there hasn’t been any major breaches amongst SaaS providers. However, we have already seen some activities such as the breach at Salesforce.com. In addition, we have seen many anecdote evidence that multi-tenant architectures in the B2C (e.g., Flickr, YouTube) world are prone to data leakage. I have also personally experienced this on YouTube. The following screen capture shows an account that’s NOT mine (again, that’s NOT me in the video!!) but it popped up in my browser when I tried to go to YouTube.

One may argue that these are consumer sites and are not relevant for the SaaS providers. However, the same technologies and architectures are being used in both the consumer and enterprise world. In fact, as the trend of IT consumerization continues, we will see more and more of the consumer technologies being used in enterprise applications. Think about it this way, what if this Salesforce.com and your customer list popped up in your competitor’s screen?

SaaS providers should be prepared to answer security questions from customers and enterprises. Here are a list of questions that SaaS providers will likely get asked during customer trials/evaulations.

1. Data Locality – Where’s my data?

Due to compliance and data privacy laws in various countries, locality of data is of utmost importance in many enterprise architecture. For example, in many EU and South America countries, certain types of data cannot leave the country because of potentially sensitive information. In addition to the issue of local laws, there’s also the question of whose jurisdiction the data falls under when an investigation occurs. In most cases, the government where the data is housed will likely win. A good example of this type of concern is when the French cabinet banned the use of Blackberry devices.

Many enterprises have architected around these issues for the on-premise software they install. However, with cloud computing and SaaS, this issue is even more exasperated. In a cloud computing environment, sometimes you don’t know where your data is stored or where your application is being run; and some proponents of cloud computing are also saying that you shouldn’t have to worry about where the computing resources are as long as your application is running and behaving as it should. However, other leaders in the cloud computing space are taking note of the data privacy and locality issues. For example, Amazon recently announced the availability of an European S3 cloud, and Salesforce.com is also planning Singapore data center.

Given the regulatory compliance and data privacy concerns, SaaS providers should be ready to answer tough questions about where their computing resources are and will customer data be ever transferred outside to another jurisdiction with different laws.

2. ata Segregation – How is my data segregated with other customers, potentially my competitors?

Everyone’s talking about the benefits of multi-tenancy in the SaaS world, but many seem to ignore one of the biggest security concerns, mixing customer data together, that came along with multi-tenancy.

One of the reasons that hampered SaaS adoption initially was trust. End users must trust that the SaaS providers have the best security in place to protect their data and never expose their data to anyone outside of the authorized domain. Therefore, the ability to segregate data by end customer is a critical requirement for the SaaS providers. There are many architectural methods in segregating the end customer data. At the end, the requirements come down to that users must never see the data that they are not authorized to see, and that end customer’s data should never be exposed to other end customers.

Saas Providers would be wise to consider data segregation early on in the architectural design. For most ISVs turning into SaaS providers, this is an unfamiliar territory and should seek guidance if possible. SaaS providers should also understand the customer concerns and address them early on.

3. Data Access – Who can access my data in your company?

Enterprises have spent hundreds of thousands of dollars on identity and access management systems, log management systems and other software to ensure that employees access only information they are allowed. Within the confines of their firewalls, IT organizations may feel that they have the situation somewhat under control. The advent of SaaS have changed that. With the company data outside of the firewall and in a “cloud,” IT organizations no longer can control who and when their data-in-the-cloud will be accessed. Without visibility into the cloud, IT organizations are accepting a much bigger risk compare to when everything’s inside the firewall. Even though many SaaS providers have offered various capabilities such as authentication integration with customers’ own LDAP servers, this perception of lost control is a difficult hurdle to get over.

SaaS providers offering cloud services, whether it’s infrastructure, platform or application, should accept the responsibility of protecting customer data as a single breach could affect all of the customers. SaaS providers must be prepared to help customers understand their security policies on user access, activity monitoring as well as segregation of duties.

4. Access Audit – Who has accessed my data and where’s my access logs?

The last few years we have seen a rise of log management and SIEM solutions aimed at compliance-aware organizations. These products is responsible for collecting, analyzing, correlating, archiving and reporting on all activities happening inside an IT infrastructure. Part of the reason these products became such a success is because of the need to track and monitor user activities in the world of regulatory compliance. In addition to compliance, IT organizations use logs to help them identify security issues, perform troubleshooting and forensics analysis, and analyze traffic and user patterns.

With software in the cloud, network, system and application logs are no longer easily accessible by IT organizations. They either have to negotiate access to these logs during contract time, or they have find new ways of monitoring user activities. Given that the IT organizations don’t “own” the software, it makes it even more difficult to “hack” around the system. Without access logs, IT organizations may not be able to answer simple questions from auditors, such as “who have accessed the financial information in the past quarter?”

Knowing how critical access logs are to compliance, operations and security matters for IT organizations, SaaS providers should consider providing access logs as a part of their normal service or have it as an option for customers. As an example, Amazon’s S3 service offers options to enable and download access logs.

We will continue with our tough security questions in part 2 of this series.

Download file here.

Chris, in the podcast, talked about 3 major misconceptions: security, integration and legacy concerns.

Security (and data privacy for that matter) has been, and will likely continue to be, the biggest concern. Chris argued that this concern is really red herring and that smart CIOs are finding that SaaS companies sometimes even have more security measures and better security policies than when the data is housed internally. Though I would say that this is the case of devil you know vs the devil that you don’t. If you know that internal security measures are not up to par, there may be compensating controls that can be put in place. However, with SaaS products, the enterprises loses all of the control. So they are understandably concerned.

Chris gave the example that with data housed internally, employees will copy them onto their computer and use it offline. Whereas with SaaS, they will likely be less inclined to do that. This is true to a certain extent. However, nothing prevents the employees from copying data onto their computer even if it’s SaaS. If they are offline and want to work on the data, they will copy them down regardless of SaaS or on-premise. (Now here’s a thought, maybe Google Gears can have some monitoring and tracking capabilities built-in? Or maybe someone can extend Gears?)

Now I am not arguing that enterprises should never use SaaS products. I am simply saying that they should keep security and privacy in mind when evaluating different SaaS offerings and make sure that either

• Truly sensitive data such as credit card information are never housed externally.
• Take extreme measures to evaluate a SaaS provider’s security policy and practice. (How to evaluate is probably for another post. I would love to hear your thoughts in the comments if you would like to discuss.)

Chris later provided some guidance:

• Make sure the vendor meets compliance standards and such as SAS70 type 2 security standards
• Tour the data center to ensure proper security practice are in place
• Get educated about the security standards (and for SaaS providers, educate your customers)
• Check references (nothing ever replaces this, so always do it)

The second misconception Chris mentioned is “integration.” Many enterprises have the misconception that SaaS offerings are closed and are more difficult than on-premise apps to integrate. I have to agree with Chris here that this is truly a misconception. Most SaaS providers are much more Web 2.0-savvy and usually provide better API to customers for integration. Chris also mentioned their 4-way mashup with PayPal, Amazon and Salesforce.com.

The last misconception discussed was around the legacy concerns from the old ASP model. Chris didn’t specifically talk about why the old ASP model generated these legacy concerns. He simply said that because the old ASP model wasn’t built from the ground up to be multi-tenant, therefore people had concerns. I would have liked to hear more about the specific reasons. This is one of the things that bugged me about the podcast. Chris touted multi-tenancy to be this be all end all solution to all problems including security and integration. That’s simply not the case. Multi-tenancy brings its own set of concerns and problems such as data privacy and performance. Most ISVs who have been developing on-premise applications will likely not be familiar the design considerations of multi-tenancy and will have a learning curve to go through. Again, I believe multi-tenancy has a lot of advantages but let’s not make it the solution for everything.

One thing Chris said that every ISV should remember is: “The saas model must earn the customer every month.” The cost of migrating from one SaaS provider to another is much lower than on-premise apps. So in order to keep your customers, make sure you do everything you can in supporting the customers. Remember, Support is the New Marketing!

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.

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.

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.

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).

It’s definitely worth scanning through. There are some interesting findings:

• Regulatory compliance related to information security is among the most critical security issues customers face.
• Virus attacks continue to be the source of the greatest financial losses. ($15.7 mil)
• Unauthorized access continues to be second-greatest source of financial losses. (10.6 mil)

It’s also interesting that e-mail and web activity are used by over 50% of the organizations as effective security techniques. (page 17)

Not surprisingly, data protection is cited as the most critical security issue for the companies for the next two years. (page 24)

My third article on the SLA series, SLA 103: Security Reviews, is out.

Some service providers, as part of your security-services installation, include a free design review when you buy their managed security service. If your SLA doesn’t include such a review, try negotiating with your service provider to get it.

Some service providers require the customer to initiate the review process. If it’s not initiated within a stated time frame, the customer loses the opportunity to have the service performed. Be sure to understand the process by which you will obtain your security review and in what time frame your initial request needs to be made.

.

Will let you know how it reads.

A vulnerability has been reported in Cisco Security Monitoring, Analysis and Response System (CS-MARS), which can be exploited by malicious, local users to gain escalated privileges.

The vulnerability is caused due to CS-MARS appliances being shipped with a default password for an undocumented administrative root account that is intended for debugging purposes. This can be exploited by malicious users to gain root privileges using the undocumented “expert” command. The password for the account reportedly cannot be changed.

Successful exploitation requires logon to the administration command line interface with e.g. the “pnadmin” account.

The vulnerability has been reported in versions prior to 4.1.3.

Please upgrade to 4.1.3 asap.

As reported by Secunia and Cisco.

Ruby Qurashi’s article on Eight steps for integrating security into application development is a good summary of a process one should take to ensure security’s built into the applications from the start.

1. Initial review
2. Definition phase: Threat modeling
3. Design phase: Design review
4. Development phase: Code review
5. Deployment phase: Risk assessment
6. Risk mitigation
7. Benchmark
8. Maintenance phase: Maintain

The threat modeling step is, I believe, one of the most critical steps in this whole process. This belief is mainly due to that many of the application developers are not familiar with the various attacks that could happen to their software. This step would serve as a great training step for these developers.

If this step is performed correctly, the following steps will be much easier for everyone.

Good summary, worth reading.