We’re continuing to ride the wave of IT transformation and marketing efforts around various cloud computing paradigms. Driven by the need to handle increasing malware volume and the opportunity to derive intelligence from a large user community, antivirus vendors have been incorporating some aspects of cloud-themed processing into their products.
Reminder: What is Cloud Antivirus?
I defined the notion of cloud antivirus in my earlier post on the topic:
Cloud anti-virus is anti-malware technology that uses lightweight agent software on the protected endpoint, while offloading the majority of data analysis to the provider’s infrastructure.
Instead of having to assess whether a file is malicious by performing analysis locally, the agent captures the relevant details from the endpoint and provides them to the cloud engine for processing. As the result, the broad community of the tool’s users benefit from the processed data collected from various subsets of the population.
While some products are designed to act as standalone cloud antivirus tools, the broader adoption of cloud capabilities has been driven by enhancements incorporated into existing antivirus or Internet security products.
Cloud Antivirus Capabilities Build Into Common AV Products
I spent some time exploring publicly-available information about common antivirus products to understand how the vendors describe and position their cloud capabilities. Here’s the gist of what I found, in case you want to dig deeper into this topic:
The excerpts above that outline how antivirus vendors describe their cloud capabilities are taken mostly from marketing documents. If you have pointers to more technical descriptions of these mechanisms, please leave a comment.
I’ve been pondering the use of deception and variability to slow down and misdirect computer attackers. Honeypots have been discussed in this context for some time, yet they’ve failed to take off as mainstream components of a security architecture. Perhaps now is the time when a new set of tools and people can reignite an interest in this aspects of information security. I believe this area is ripe for innovation.
Looking at how deception was used during World War II can set the stage for the common forms of such tactics. According to a paper by Donald J. Bacon, Allied Forces to confused and misdirected the enemy by incorporating ambiguity and misdirection into their operations. The paper also attributes many Soviet victories during the war to the full integration of deception into operational planning and execution.
Early Examples of Deception for Computer Security
A historic perspective on the use of deception for computer security comes from the account of Gene Spafford of his work during 1989-1993. Gene describes the “active defenses” he employed to identify attacks in progress, slow down attackers, learn of their techniques and feed them fake data. His approaches included:
Gene believes that “too few defenders these days build forensics capture into their systems to help identify intruders. They also don’t have active defenses, countermeasures and chaff in place to slow down attackers and provide more warning of problems.”
The Use of Honeypots
Many of the deception techniques discussed by Gene were implemented later through the use of honeypot tools. Around 1999, Honeynet Project came into existence, infusing innovative thinking into such ideas and approaches to discovering attacks and learning about attacker’s capabilities. The most comprehensive commercial product in this space at the time was, probably, ManTrap by Recourse Technologies. The company was acquired by Symantec in 2002, but was discontinued a few years later.
The idea of honeypots seems to have faded into the background, as people were reluctant to deploy them on production networks due to support costs and risks and low perceived value. Yet, people continued to make specialized honeypot tools, as is evidenced by the likes of Nepenthes—a free tool for detecting and capturing malware. Other tools include Kippo for SSH, Glastopf for web servers, Jsunpack-n for web clients and InetSim for various network services.
More recently, John Strand at PaulDotCom has been exploring the use of deception in the context of offensive countermeasures. For instance, he showed how a small script can be used to automatically shun the attacking IP address that tries to connect to a decoy port on Windows and on Linux. John also demonstrated a free tool called WebLabyrinth by Ben Jackson, which is designed to confuse and slow down malicious web crawlers.
Deception as a Larger Defensive Capability
My goal is not to present a history of deception tools, but rather to offer a few data points regarding how, if at all, these technologies have evolved. As you can see, our tools today aren’t far removed from the early ideas implemented by Gene Spafford. Here’s my take-away:
Deception tools and approaches won’t go beyond niche tools and won’t gain mass appeal until we find a way to integrate honeypot capabilities into the overall IT infrastructure.
One of the lessons in the use of deception during World War II is that to be successful, such efforts cannot be one-off projects. They have to be centrally managed and integrated into the fabric of operations. I’m reminded of this by Gene Spafford’s use of the term “active defenses” and by John Strand talk about honeypots in the context “offensive countermeasures.” (Not just “honeypots.”)
Protean Security and Cloud Computing
Perhaps the increased use of cloud-based services will make it easier to incorporate deception into IT infrastructure. Mike Rothman described the idea of HoneyCloud, which would be used to deploy deceptive and protean technology elements into a private cloud to minimize production risks. Moreover, I think the biggest advantage of cloud technology is its elastic capabilities that, combined with support for automation can allow an organization to integrate deceptive and protean capabilities into the fabric of its IT operations. There’s room for innovation there, and that’s very exciting.
Computer attackers exhibit an increased interest in contents of email messages. The intruder can gain access to the messages by directly querying the victim’s mail store or by accessing the corporate centralized message store. There’s one more attack vector to consider: third-party “cloud” add-ons and services that have been granted access to email and other communication data.
Options for “Cloud” Email Search Add-Ons and Services
I’m talking about the increasingly-popular email search tools that make it easier for users to locate, analyze and make use of messages and contacts. The choices include:
Granting Access to Email Data
To make use of these tools, the user needs to authorize them to access the desired email and social networking accounts. For instance, TechCrunch described the process for getting started with Greplin:
“A typical user may sign up and start off by authorizing Greplin to index Facebook, Twitter and Gmail, for example. Greplin then grabs everything in those services – all your Facebook messages and updates, all your Twitter updates and DMs, all your Gmail messages back and forth, etc. , and lets you search them.”
From an attacker’s perspective, the vendors’ systems used to store and process email and other communications form an attractive target: By compromising the systems used for storing content and/or its indices, the intruder can gain access to a treasure trove of valuable data.
Some people recognize the risk of granting these tools access to their data and decide to use the tools regardless. For instance, I came across a blog posting by Josh Fraser in which he wrote:
“There’s an obvious concern about the security aspect of using Greplin since they have access to all my content and are storing the indexes in the cloud. For me, the value they provide is big enough that I’m willing to take the risk and I’m not one to hand over the keys to my data easily!”
Josh performed the risk vs. benefit analysis and decided to accept the risk. Good. However, I wonder how many people install such tools without given a second thought to data security implications?
How Do These Services Secure Users’ Data?
I’ve been unable to find much information about the security measures that the vendors implement to protect users’ data beyond the vague language typically found in privacy policies. For instance, searching Greplin’s on-line help system for “security” gave me zero hits:
Backupify simply says “Any information we have about you is stored with strong encryption.” What does that mean? (For instance, how is key management handled?)
Gist does a better job describing some aspects of its security, clarifying that “Gist also has the ability to upload your email contents to Gist” and outlining other data that the service has access to. However, there are few details regarding the actual security controls that might be in place.
CloudMagic stands out from many other tools in this category by storing the email index on the user’s local host and, therefore, addressing many of the security issues that the other vendors need to consider. According to the company, it “never exchanges account’s authentication details or its content with any third party servers including ours.”
Email search add-ons and services provide valuable features that users want. I’m excited to see the innovation that the vendors exhibit by helping people make use of the ever-growing pile of email and other communication data. At the same time, I worry that the vendors aren’t paying sufficient attention to security of the highly-valuable data they process and store. I also worry that users of such tools adopt them without considering the risks.
As the strategies employed by computer attackers increasingly exhibit market segmentation attributes, the threats evolve toward more focused, nimble tactics. One aspect of this trend is the attackers’ interest in email contents, which is why it’s so important to pay attention to how access to email and other communications is controlled—not only locally, but also through the use of “cloud” search add-ons and services.
Security professionals lack virtualization knowledge and best practice models for server virtualization security. Until they gain this knowledge, they won’t buy security tools. Time to teach the market how to fish.
Cloud computing presents its share of risks that concern infosec professionals. At the same time, the cloud billing model offers a major security benefit to small and medium-sized businesses (SMBs) by making security more affordable for them.
Pricing Enterprise Security Products
Historically, enterprise security products have been expensive. (I wrote earlier how vendors can use low price as a competitive advantage.) In particular, the initial purchase and setup price—the capital expenditure (capex)—has prevented SMBs from deploying more than the bare essential security tools, say network firewalls and anti-virus. Adopting other security technologies, such as those mandated by PCI Data Security Standard, has been a significant financial burden.
Pricing a product usually involves extracting the maximum possible amount that the customer is willing and able to pay. This is why vendors often employ price discrimination practices. For example, the vendor might offer a full-featured version of the product at a high price for customers who value the features and can afford them. The vendor might also offer a lightweight version at a lower price; this allows the company to capture the portion of the market that’s comprised of the customers who cannot justify or afford the higher expense.
Enterprise security vendors have had a hard time offering lower-priced versions for SMBs that include an attractive feature set. The cloud makes this easier by providing an alternative billing model with inherent price discrimination characteristics.
The Advantages of Cloud’s Billing Model for SMBs
One of the essential aspects of cloud computing, according to NIST SP 800-145, is measured service. It involves “leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts).” In other words, cloud providers can bill customers based on how much of the service was actually used.
SMBs that do not use many units of a security service find it more affordable use the pay-per-use billing model than paying for the product outright. This model also provides the product’s vendor with inherent price discrimination, since the customers who make greater use of the service pay more for it than the lower-volume customers.
A related aspect of cloud services billing model is its conversion of the initial expense of obtaining the product (capex) into a stream of regular payments called operating expenditure (opex). In the current economic climate, avoiding capex in favor of opex is attractive to many companies. This is particularly beneficial for SMBs, who might lack the cash flow to make a large capex payment, but who can keep up with opex payments.
For instance, consider the two-factor authentication feature that Google provides for its customers. Most SMBs wouldn’t have the money or the expertise to implement this security control for their systems. Yet, they get access to it by paying a relatively low monthly fee for Google Apps on per-user basis. (Google even offers this feature to its non-paying users.)
These financial aspects of cloud services give SMBs access to security technologies even when they would’ve been unable to afford to buy the tools outright. As cloud providers incorporate security services such as vulnerability scanning, log management and web application firewalls (WAFs) into their offerings, I expect to see more SMBs making use of the security services they wouldn’t normally consider for purchase. When that happens, everyone wins.
Security tends to dominate many discussions regarding the adoption of cloud computing. I outlined some of the risks that often come up in this context. Yet, which of the information security risks are actually unique to the cloud paradigm? Michael Cloppert raises this point in his insightful post Let’s Enable Cloud Computing.
Michael points out that most of the risks brought up in cloud discussions are applicable to IT in general and either have a mitigation strategy or have been accepted. He sums up the infosec community’s response to cloud security as “fear of the unknown,” concluding that:
“Classic InfoSec mindset is as a gateway; a veto-holding non-voting member of the IT community. The correct role, in my opinion, is as an active participant in technical innovation, architecture, and the engineering process, making sure requirements are met in a way that balances risk with cost - not eliminating risk at extraordinary cost.”
I tie the fear of the unknown to the desire to wait for cloud technologies and management processes to mature, and that’s fine with me. For instance, during early VLAN days, not many admins knew the syntax and the implication of certain commands, and were more likely introduce a configuration error that introduced a vulnerability. Similarly, many organizations implementing virtualization in the context of cloud computing are new to the tools and can make configuration mistakes. Further, the products they’re using are relatively immature and haven’t been time-tested.
The risks related to the newness of cloud technologies will become less of an issue in about a year. Until then, most security professionals will apply extra scrutiny to proposals that involve processing sensitive or regulated data in shared cloud environments. I think that’s a good idea, as long as the discussions don’t immediately lead to a flat “no way” as soon as the term “cloud” is brought up.
The biggest concern I have over outsourced cloud is that the economics are pushing a lot of companies to outsource without carefully understanding and codifying their requirements. Further, they might not know how to define a proper outsourcing contract, how to manage the IT transition project or how to oversee the resulting environment. These are the areas where experienced information security professionals can add a lot of value.
Want to know more? Read my earlier notes on cloud security.
Like any model of IT services, the cloud introduces several security challenges specific to this paradigm of computing.
Below are my top 10 cloud-specific risks that customers should understand and address when adopting cloud services. This is a summary of the key aspects of my earlier post on the topic.
If you found this useful, you might like my other cloud security posts.
Update: For a follow-up to this post, see my note on Cloud Risks and the Security Risks.
Security professionals are rightly concerned about their organizations starting to embrace cloud-based services even for applications that process sensitive and regulated data. Yet, cloud computing is a reality of today’s business and IT climate. Coming to terms with paradigm starts by understanding the terminology and key cloud frameworks and continues by considering the risks associated with such services. Once organizations delineate the risks worth worrying about, they can determine how to handle them.
Build Upon Your Existing Approaches to Risk
Don’t start from scratch when dealing with Governance, Risk and Compliance (GRC) issues of cloud computing. You might have already established approaches for reviewing logs, formalizing third-party vendor commitments, performing change management, and defined other controls that apply to IT infrastructure and applications regardless of how they are deployed. Build upon the tools, processes and people your organization has come to rely upon.
Risks Introduced by Key Cloud Characteristics
The risks particularly relevant to cloud services are those associated with the following characteristics of the cloud:
Concerns Over the Hypervisor
Discussions of cloud risks often highlight the possibility that the hypervisor, which handles virtualization of cloud IT resources, can be exploited. For instance:
Who Is Responsible For What?
Organizations that use an external/outsourced form of cloud services usually retain some security and regulatory responsibilities. Critical security and GRC tasks might not get done, because each party will assume that the other needs is responsible for them. This is because organizations often fail to define which obligations fall upon the cloud provider and which will be handled by the customer. For instance:
Creating a roles-and-responsibilities matrix prior to executing the cloud services contract will help prevent critical tasks falling through the cracks.
Visibility into The Cloud
Cloud services are often presented as black boxes that function according to the specifications. Yet, the inner-workings of such services is often not visible to the user. This makes it hard to define, validate and enforce security and related IT controls. Third-party attestations can shed some light on security practices of the cloud provider. Moreover, cloud providers may allow customer to review some security logs and events that occur within the cloud.
More Perspectives on Cloud Risks
Here are pointers to the papers I found particularly useful when considering cloud-related security risks:
[Because access to cloud] tools and resources doesn’t require major investments or time-consuming implementations, cloud technology encourages improvisation, experimentation, and tinkering — within and across enterprise boundaries.