Business Information

Technology insights for the data-driven enterprise


Enterprise cloud services: Who's responsible?

Learn why the question of who's responsible for specific areas of security in the cloud is still a common enterprise cloud service unknown.

Jan StaffordJan Stafford

The concern for cloud security still knits the brows of business and software decision makers, from software developers and architects to CEOs and CIOs, according to anecdotal and statistical evidence. Anecdotal? The house was packed for the "Security in 2013" session at the San Francisco Amazon Web Services Summit 2013. Statistical? TechTarget surveys from cloud's early days, the mid-ought's, until the new March 2013 Cloud Pulse research shows that security is the biggest barrier to cloud adoption, with a consistent 33-36% of respondents saying so.

There's not enough security in cloud environments said over 32% of the nearly 1,300 business and IT respondents to TechTarget's first quarter 2013 Cloud Pulse survey. About 34% were put off by not having enough control over cloud environments, certainly a related topic. Other companies' surveys reveal higher levels of concern about security. Concerns about security are impeding enterprise cloud adoption for 54% of respondents to a recent Trend Micro survey, according to AWS Summit speaker JD Sherry, a former enterprise CIO who's now global director of technology and solutions for Trend Micro.

This Cloud Directions column looks into a common cloud security unknown: Who's responsible for specific areas of security in the cloud? Organizations make the assumption that cloud providers are providing security services that they are not, expert Dan Cornell told me recently. "Because it was easy to set up cloud servers, they think someone [with the cloud provider] is paying attention to them. In a lot of cases, no one is," said Cornell, president of Denim Group, a security tool ISV and consultancy in San Antonio.

Both providers and customers are accountable for the chronic aura of fear about cloud services and applications security, said Cornell. Lack of information from cloud service providers about the division of security responsibilities and potential cloud users' inefficient analysis and magical thinking are to blame, they say.

The good news is that some cloud services providers have moved security information from fine print to bold headlines, as evidenced by the above-mentioned AWS Summit session. In "Security in 2013," the security responsibilities of Amazon Web Services and customers were spelled out:

  • AWS: facilities; physical security; physical infrastructure; network infrastructure; virtualization infrastructure.
  • AWS customer: operating system; application; security groups; network ACLs; network configuration; account management.

Amazon takes care of security for its in-house systems and infrastructure, "but they don't want to be in the database [security] business," said "Security in 2013" speaker Sherry. "CIOs and practitioners are responsible for security and service deployment. Customers do need to take responsibility for securing their services running in the cloud."

Consumers of cloud services are responsible for agent capability that enables management of the security profile, the firewall, host intrusion and more. "You have to get down to the host level as it is pertinent to you," said Sherry. Traditional network appliances are not feasible, because they have limited control over the network, he noted. Agent-based host security controls are required.

Taking on the customer-side responsibilities for cloud application and service security is a big stretch for companies' current security systems, largely because of the dynamic nature of cloud services. For example, having no in-house staff to maintain cloud applications is a fact of life for 21.6% of Cloud Pulse 2013 respondents.

It's hard to get typical enterprise security processes to work in a cloud environment, Cornell said. "Where you run into trouble in the cloud is the ability to scale up a lot of servers faster," he explained. "Your standard processes for provisioning and reprovisioning may not be able to handle this."

Obviously, careful evaluation of current capabilities versus cloud services security requirements is needed. Look at how usage patterns will change when applications are moved to the cloud, Cornell advised. An example is deciding where anti-virus is needed or not, the latter perhaps being when a server is turned on for a minute to do specific work and then turned off quickly. "The main concern is getting blindsided by the different cloud server lifecycle and different exposures there," Cornell said.

Using third-party cloud security services to fill the gap between in-house capabilities and cloud responsibility requirements is a valid option, with caveats. Cornell advises: "If you don't have that capacity for your physical servers, then look to services."

Usage of Security as a Service will increase over the next year, according to 2013 Cloud Pulse results. About 6% use security services now, but 17.3% will use them in the next year. The majority, 54%, will use security services to augment and not replace existing internal security processes. Most (47.7%) will use email security services and security information and event management (27.3%). About 20% plan to use cloud services for identity and access management, intrusion detection and prevention, penetration testing and software vulnerability assessment and management.

Vendor lock-in fears are also still with us in the security services realm, said over 52% participating in the 2013 Cloud Pulse survey. Lock-in has, of course, been reality and concern for enterprise decision makers since the mainframe days. In choosing cloud vendors, as in war, exit strategies are direly needed, and failing to create them can be disastrous.

Article 11 of 11

Dig Deeper on AWS security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Business Information

Access to all of our back issues View All