Research

Guess what, folks – not only is industrial espionage rampant, but sometimes it’s supported by nation-states. Just ask Boeing about Airbus and France, or New Zealand about French operatives sinking a Greenpeace ship (and killing a few people in the process) on NZ territory. We’ve been hearing a lot lately about China, as highlighted by this Slashdot post that compiles a few different articles. No, Google isn’t threatening to pull out of China because they suddenly care more about human rights, it’s because it sounds like China might have managed to snag some sensitive Google goodies in their recent attacks. Here’s the deal. For a couple years now we’ve been hearing credible reports of targeted, highly-sophisticated cyberattacks against major corporations. Many of these attacks seem to trace back to China, but thanks to the anonymity of the Internet no one wants to point fingers. I’m moving into risky territory here because although I’ve had a reasonable number of very off the record conversations with security pros whose organizations have been hit – probably by China – I don’t have any statistical evidence or even any public cases I can talk about. I generally hate when someone makes bold claims like I am in this post without providing the evidence, but this strikes at the core of the problem: Nearly no organizations are willing to reveal publicly that they’ve been compromised. There is no one behind the scenes collecting statistical evidence that could be presented in public. Even privately, almost no one is sharing information on these attacks. A large number of possible targets don’t even have appropriate monitoring in place to detect these attacks. Thanks to the anonymity of the Internet, it’s nearly impossible to prove these are direct government actions (if they are). We are between a rock and a hard place. There is a massive amount of anecdotal evidence and rumors, but nothing hard anyone can point to. I don’t think even the government has a full picture of what’s going on. It’s like WMD in Iraq – just because we all think something is true, without the intelligence and evidence we can still be very wrong. But I’ll take the risk and put a stake in the ground for two reasons: Enough of the stories I’ve heard are first-person, not anecdotal. The company was hacked, intellectual property was stolen, and the IP addresses traced back to China. The actions are consistent with other policies of the Chinese government and how they operate internationally. In their minds, they’d be foolish to not take advantage of the situation. All nation-states spy, includig on private businesses. China just appears to be both better and more brazen about it. I don’t fault even China for pushing the limits of international convention. They always push until there are consequences, and right now the world is letting them operate with impunity. As much as that violates my personal ethics, I’d be an idiot to project those onto someone else – never mind an entire country. So there it is. If you have something they want, China will break in and take it if they can. If you operate in China, they will appropriate your intellectual property (there’s no doubt on this one, ask anyone who has done business over there). The problem won’t go away until there are consequences. Which there probably won’t be, since every other economy wants a piece of China, and they own too much of our (U.S.) debt to really piss them off. If we aren’t going to respond politically or economically, perhaps it’s time to start hacking them back. Until we give them a reason to stop, they won’t. Why should they? Share:

Over the past 7 years or so I’ve talked with thousands of IT professionals working on various types of data security projects. If I were forced to pull out one single thread from all those discussions it would have to be the sheer intimidating potential of many of these projects. While there are plenty of self-constrained projects, in many cases the security folks are tasked with implementing technologies or changes that involve monitoring or managing on a pretty broad scale. That’s just the nature of data security – unless the information you’re trying to protect is already in isolated use, you have to cast a pretty wide net. But a parallel thread in these conversations is how successful and impactful well-defined data security projects can be. And usually these are the projects that start small, and grow over time. Way back when I started the blog (long before Securosis was a company) I did a series on the Information-Centric Security Cycle (linked from the Research Library). It was my first attempt to pull the different threads of data security together into a comprehensive picture, and I think it still stands up pretty well. But as great as my inspired work of data-security genius is (*snicker*), it’s not overly useful when you have to actually go out and protect, you know, stuff. It shows the potential options for protecting data, but doesn’t provide any guidance on how to pull it off. Since I hate when analysts provide lofty frameworks that don’t help you get your job done, it’s time to get a little more pragmatic and provide specific guidance on implementing data security. This Pragmatic Data Security series will walk through a structured and realistic process for protecting your information, based on hundreds of conversations with security professionals working on data security projects. Before starting, there’s a bit of good news and bad news: Good news: there are a lot of things you can do without spending much money. Bad news: to do this well, you’re going to have to buy the right tools. We buy firewalls because our routers aren’t firewalls, and while there are a few free options, there’s no free lunch. I wish I could tell you none of this will cost anything and it won’t impose any additional effort on your already strained resources, but that isn’t the way the world works. The concept of Pragmatic Data Security is that we start securing a single, well-defined data type, within a constrained scope. We then grow the scope until we reach our coverage objectives, before moving on to additional data types. Trying to protect, or even find, all of your sensitive information at once is just as unrealistic as thinking you can secure even one type of data everywhere it might be in your organization. As with any pragmatic approach, we follow some simple principles: Keep it simple. Stick to the basics. Keep it practical. Don’t try to start processes and programs that are unrealistic due to resources, scope, or political considerations. Go for the quick wins. Some techniques aren’t perfect or ideal, but wipe out a huge chunk of the problem. Start small. Grow iteratively. Once something works, expand it in a controlled manner. Document everything. Makes life easier come audit time. I don’t mean to over-simplify the problem. There’s a lot we need to put in place to protect our information, and many of you are starting from scratch with limited resources. But over the rest of this series we’ll show you the process, and highlight the most effective techniques we’ve seen. Tomorrow we’ll start with the Pragmatic Data Security Cycle, which forms the basis of our process. Share:

The FireStarter is something new we are starting here on the blog. The idea is to toss something controversial out into the echo chamber first thing Monday morning, and let people bang on some of our more abstract or non-intuitive research ideas. For our inaugural entry, I’m going to take on one of my favorite topics – risk management. There seem to be few topics that engender as much endless – almost religious – debate as risk management in general, and risk management frameworks in particular. We all have our favorite pets, and clearly mine is better than yours. Rather than debating the merits of one framework over the other, I propose a way to evaluate the value of risk frameworks and risk management programs: Any risk management framework is only as valuable as the degree to which losses experienced by the organization were accurately predicted by the risk assessments. A risk management program is only as valuable as the degree to which its loss events can be compared to risk assessments. Pretty simple – all organizations experience losses, no matter how good their security and risk management. Your risk framework should accurately model those losses you do experience; if it doesn’t, you’re just making sh&% up. Note this doesn’t have to be quantitative (which some of you will argue anyway). Qualitative assessments can still be compared, but you have to test. As for your program, if you can’t compare the results to the predictions, you have no way of knowing if your program works. Here’s the ruler – time to whip ‘em out… Share:

A lot of my tech friends make fun of me for my minimal use of Google services. They don’t understand why I worry about the information Google collects on me. It isn’t that I don’t use any Google services or tools, but I do minimize my usage and never use them for anything sensitive. Google is not my primary search engine, I don’t use Google Reader (despite the excellent functionality), and I don’t use my Gmail account for anything sensitive. Here’s why: First, a quote from Eric Schmidt, the CEO of Google (the full quote, not just the first part, which many sites used): If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place, but if you really need that kind of privacy, the reality is that search engines including Google do retain this information for some time, and it’s important, for example that we are all subject in the United States to the Patriot Act. It is possible that that information could be made available to the authorities. I think this statement is very reasonable. Under current law, you should not have an expectation of privacy from the government if you interact with services that collect information on you, and they have a legal reason and right to investigate you. Maybe we should have more privacy, but that’s not what I’m here to talk about today. Where Eric is wrong is that you shouldn’t be doing it in the first place. There are many actions all of us perform from day to day that are irrelevant even if we later commit a crime, but could be used against us. Or used against us if we were suspected of something we didn’t commit. Or available to a bored employee. It isn’t that we shouldn’t be doing things we don’t want others to see, it’s that perhaps we shouldn’t be doing them all in one place, with a provider that tracks and correlates absolutely everything we do in our lives. Google doesn’t have to keep all this information, but since they do it becomes available to anyone with a subpoena (government or otherwise). Here’s a quick review of some of the information potentially available with a single piece of paper signed by a judge… or a curious Google employee: All your web searches (Google Search). Every website you visit (Google Toolbar & DoubleClick). All your email (Gmail). All your meetings and events (Google Calendar). Your physical location and where you travel (Latitude & geolocation when you perform a search using Google from your location-equipped phone). Physical locations you plan on visiting (Google Maps). Physical locations of all your contacts (Maps, Talk, & Gmail). Your phone calls and voice mails (Google Voice). What you read (Search, Toolbar, Reader, & Books) Text chats (Talk). Real-time location when driving, and where you stop for food/gas/whatever (Maps with turn-by-turn). Videos you watch (YouTube). News you read (News, Reader). Things you buy (Checkout, Search, & Product Search). Things you write – public and private (Blogger [including unposted drafts] & Docs). Your photos (Picassa, when you upload to the web albums). Your online discussions (Groups, Blogger comments). Your healthcare records (Health). Your smarthome power consumption (PowerMeter). There’s more, but what else do we care about? Everything you do in a browser, email, or on your phone. It isn’t reading your mind, but unless you stick to paper, it’s as close as we can get. More importantly, Google has the ability to correlate and cross-reference all this data. There has never before been a time in human history when one single, private entity has collected this much information on a measurable percentage of the world’s population. Use with caution. Share:

I’m incredibly excited to finally announce that as of today, Mike Rothman is joining Securosis. This is a full merger of Security Incite and Securosis, and something I’ve been looking forward to for years. Back when I started the Securosis blog over 3 years ago I was still an analyst at Gartner and was interested in participating more with the open security community. A year later I decided to leave Gartner and the blog became my employer. I wasn’t certain exactly what I wanted to do, and was restricted a bit due to my non-compete, but I quickly learned that I was able to support myself and my family as an independent voice. Mike was running Incite at the time, and seeing him succeed helped calm some of my fears about jumping out of a stable, enjoyable job. Mike also gave me some crucial advice that was incredibly helpful as I set myself up. One of my main goals in leaving Gartner was to gain the freedom to both participate more with, and give back to, the security community. Gartner was great, but the nature of its business model prevents analysts from giving away their content to non-clients, and restricts some of their participation in the greater community. It’s also hard to perform certain kinds of primary research, especially longer-term projects. Since I had a non-compete, I sort of needed to give everything away for free anyway. Things were running well, but I was also limited in how much I could cover or produce on my own. I may have published more written words than any other security analyst out there (between papers and blog posts), but it was still a self-limiting situation. Then about 18 months ago Adrian joined and turned my solo operation into an actual analyst firm. At the same time Mike and I realized we shared a common vision for where we’d like to take the research and analysis game, and started setting up to combine operations. We even had a nifty company name and were working on the nitty-gritty details. When we had our very first conversation about teaming up, Mike told me there was only one person he’d work for again, but there wasn’t anything on the radar. Then, of course, he got the call right before we wrote up the final paperwork. We both saw this as a delay, not an end, and the time is finally here. This is exciting to me for multiple reasons. First, we now gain an experienced analyst who has been through the wringer with one of the major firms (Meta), thrived as an independent analyst, and fought it out on the mean streets of vendor-land. There aren’t many great analysts out there – and even fewer with Mike’s drive, productivity, experience, and vision. This also enables us to create the kind of challenging research environment I’ve missed since leaving Gartner. With Mike and our Contributors (David Mortman, David Meier, and Chris Pepper) we now have a team of six highly-opinionated and experienced individuals ready to challenge and push each other in ways simply not possible with only 2-3 people. Mike also shares my core values. Everything we write is for the end user, no matter the actual target audience. We should always give away as much as possible for free. We should conduct real primary research, as opposed to merely commenting on the world around us. Everything we produce should be pragmatic and help someone get their job done better and faster. Our research should be as objective and unbiased as possible, and we’ll use transparency and our no-BS approach as enforcement mechanisms. Finally, we’re lifers in the security industry – this is a lifestyle business, not a get-rich-quick scheme. This is also an amazing opportunity to work closely with one of the people I respect most in our industry. Someone I’ve become close friends with since first meeting on the rubber-chicken circuit. In our updated About section and the Merger FAQ, there’s a lot of talk about all the new things this enables us to do, and the additional value for our supporters and paying clients. But to me the important part is I get to work with someone I like and respect. Someone I know will push me like few others out there. Someone who shares my vision, and is fun to work with. The only bad part is the commute. It’s going to be a real bi%^& to fly Mike out to Phoenix for Happy Hour every week. Share:

Fall of 2009 marks the 20th anniversary of the start of my professional security career. That was the first day someone stuck a yellow shirt on my back and sent me into a crowd of drunk college football fans at the University of Colorado (later famous for its student riots). I’m pretty sure someone screwed up, since it was my first day on the job and I was assigned a rover position – which normally goes to someone who knows what the f&%$ they are doing, not some 18 year old, 135-lb kid right out of high school. And yes, I was breaking up fights on my first day (the stadium wasn’t dry until a few years later). If you asked me then, I never would have guessed I’d spend the next couple decades working through the security ranks, eventually letting my teenage geek/hacker side take over. Over that time I’ve come to rely on the following guiding principles in everything from designing my personal security to giving advice to clients: Don’t expect human behavior to change. Ever. You cannot survive with defense alone. Not all threats are equal, and all checklists are wrong. You cannot eliminate all vulnerabilities. You will be breached. There’s a positive side to each of these negative principles: Design security controls that account for human behavior. Study cognitive science and practical psychology to support your decisions. This is also critical for gaining support for security initiatives, not just design of individual controls. Engage in intelligence and counter-threat operations to the best of your ability. Once an attack has started, your first line of security has already failed. Use checklists to remember the simple stuff, but any real security must be designed using a risk-based approach. As a corollary, you can’t implement risk-based security if you don’t really understand the risks; and most people don’t understand the risks. Be the expert. Adopt anti-exploitation wherever possible. Vulnerability-driven security is always behind the threat. React faster and better. Incident response is more important than any other single security control. With one final piece of advice – keep it simple and pragmatic. And after 20 years, that’s all I’ve got… Share:

One of the more difficult aspects of medical research is correlating treatments/actions with outcomes. This is a core principle of science based medicine (if you’ve never worked in the medical field, you might be shocked at the lack of science at the practitioner level). When performing medical studies the results aren’t always clean cut. There are practical and ethical limits to how certain studies can be performed, and organisms like people are so complex, living in an uncontrolled environment, that results are rarely cut and dried. Three categories of studies are: Pre-clinical/biological: lab research on cells, animals, or other subsystems to test the basic science. For example, exposing a single cell to a drug to assess the response. Experimental/clinical: a broad classification for studies where treatments are tested on patients with control groups, specific monitoring criteria, and attempts to control and monitor for environmental effects. The classic double blind study is an example. Observational studies: observing, without testing specific treatments. For example, observational studies show that autism rates have not increased over time by measuring autism rates of different age groups using a single diagnostic criteria. With rates holding steady at 1% for all living age groups, the conclusion is that while there is a perception of increasing autism, at most it’s an increase in diagnosis rates, likely due to greater awareness and testing for autism. No single class of study is typically definitive, so much of medicine is based on correlating multiple studies to draw conclusions. A drug that works in the lab might not work in a clinical study, or one showing positive results in a clinical study might fail to show desired long-term outcomes. For example, the press was recently full of stories that the latest research showed little to no improvement in long-term patent outcomes due to routine mammograms for patients without risk factors before the age of 50. When studies focus on the effectiveness of mammograms detecting early tumors, they show positive results. But these results do not correlate with improvements in long-term patient outcomes. Touchy stuff, but there are many studies all over medicine and other areas of science where positive research results don’t necessarily correlate with positive outcomes. We face the same situation with security, and the recent debate over password rotation highlights (see a post here at Securosis, Russell Thomas’s more-detailed analysis, and Pete Lindstrom’s take). Read through the comments and you will see that we have good tools to measure how easy or hard it is to crack a password based on how it was encrypted/hashed, length, use of dictionary words, and so on, but none of those necessarily predict or correlate with outcomes. None of that research answers the question, “How often does 90 day password rotation prevent an incident, or in what percentage of incidents did lack of password rotation lead to exploitation?” Technically, even those questions don’t relate to outcomes, since we aren’t assessing the damage associated with the exploitation (due to the lack of password rotation), which is what we’d all really like to know. When evaluating security, I think wherever possible we should focus on correlating, to the best of our ability, security controls with outcomes. Studies like the Verizon Data Breach Report are starting to improve our ability to draw these conclusions and make more informed risk assessments. This isn’t one of those “you’re doing it wrong” posts. I believe that we have generally lacked the right data to take this approach, but that’s quickly changing, and we should take full advantage of the opportunity. Share:

On Friday I asked a simple question over Twitter and then let myself get dragged into a rat-hole of a debate that had people pulling out popcorn and checking the latest odds in Vegas. (Not the odds on who would win – that was clear – but rather on the potential for real bloodshed). And while the debate strayed from my original question, it highlighted a major problem we often have in the security industry (and probably the rest of life, but I’m not qualified to talk about that). A common logical fallacy is to assume that a possibility is a probability. That because something can happen, it will happen. It’s as if we tend to forget that the likelihood something will happen (under the circumstances in question) is essential to the risk equation – be it quantitative, qualitative, or whatever. Throughout the security industry we continually burn our intellectual capital by emphasizing low-probability events. “Mac malware might happen so all Mac users should buy antivirus or they’re smug and complacent”. Forgetting the fact that the odds of an average Mac user being infected by any type of malware are so low as to be unmeasurable, and lower than their system breaking due to problems with AV software. Sure, it might change. It will probably change; but we can’t predict that with any certainty and until then our response should match the actual (current) risk. Bluetooth attacks are another example. Possible? Sure. Probable? Not unless you’re at a security or hacker conference. There are times, especially during scenario planning, to assume that anything that can happen will happen. But when designing your actual security we can’t equate all threats. Possible isn’t probable. The mere possibility of something is rarely a good reason to make a security investment. Share:

I had one of those weird moments today where I found an unrelated part of my life unexpectedly influenced by my martial arts background. I was asked to critique a research paper by someone I haven’t worked with before. Without going into details, this particular paper had a fatal flaw. It opened with a negative position, then attempted to justify the positive. It started defensively, and in the process lent credence to the opposing view, as opposed to strengthening the author’s position. In other words, it started with, “here’s what you say about X, and why I think Y” as opposed to, “here is position Y, and why it is correct and X is wrong”. In advising the author, I remembered a lesson I learned when I first started teaching martial arts (traditional taekwondo). I was giving a class on unarmed restraint techniques, which adapted some experiences in physical security to martial arts. They’re similar to police restraint techniques, but adjusted for not having a firearm (police techniques involve protecting the firearm so the bad guy can’t grab it while being restrained) or handcuffs. In the class were two of my instructors, helping me learn to teach. I started by saying something like, “I’m no expert”, and one of them walked off right then and there. At a break he came back and asked if I knew why he had left. He told me to never start a lesson or debate by disqualifying myself as an authority. I essentially told the class they shouldn’t listen to me, because I didn’t know what the frack I was talking about. Self-deprecating humor, applied appropriately, is fine – but never start from a position of weakness. I was trying to be humble, but instead destroyed any reason someone would want to learn from me. Over time I expanded this lesson to “Never start with a negative when your goal is to prove a positive.” Essentially, that places the opposing view ahead of yours and forces you into a defensive position. If I’m writing research to show the value of DLP, I sure as heck better not start it with all the criticisms against DLP. It’s kind of like a fight. If you allow the opponent to control the ring and dictate the pace, your odds of winning are much lower. You can never win on defense alone. One important corollary is that you also shouldn’t expect someone to agree with your position based on your credentials alone. I get seriously annoyed by other analysts/pundits who make pronouncements, yet never back them with evidence. Start from a position of strength (assuming you are the expert), but also lead the reader, with evidence and logic, to reach your conclusions for themselves. Most black belts are crappy martial artists and teachers… if their techniques suck, find another one. Respect still needs to be earned. Enough with the preachy stuff… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on What IBM’s Acquisition of Guardium Really Means. Rich was quoted on Scottrade regarding Rapid7. Adrian was quoted by Information Security Magazine, PC Magazine, The Boston Globe, Network World, and Dark Reading on IBM’s acquisition of Guardium. Rich was picked up a bunch on the Bit.ly security additions, including this mention at eWeek. Episode 175 of The Network Security Podcast. Favorite Securosis Posts Rich: Adrian on Top Questions Regarding Guardium Acquisition Adrian: Rich’s post on Coming Soon: Bit.ly Adding Real Time Security Scanning for All Links. Mort: Quick Thoughts on the Point of Sale Security Fail Lawsuit Meier: Quick Thoughts on the Point of Sale Security Fail Lawsuit – I’ve personally found a few PoS with card readers wide open at Mom ‘n’ Pop shops. Other Securosis Posts Sign Up To Drop Comment Moderation Cloud Risk Thoughts: Deciding What, When, and How to Move to the Cloud Serious Flaw in Clientless SSL VPNs & Clientless SSL VPN Redux Christmas Wish Guardium Acquired by IBM We Give Thanks M86 Acquires Finjan Microsoft IE Issues Reported Health Net Asked to Explain Disclosure Delay Project Quant for Databases: Project Quant: Database Security Planning, Part 2 (part 3) Project Quant: Database Security Planning (part 2) Project Quant: Database Security Process Framework (part 1) Favorite Outside Posts Rich: What the Black Screen of Death Story Says About Journalism. Serious fail on the part of PrevX – they should be ashamed, and have just destroyed any reason for people to trust them. Adrian: It’s Homeric in length for a blog post, but Hoff’s post The Cloud in Context is a great overview of Cloud computing. Mort: Real Security Is Threat-Centric. Not seeing this change anytime soon, alas. Meier: Used ATM Machines for sale on Craigslist. My new weekend hobby! Pepper: Recommendation: Disable Invisible Flash. Flash cookies are evil. Rich #2: This is a must-read article on how few breaches really get reported. The winning quote: “Of the thousands of cases that we’ve investigated, the public knows about a handful,” said Shawn Henry, assistant director for the Federal Bureau of Investigation’s Cyber Division. “There are million-dollar cases that nobody knows about.” Top News and Posts Google launches public DNS resolvers. I use EasyDNS for this myself, being a bit paranoid about the power Google is accumulating. But they do have an excellent privacy policy for this service. Researcher busts into Twitter via SSL reneg hole And they said it couldn’t be done! 79 million records exposed in government breaches. We were named one of the top analyst blogs. Two security tools for analyzing relationships in social networks. More on the Rybolov Information Security Management Model. Layer8: BSOFH: the roar of the packets, the smell of the cloud. True stupidity: woman calls in a fake bomb threat to delay a plane. From the TSA blog. Ray Wagner from Gartner on personal security at work. Hackers attempt to take $1.3M from small business account. If you are in security, and don’t understand the ACH system, it’s time to educate yourself. Users aren’t the weakest link if your security sucks. Cool password research from Microsoft. Blog Comment of the Week This week’s best comment comes from David in response to Quick Thoughts on the Point of Sale

I’ve been working with the Cloud Security Alliance on the next revision of their official Security Guidance document, and we decided to include a short note on risk in the beginning, to help add some context. Although we are deep in the editorial process, I realized this is the sort of thing I should put out for some public comment, as it’s at the beginning of the document and will help frame how it’s read. With so many different cloud deployment options – including SaaS vs. PaaS vs. IaaS, public vs. private, internal vs. external, and various hybrid scenarios – no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions. This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick mechanism for evaluating your tolerance for moving an asset to various different cloud computing models. There is a full section on risk management in the Guidance, and I’m also working on a data security specific post to mesh with the other cloud data security content I’m developing. Identify the asset for the cloud deployment At the simplest, assets supported by the cloud fall into two general buckets: Data Applications/Functions/Processes We are either moving information into the cloud, or transactions/processing (from partial functions, all the way up to full applications). With cloud computing our data and applications don’t need to reside in the same location, and we can even shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service. The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud, to account for scope creep. Data and transaction volumes are often higher than expected, and cloud deployments often scale higher than anticipated. Evaluate the asset The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is. For each asset, ask the following questions: How would we be harmed if the asset became public and widely distributed? How would we be harmed if an employee of our cloud provider accessed the asset? How would we be harmed if the process or function was manipulated by an outsider? How would we be harmed if the process or function failed to provide expected results? How would we be harmed if the information/data was unexpectedly changed? How would we be harmed if the asset was unavailable for a period of time? Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how those are affected if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we also have a wider array of deployment options including internal models. Map the asset to potential cloud deployment models Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models – private, public, community, or hybrid and internal vs. external options. For the asset, determine if you are willing to accept the following options: Public. Private, internal/on-premises. Private, external (including dedicated or shared infrastructure). Community; taking into account the hosting location, service provider, and identification of other community members. Hybrid. To effectively evaluate a potential hybrid deployment, you must to have at least a rough architecture of where components, functions, and data will reside. At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations best fit your security and risk requirements. Evaluate potential cloud service models In this step focus on the degree of control you’ll have at each SPI tier (Software, Platform, or Infrastructure as a Service) to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk assessment. Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of PCI regulated data) you can include them in the evaluation. Sketch the potential data flow If you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high-level, before making a final decision it’s absolutely essential to understand whether, and how, data can move in and out of the cloud. If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as you make final decisions, you’ll be able to identify risk exposure points. Document Conclusions You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. You’ll also have a rough idea of potential exposure points for sensitive information and operations. These together should give you sufficient context to evaluate any other security controls. For low-value assets you don’t need the same level of security controls and can skip many of