Research

Securosis has a long history of following and publishing on data security. Rich was the lead analyst on DLP about a zillion years ago during his time with Gartner. And when Securosis first got going (even before Mike joined), it was on the back of data security advisory and research. Then we got distracted by this cloud thing, and we haven’t gone back to refresh our research, given some minor shifts in how data is used and stored with SaaS driving the front office and IaaS/PaaS upending the data center (yes that was sarcasm). We described a lot of our thinking of the early stages of this transition in Tidal Forces 1 and Tidal Forces 3, and it seems (miraculously) a lot of what we expected 3 years ago has come to pass. But data security remains elusive. You can think of it as a holy grail of sorts. We’ve been espousing the idea of “data-centric security” for years, focusing on protecting the data, which then allows you to worry less about securing devices, networks, and associated infrastructure. As with most big ideas, it seemed like a good idea at the time. In practice, data-centric security has been underwhelming as having security policy and protection travel along with the data, as data spreads to every SaaS service you know about (and a bunch you don’t know about), was too much. How did Digital Rights Management work at scale? Right. The industry scaled back expectations and started to rely on techniques like tactical encryption, mostly using built-in capabilities (FDE for structured data, and embedded encryption for file systems). Providing a path of least resistance to both achieve compliance requirements, as well as “feel” the data was protected. Though to be clear, this was mostly security theater, as compromising the application still provided unfettered access to the data. Other techniques, like masking and tokenization, also provided at least a “means” to shield the sensitive data from interlopers. New tactics like test data generation tools also provide an option to ensure that developers don’t inadvertently expose production data. But even with all of these techniques, most organizations still struggle with protecting their data. And it’s not getting easier. The Data Breach Triangle Back in 2009, we introduced a concept called The Data Breach Triangle, which gave us a simple construct to enumerate a few different ways to stop a data breach. You need to break one of the legs of the triangle. Data: The equivalent of fuel – information to steal or misuse. Exploit: The combination of a vulnerability or an exploit path to allow an attacker unapproved access to the data. Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive. Most of the modern-day security industry focused on stopping the exploit, either by impacting the ability to deliver the exploit – firewall/IPS or preventing the compromise of the device – endpoint protection. There also were attempts to stop the egress of sensitive data via outbound filters/FW/web proxy or DLP. As described above, attempts to either protect or shield the data have been hard to achieve at scale. So what do we get? Consistent breaches. Normalized breaches. To the point that an organization losing tens of millions of identities no longer even registers as news. SaaS exacerbates the issue Protecting data continues to get more complicated. SaaS has won. As we described in Tidal Forces, SaaS is the new front office. If anything, the remote work phenomenon driven by the inability to congregate in offices safely will accelerate this trend. Protecting data was hard enough when we knew where it was. I used to joke how unsettling it was back in 1990 when my company outsourced the mainframe, and it was now in Dallas, as opposed to in our building in Arlington, VA. At least all of our data was in one place. Now, most organizations have dozens (or hundreds) of different organizations controlling critical corporate data. Yeah, the problem isn’t getting easier. Rethinking Data Security What we’ve been doing hasn’t worked. Not at scale anyway. We’ve got to take a step back and stop trying to solve yesterday’s problem. Protecting data by encrypting it, masking it, tokenizing it, or putting a heavy usage policy around it wasn’t the answer, for many reasons. The technology industry has rethought applications and the creation, usage, and storage of data. Thus, we security people need to rethink data security for this new SaaS reality. We must both rethink the expectations of what data security means, as well as the potential solutions. That’s what we’ll do in this blog series Data Security for the SaaS Age. We haven’t been publishing as much research over the past few years, so it probably makes sense to revisit our Totally Transparent Research methodology. We’ll post all of the research to the blog, and you can weigh in and let us know that we are full of crap or that we are missing something rather important. Comments on this post are good or reach out via email or Twitter. Once we have the entire series posted and have gathered feedback from folks far smarter than us, we package up the research as a paper and license it to a company to educate its customers. In this case, we plan to license the paper to AppOmni (thanks to them), although they can decide not to license it at the end of the process – for any reason. This approach allows us to write our research without worrying about anyone providing undue influence. If they don’t like the paper, they don’t license it. Simple. In the next post, we focus on the solution, which isn’t a product or a service; rather it’s a process. We update the Data Security Lifecycle for modern times, highlighting the need for a systematic approach to identifying critical data and governing the use of that data in

Do you ever play those wacky question games with your friends? You know, where the questions try to embarrass you and make you say silly things? I was never much of a game player, but sometimes it’s fun. At some point in every game, a question about your favorite physical feature comes up. A lot of people say their eyes. Or their legs. Or maybe some other (less obvious) feature. It would also be interesting to ask your significant other or friends what they thought. I shudder to think about that. But if you ask me, the answer is pretty easy. It’s my hair. Yeah, that sounds a bit vain, but I do like my hair. Even though it turned gray when I was in my early 30s, that was never an impediment. It probably helped early in my career, as it made me seem a bit older and more experienced, even though I had no idea what I was doing (I still don’t). The only issue that ever materialized was when I first started dating Mira (who also has great hair). She showed my picture to her daughter (who was 12 at the time), and she asked, “why are you dating that old guy?” That still cracks me up. This COVID thing has created a big challenge for me. I usually wear my hair pretty short, trimmed with a clipper on the sides, and styled up top. But for a couple of months, seeing my stylist wasn’t an option. So my hair has grown. And grown. And grown. As it gets longer, it elevates. It’s like a bird’s nest elevation. You know, like losing your keys in there elevation. I could probably fit a Smart Car in there if I don’t get it cut at some point soon. If I’m going to grow my hair out, I want to have Michael Douglas’s hair. His hair is incredible, especially during his Black Rain period. The way his hair flowed as he was riding the motorcycle through Tokyo in that movie. It was awesome, but that is not to be. My destiny is to have big bird nest hair. Mira told me to shave it off. I have a bunch of friends that have done the home haircut, and it seems to work OK. I learned that a friend of mine has been doing his hair at home for years. And he looks impeccable even during the pandemic. I’m a bit jealous. I even bought a hair clipper to do it myself. I figured I’d let one of the kids have fun with it, and it would make for a fun activity. What else are we doing? The clipper is still in its packaging. I can’t bring myself to use it. Even if the self-cut turned out to be a total fiasco, my hair grows so fast it would only take a few weeks to grow out. So we aren’t talking about common sense here. There is something deeper in play, which took me a little while to figure out. I used to wear my hair very short in college during my meathead stage. So it’s not that I’m scared of really short hair. Then I remembered the one time I did a buzz cut as an adult. It was the mid-90s when I was 60 lbs heavier and into denim shirts. Yes, denim shirts were cool back then, trust me. So combine a big dude with a buzz cut in a denim shirt, and then one of my friends told me I looked like Grossberger from Stir Crazy, that was that. No more buzz cut. Clearly, I’m still scarred from that. I guess I have a bit of a Samson complex. It’s like I’ll lose my powers if I get a terrible haircut. I’m not sure what powers I have, but I’m not going to risk it. I’ll just let the nest keep growing. Mira says she likes it, especially when I gel my hair into submission and comb it straight back. I call it the poofy Gekko look. But I fear the gel strategy won’t last for much longer. By the end of the day, the top is still under control, but my sides start to go a little wacky, probably from me running my hands through my hair throughout the day. I kind of look like Doc Brown from Back to the Future around 6 PM. It’s pretty scary. What to do? It turns out hair salons were one of the first businesses to reopen in Georgia. So I made an appointment for mid-June to get a cut from my regular stylist. Is it a risk? Yes. And I’ve never checked her license, but I’m pretty sure her name isn’t Deliah. The salon is taking precautions. I’ll be wearing a mask and so will she. We have to wait outside, and she cleans and disinfects everything between customers. It’s a risk that I’m willing to take. Because at some point, we have to return to some sense of normalcy. And for me, getting my hair cut without risking a Grossberger is the kind of normalcy I need. Share:

The pandemic is hard on everyone. (says the Master of the Obvious) It’s a combination of things. There are layers of fear — both from the standpoint of the health impact, as well as the financial challenges facing so many. We cannot underestimate the human toll, and unfortunately, the US has never prioritized mental health. As I mentioned last week in my inaugural new Insight, I’m not scared for myself, although too many people I care about are in vulnerable demographics. I’m lucky that (at least for now) the business is OK. I work in an industry that continues to be important and for a company that is holding its own. But it’s hard not to let the fear run rampant. The Eastern philosophies teach us to stay in the moment. To try to focus on what’s right in front of you. Do not fixate on decisions made or roads not taken. Do not think far ahead about all of the things that may or may not come to pass. Stay right here in the experience of the present. And I try. I really try to keep the things I control at the forefront. Yet there is so much I don’t control about this situation. And that creates a myriad of challenges. For example, I don’t control the behavior of others. I believe the courteous thing to do now is wear a mask when in public. There are certainly debates about whether the masks make a real difference in controlling the spread of the novel coronavirus. But when someone near me is wearing a mask, it’s a sign (to me anyway) that they care about other people. Maybe I’m immunocompromised (thankfully I’m not). Maybe I live with someone elderly. They don’t know. The fact is they likely don’t have the infection. But perhaps they do. It’s about consideration, not about personal freedoms. I have the right to approach someone sitting nearby and fart (from 6 feet away, of course). But I don’t do that because it’s rude. I put wearing a mask into the same category. But alas, I don’t control whether other people wear masks. I can only avoid those that don’t. NY Governor Andrew Cuomo said it pretty well. I don’t control who takes isolation seriously and who doesn’t. Many people have decided to organize small quarantine pods who isolate with each other because they don’t see anyone else. This arrangement requires discipline and trust and doesn’t scale much past 2 or 3 families. Being in a blended household means that I had my pod defined for me. There are my household and the households of both of our former spouses. It’s hard to keep everyone in sync. My kids were staying with their Mom in the early days of quarantine. But my son was seeing other kids in the neighborhood. Not a lot, but a few. And supposedly those kids were staying isolated – until they weren’t. One of the neighbors had a worker in the house and then had a visitor who was a healthcare professional in Canada. Sigh. So he goes into isolation for two weeks, and I can’t see my kids. Then my former spouse got religion about isolation and decided that she wasn’t comfortable with my pod, which includes Mira’s former spouse. She doesn’t know him, and in this situation, trust is challenging. Sigh. Another six weeks of not seeing my kids. Mira and I have done a few social distance walks with them, but it’s hard. You wonder if they are too close. So we adapted and set up chairs in a parking lot and hung out. It’s tough. All I wanted to do was hug my kids, but I couldn’t. To be clear, in the grand scheme of things, this is a minor problem. A point in time that will pass. Maybe in 6 months, or maybe in a year. But it will pass. And I’ve got it good, given my health and ability to still work. Many people don’t. They may be alone, or they may not have a job. Those are big problems. But I also don’t want to minimize my experience. It sucks not to be able to parent your kids. It’s getting more complicated by the day. Things in Georgia (where I live) are opening up. Many of the kid’s friends are getting together, and the reality is that we can’t keep them isolated forever. So their Mom and I decided we would keep things locked down through the end of May and then revisit our decision in June. My kids could stay with me for a little while. And that happened last week. When I went over to pick them up, I was overcome. It was only a hug, but it felt like a lot more than that. Over the past week, I got to wake them up, pester them to do online classes, eat with them, and sit next to them as we watched something on Netflix. We were going to figure out week by week where the kids would stay. I’m not going anywhere, so that would work great. But the best-laid plans… I found out that my oldest is seeing her friends. And isn’t socially distancing. Sigh. She’s an adult (if you call 19 an adult), and she made the decision. I’m unhappy but trying to be kind. I’m trying to understand her feelings as her freshman year in college abruptly ended. She went from the freedom of being independent (if you call college independent living) to being locked up in her Mom’s house. That when you are 19, you don’t really think about the impact of your actions on other people. That you can get depressed and forget about the rules and do anything to take a drive with a couple of friends. And now the other house where my kids live is no longer in my pod. One of the kids is with me, and she’ll stay for a couple of

It’s a sunny late spring day. Mike steps into the dank building and can smell the must. It feels old but familiar. Strangely familiar. The building looks the same, but he knows it’s different. Too much time has passed. He steps into the confessional and starts to talk. Mike: Forgive me. It’s been almost 3 and a half years since I’ve been here. I’d say it was because I have been busy, which I have. But it’s not that. I spent close to 13 years here, and I had gone through a pretty significant personal transformation. As I was navigating the associated transitions, I guess I just wanted to live a bit and integrate a lot of the lessons I’ve learned behind the scenes for a while. Confessor: OK. That seems reasonable. How’s that been going? Mike: Pretty good, I’d say. I mentioned my new love (her name is Mira). We got married in mid-2017. I’ve packed my oldest daughter off to college last August and my step-son leaves for his college hopefully at the end of this summer. We’ve got a wonderful blended family and we’ve made some close friends as well. Physically I’m good as well. I’ve been able to maintain my fitness through intense workouts (thanks to OrangeTheory) and use the time in class as my mindfulness practice. And I just try to improve a little bit each day and live my life with kindness and grace. Confessor: How’s work going? You mentioned being busy, but what does that mean? Everyone is busy. Mike: That’s a good point. Culturally there is some kind of weird incentive to be busy. Or to look busy, anyway. Rich and I have been grinding away. Adrian decided to move on last December, so we’ve just kept pushing forward. Evidently cloud security is a thing, so we’ve benefited from being in the right place at the right time. But we spend a lot of time thinking about how work changes and the impact to security. We don’t quite know what it will look like, but we’re pretty sure it accelerates a lot of the trends we’ve been talking about for the past 5 years. I’m also happy to say DisruptOps is doing well (we closed a Series A back in late February). I guess I’m just grateful. I work with great people and I can still pay the bills, so no complaints. Confessor: Hmmm. So you are in a good spot personally and the business is doing well. It seems that you used the time away from here productively. Why come back now? Mike: I found that being here was a way of documenting my journey, for me. And that many of the people here enjoyed it and learned a thing or two. The fact is we are in the midst of a very uncertain time. Our society has undergone shocks to the system and we’re all trying to figure out what a “new normal” looks like. I don’t have any answers, to be clear, but I want to share my fears, my hopes, and my experiences and hope that we’ll all navigate these challenging and turbulent waters together. Confessor: Fear. That’s a good place to start. What are you scared of? Mike: Simply put, that COVID-19 impacts people that I love. We’ve been lucky so far, taking the quarantine seriously, but I am not taking that for granted and continuing to stay inside. Good thing I can come here virtually. Strangely enough, I have little fear regarding my own physical well-being. I made a deal with Mira that we’d be together for at least 44 years and I plan to make good on that deal. But our parents are old and in some cases, immunocompromised. We can’t control what other people do and whether they respect the threat or the science. So it’s definitely scary. Confessor: How are you holding up mentally? Mike: It’s tough. My head was spinning. I was consumed by the news and reacting to most every Tweet. It wasn’t productive. So I’ve started seated meditation again. I just needed to shut down my thoughts, even for a short time, and open up to possibility. To get into the habit of controlling my thoughts, my outlook, and my mood. Meditation helps me do that. And it’s hard to not be able to do the things we love and have no idea when things will return to some semblance of normal. You know, doing simple things that I took for granted, like travel. Mira and I love to travel and we’re very fortunate to go on very cool trips. We can’t see shows or live sports for the time being. That sucks. I also value the time I can spend with clients and at conferences. Who knew that the RSA Conference would be the last time many of us will travel for business for who knows how long? But you make the best of it. Confessor: We’ve changed a lot in the time that you were away. There are new people here. Some have moved on. Mike: It’s not like I’m the same person either. We’re all constantly changing. The goal is to navigate change in the most graceful way possible. I like to think my changes have been positive. I don’t need to act like a grump anymore, I was happy to leave that aspect of my persona behind. I think there is also something to be said about the wisdom of experience. I don’t claim to be wise, but I have a lot of experience. Mostly screwing things up. Hopefully, I’ll be able to continue sharing that experience here and we can learn together. We’re in uncharted territory and that can be pretty exciting if you are open to the inevitable changes ahead. Confessor: So when will you be back? And I suspect it won’t look the same, will it? Mike: You are pretty perceptive. I always enjoyed that about being here. I’m going to aim to

April 7 Update: some research is emerging since I posted this that COVID related ARDS is not typical ARDS. Here’s the medical reference for providers but it’s very early evidence so far we should keep an eye on: COVID-19 Does Not Lead to a “Typical” ARDS. This was further validated by an article in MedScape that previews some emerging peer-reviewed research. Thus while my explanations of ARDS and ventilators is accurate, the ties to COVID-19 are not and new treatment protocols are emerging. Although this is a security blog, this post has absolutely nothing to do with security. No parallels from medicine, no mindset lessons, just some straight-up biology. As many readers know I am a licensed Paramedic. I first certified in the early 1990’s, dropped down to EMT for a while, and bumped back up to full medic two years ago. Recently I became interested in flight and critical care and completed an online critical care and flight medic course from the great team at FlightBridgeED. Paramedics don’t normally work with ventilators – it is an add-on skill specific for flight and critical care (ICU) transports. I’m a neophyte to ventilator management, with online and book training but no practice, but I understand the principles, and thanks to molecular biology back in college, have a decent understanding of cellular processes. COVID-19 dominates all our lives now, and rightfully so. Ventilators are now a national concern and one the technology community is racing to help with. Because of my background I’ve found myself answering a lot of questions on COVID-19, ARDS, and ventilators. While I’m a neophyte at running vents, I’m pretty decent at translating complex technical subjects for non-experts. Here’s my attempt to help everyone understand things a bit better. The TL;DR is that COVID-19 damages the lungs, which for some people triggers the body to overreact with too much inflammation. This extra fluid interferes with gas exchange in the lungs, and oxygen can’t as easily get into the bloodstream. You don’t actually stop breathing, so we use the ventilators to change pressure and oxygen levels, in an attempt to diffuse more oxygen through this barrier and into the lungs without, causing more damage by overinflating them. We start with respiration Before we get into COVID and ventilators we need to understand a little anatomy and physiology. Cells need oxygen to convert fuel into energy. Respiration is the process of getting oxygen into cells and removing waste products – predominantly CO2. We get oxygen from our environment and release CO2 through ventilation: air moving in and out of our lungs. Those gases are moved around in our blood, and the actual gas exchange occurs in super-small capillaries which basically wrap around our cells. The process of getting blood to tissues is called perfusion. Theis is all just some technical terminology to say: our lungs take in oxygen and release carbon dioxide, we move the gases around using our circulatory system, and we exchange gases in and out of cells in super-small capillaries. Pure oxygen is a toxin, and CO2 diffused in blood is an acid, so our bodies have all sorts of mechanisms to keep things running. Everything works thanks to diffusion and a few gas laws (Graham’s, Henry’s, and Dalton’s are the main ones). Our lungs have branches and end in leaves called alveoli. Alveoli are pretty wild – they have super-thin walls to allow gases to pass through, and are surrounded by capillaries to transfer gasses into and out of our blood. They look like clumps of bubbles, because they maximize surface area to facilitate the greatest amount of gas exchange in the smallest amount of space. Healthy alveoli are covered in a thin liquid called surfactant, which keeps them lubricated so they can open and close and slide around each other as we breathe. Want to know one reason smokers and vapers have bad lungs? All those extra chemicals muck up surfactant, thicken cell walls, and cause other damage. In smokers a bunch of the alveoli clump together, losing surface area, in a process called atelectasis (remember that word). Our bodies try to keep things in balance, and have a bunch of tools to nudge things in different directions. The important bit for our discussion today is that ventilation is managed through how much we breathe in for a given breath (tidal volume), and how many times a minute we breathe (respiratory rate). This combination is called our minute ventilation and is normally about 6-8 liters per minute. This is linked to our circulation (cardiac output), which is around 5 liters per minute at rest. The amount of oxygen delivered to our cells is a function of our cardiac output and the amount of oxygen in our blood. We need good gas exchange with our environment, good gas exchange into our bloodstream, and good gas exchange into our cells. COVID-19 screws up the gas exchange in our lungs, and everything falls apart from there. Acute Respiratory Distress Syndrome ARDS is basically your body’s immune system gone haywire. It starts with lung damage – which can be an infection, trauma, or even metabolic. One of the big issues with ventilators is that they can actually cause ARDS with the wrong settings. This triggers an inflammatory response. A key aspect of inflammation is various chemical mediators altering cell walls, especially those capillaries – and then they start leaking fluid. In the lungs this causes a nasty cascade: Fluid leaks from the capillaries and forms a barrier/buffer of liquid between the alveoli and the capillaries, and separates them. This reduces gas exchange. Fluid leaks into the alveoli themselves, further inhibiting gas exchange. The cells are damage by all this inflammation, triggering another stronger immune response. Your body is now in a negative reinforcement cycle and making things worse by trying to make them better. This liquid and a bunch of the inflammation chemicals dilute the surfactant and damage the alveolar walls, causing atelectasis. In later stages of ARDS your

This is the third post in our series, “Network Operations and Security Professionals’ Guide to Managing Public Cloud Journeys”, which we will release as a white paper after we complete the draft and have some time for public feedback. You might want to start with our first and second posts. Special thanks to Gigamon for licensing. As always, the content is being developed completely independently using our Totally Transparent Research methodology. Learning cloud adoption patterns doesn’t just help us identify key problems and risks – we can use them to guide operational decisions to address the issues they consistently raise. This research focuses on managing networks and network security, but the patterns include broad security and operational implications which cover all facets of your cloud journey. Governance issues aside, we find that networking is typically one of the first areas of focus for organizations, so it’s a good target for our first focused research. (For the curious, IAM and compliance are two other top areas organizations focus on, and struggle with, early in the process). Recommendations for a Safe and Smooth Journey Developer Led Mark sighed with relief and satisfaction as he validated the VPN certs were propagated and approved the ticket for firewall rule change. The security group was already in good shape and they managed to avoid having to add any kind of direct connect to the AWS account for the formerly-rogue project. He pulled up their new cloud assessment dashboard and all the critical issues were clear. It would still take the IAM team and the project’s developers a few months to scale down unneeded privileges but… not his problem. The federated identity portal was already hooked up and he would get real time alerts on any security group changes. “Now onto the next one,” he mumbled after he glanced at his queue and lost his short-lived satisfaction. “Hey, stop complaining!” remarked Sarah, “We should be clear after this backlog now that accounting is watching the credit cards for cloud charges; just run the assessment and see what we have before you start complaining.” Having your entire organization dragged into the cloud thanks to the efforts of a single team is disconcerting, but not unmanageable. The following steps will help you both wrangle the errant project under control, and build a base for moving forward. This was the first adoption pattern we started to encounter a decade ago as cloud starting growing, so there are plenty of lessons to pull from. Based on our experiences, a few principles really help manage the situation: Remember that to meet this pattern you should be new to either the cloud in general, or to this cloud platform specifically. These are not recommendations for unsanctioned projects covered by your existing experience and footprint. Don’t be antagonistic. Yes, the team probably knew better and shouldn’t have done it… but your goal now is corrective actions, not punitive. You goal is to reduce urgent risks while developing a plan to bring the errant project into the fold. Don’t simply apply your existing policies and tooling from other environments to this one. You need tooling and processes appropriate for this cloud provider. In our experience, despite the initial angst, these projects are excellent opportunities to learn your initial lessons on this platform, and to start building out for a larger supported program. If you keep one eye on immediate risks and the other on long-term benefits, everything should be fine. The following recommendations go a long way towards reducing risks and increasing your chances of success. But before the bullet points we have one overarching recommendation: As you gain control over the unapproved project, use it to learn the particulars of this cloud provider and build out your core cloud management capabilities. When you assess, set yourself up to support your next ten assessments. When you enable monitoring and visibility, do so in a way which supports your next projects. Wherever possible build a core service rather than a one-off. Step one is to figure out what you are dealing with: How many environments are involved? How many accounts, subscriptions, or projects? How are the environments structured? This involves mapping out the application, the PaaS services offered by the provider (they offer PaaS services such as load balancers and serverless capabilities), the IAM, the network(s), and the data storage. How are the services configured? How are the networks structured and connected? The Software Defined Networks (SDN) used by all major cloud platforms only look the same on the surface – under the hood they are quite a bit different. And, most importantly, Where does this project touch other enterprise resources and data?!? This is essential for understanding your exposure. Are there unknown VPN connections? Did someone peer through an existing dedicated network pipe? Is the project talking to an internal database over the Internet? We’ve seen all these and more. Then prioritize your biggest risks: Internet exposures are common and one of the first things to lock down. We commonly see resources such as administrative servers and jump boxes exposed to the Internet at large. In nearly every single assessment we find at least one instance or container with port 22 exposed to the world. The quick fix for these is to lock them down to your known IP address ranges. Cloud providers’ security groups are very effective because they just drop traffic which doesn’t meet the rules, so they are an extremely effective security control and a better first step than trying to push everything through an on-premise firewall or virtual appliance. Identity and Access Management is the next big piece to focus on. This research is focused more on networking, so we won’t spend much time on this here. But when developers build out environments they almost always over-privilege access to themselves and application components. They also tend to use static credentials, because unsanctioned projects are unlikely to integrate into your federated identity management. Sweep out static credentials, enable federation, and turn

This is the second post in our series, “Network Operations and Security Professionals’ Guide to Managing Public Cloud Journeys”, which we will release as a white paper after we complete the draft and have some time for public feedback. You might want to start with our first post. Special thanks to Gigamon for licensing. As always, the content is being developed completely independently using our Totally Transparent Research methodology. Understanding Cloud Adoption Patterns Cloud adoption patterns represent the most common ways organizations move from traditional operations into cloud computing. They contain the hard lessons learned by those who went before. While every journey is distinct, hands-on projects and research have shown us a broad range of consistent experiences, which organizations can use to better manage their own projects. The patterns won’t tell you exactly which architectures and controls to put in place, but they can serve as a great resource to point you in the right general direction and help guide your decisions. Another way to think of cloud adoption patterns is as embodying the aggregate experiences of hundreds of organizations. To go back to our analogy of hiking up a mountain, it never hurts to ask the people who have already finished the trip what to look out for. Characteristics of Cloud Adoption Patterns We will get into more descriptive detail as we walk through each pattern, but we find this grid useful to define the key characteristics. Characteristics Developer Led Data Center Transformation Snap Migration Native New Build Size Medium/Large Large Medium/Large All (project-only for mid-large) Vertical All (minus financial and government) All, including Financial and Government Variable All Speed Fast then slow Slow (2-3 years or more) 18-24 months Fast as DevOps Risk High Low(er) High Variable Security Late Early Trailing Mid to late Network Ops Late Early Early to mid Late (developers manage) Tooling New + old when forced Culturally influenced; old + new Panic (a lot of old) New, unless culturally forced to old Budget Owner Project based/no one IT, Ops, Security IT or poorly defined Project-based, some security for shared services Size: The most common organization sizes. For example developer-led projects are rarely seen in small startups, because they can skip directly to native new builds, but common in large companies. Vertical: We see these patterns across all verticals, but in highly-regulated ones like financial services and government, certain patterns are less common due to tighter internal controls and compliance requirements. Speed: The overall velocity of the project, which often varies during the project lifetime. We’ll jump into theis more, but an example is developer-led, where initial setup and deployment are very fast, but then wrangling in central security and operational control can take years. Risk: This is an aggregate of risk to the organization and of project failure. For example in a snap migration everything tends to move faster than security and operations can keep up, which creates a high chance of configuration error. Security: When security is engaged and starts influencing the project. Network Ops: When network operations becomes engaged and starts influencing the project. While the security folks are used to being late to the party, since developers can build their own networks with a few API calls, this is often a new and unpleasant experience for networking professionals. Tooling: The kind of tooling used to support the project. “New” means new, cloud-native tools. “Old” means the tools you already run in your data centers. Budget Owner: Someone has to pay at some point. This is important because it represents potential impact on your budget, but also indicates who tends to have the most control over a project. Characteristics of Cloud Adoption Patterns In this section we will describe what the patterns look like, and identify some key risks. In our next section we will offer some top-line recommendations to improve your chances of success. One last point before we jump into the patterns themselves: while they focus on the overall experiences of an organization, patterns also apply at the project level, and an organization may experience multiple patterns at the same time. For example it isn’t unusual for a company with a “new to cloud” policy to also migrate existing resources over time as a long-term project. This places them in both the data center transformation and native new build patterns. Developer Led Mark was eating a mediocre lunch at his desk when a new “priority” ticket dropped into his network ops queue. “Huh, we haven’t heard from that team in a while… weird.” He set the microwaved leftovers to the side and clicked open the request… Request for firewall rule change: Allow port 3306 from IP 52.11.33.xxx/32. Mission critical timeline. “What the ?!? That’s not one of our IPs?” Mark thought as he ran a lookup. “amazonaws.com? You have GOT to be kidding me? We shouldn’t have anything up there. Mark fired off emails to his manager and the person who sent the ticket, but he had a bad feeling he was about to get dragged into the kind of mess that would seriously ruin his plans for the next few months. Developer-led projects are when a developer or team builds something in a cloud on their own, and central IT is then forced to support it. We sometimes call this “developer tethering”, because these often unsanctioned and/or uncoordinated projects anchor an organization to a cloud provider, and drag the rest of the organization in after them. These projects aren’t always against policy – this pattern is also common in mergers and acquisitions. This also isn’t necessarily a first step into the cloud overall – it can also be a project which pulls an enterprise into a new cloud provider, rather than their existing preferrred cloud provider. This creates a series of tough issues. To meet the definition of this pattern we assume you can’t just shut the project down, but actually need to support it. The project has been developed and deployed without the input of security or

This is the first post in a new series, our “Network Operations and Security Professionals’ Guide to Managing Public Cloud Journeys”, which we will release as a white paper after we complete the draft and have some time for public feedback. Special thanks to Gigamon for licensing. As always, the content is being developed completely independently using our Totally Transparent Research methodology. Cloud computing is different, disruptive, and transformative. It has no patience for traditional practices or existing architectures. The cloud requires change, and there is a growing body of documentation on end states you should strive for, but a lack of guidance on how to get there. Cloud computing may be a journey, but it’s one with many paths to what is often an all-too-nebulous destination. Although every individual enterprise has different goals, needs, and capabilities for their cloud transition, our experience and research has identified a series of fairly consistent patterns. You can think of moving to cloud as a mountain with a single peak, with everyone starting from the same trailhead. But this simplistic view, which all too often underlies conference presentations and tech articles, fails to capture the unique opportunities and challenges you will face. At the other extreme, we can think of the journey as involving a mountain range with innumerable peaks, starting points, and paths… and a distinct lack of accurate maps. This is the view that tends to end with hands thrown up in the air, expressions of impossibility, and analysis paralysis. But our research and experience guide us between those extremes. Instead of a single constrained path which doesn’t reflect individual needs, or totally individualized paths which require you to build everything and learn every lesson from scratch, we see a smaller set of common options, with consistent characteristics and experiences. Think of it as starting from a few trailheads, landing on a few peaks, and only dealing with a handful of well-marked trails. These won’t cover every option, but can be a surprisingly useful way to help structure your journey, move up the hill more gracefully, and avoid falling off some REALLY sharp cliff edges. Introducing Cloud Adoption Patterns Cloud adoption patterns represent a consolidated set of cloud adoption journeys, compiled through discussions with hundreds of enterprises and dozens of hands-on projects. Less concrete than specific cloud controls, they are a more general way of predicting and understanding the problems facing organizations when moving to cloud, based on starting point and destination. These patterns have different implications across functional teams, and are especially useful for network operations and network security, because they tend to fairly accurately predict many architectural implications, which then map directly to management processes. For example there are huge differences between a brand-new startup or cloud project without any existing resources, a major data center migration, and a smaller migration of key applications. Even a straight-up lift and shift migration is extremely different if it’s a one-off vs. a smaller project vs. wrapped up in a massive data center move with a hard cutoff deadline (often thanks to an hosting contract which is not being renewed). Each case migrates an existing application stack into the cloud, but the different scope and time constraints dramatically affect the actual migration process. We’ll cover them in more detail in our next post, but the four patterns we have identified are: Developer led: A development team starts building something in the cloud outside normal processes, and then pulls the rest of the organization behind them. Data center transformation: An operations-led process defined by an organization planning a methodical migration out of existing data centers and into the cloud, sometimes over a decade or more. Snap migration: An enterprise is forced out of some or all their data centers on a short timeline, due to contract renewals or other business drivers. Native new build: The organization plans to build a new application or several completely in the cloud using native technologies. You likely noticed we didn’t mention some common terms like “refactor” and “new to cloud”. Those are important concepts but we consider them options on the journey, not to define the journey. Our four patterns are about the drivers for your cloud migration and your desired end state. Using Cloud Adoption Patterns The adoption patterns offer a framework for thinking about your upcoming (or in-process) journey, and help identify both strategies for success and potential failure points. These aren’t proscriptive like the Cloud Security Maturity Model or the Cloud Controls Matrix; they won’t tell you exactly which controls to implement, but are more helpful when choosing a path, defining priorities, mapping architectures, and adjusting processes. Going back to our mountain-climbing analogy, the cloud adoption patterns point you down the right path and help you decide which gear to take, but it’s still up to you to load your pack, know how to use the gear, plan your stops, and remember your sunscreen. These patterns represent a set of characteristics we consistently see based on how organizations move to cloud. Any individual organization might experience multiple patterns across different projects. For example a single project might behave more like a startup, even while you concurrently run a larger data center migration. Our next post will detail the patterns with defining characteristics. You can use it to determine your overall organizational journey, as well as to plan out individual projects with their own characteristics. To help you better internalize these patterns, we will offer fictional examples based on real experiences and projects. Once you know which path you are on, our final sections will include top-line recommendations for network operations and security, and tie back to our examples to show how they play out in real life. We will also highlight the most common pitfalls and their potential consequences. This research should help you better understand what approaches will work best for your project in your organization. We are focusing this first round on networking, but future work will build on this basis to

For Rich and me, it seems like forever that we’ve been doing this cloud thing. We previewed the first CCSK class back at RSAC 2011, so we’re closing in on 10 years of hands-on, in the weeds cloud stuff. It’s fundamentally changed Securosis, and we ended up as founders of DisruptOps as well. Yet as the cloud giveth, it also taketh away. Adrian’s unique perspective on application and cloud security made him a great candidate to join Bank of America, so he did. It’s a great opportunity, but we’ll certainly miss having him around during RSAC week. Especially since it means I’ll have to get the aspirin and Tums for you derelicts. But that’s not this year’s DRB theme. We picked (IM)MATURITY because it’s hard to keep in mind that we’re still in the very early stages of the cloud disruption on IT. The questions we get now are less _ “what is this cloud thing?”_ and more ” what does the journey look like?” We didn’t have a decent answer, so we set out to find one. That led us to partner with our friends at IANS to develop a Cloud Security Maturity Model that gives you a sense of the cloud journey and helps you understand how to increase your cloud security capability and maturity. At this year’s DRB, we’ll have the model on hand, as well as an online diagnostic where you can do a self-assessment against the model. We may even have a new strategic relationship to announce at the breakfast. (hush, hush – don’t tell anyone) Let’s celebrate both our maturity in the security space (yes, this is my 24th RSA Conference) while acknowledging the immaturity of securing the cloud by once again holding the most kick-ass breakfast of the year. There are breakfast impostors now, filling up the TableTop Tap House on the other mornings of the conference. But we are the true breakfast innovators of the security industry. There can be only ONE Disaster Recovery Breakfast. check out the full invite Kidding aside, the DRB happens only because of the support of our long-time supporters LaunchTech and DisruptOps, and our media partner Security Boulevard. We’re excited to welcome IANS, Cloud Security Alliance, Highwire PR, and AimPoint Group to the family as well. Please make sure to say hello and thank them for helping support your recovery. As always, the breakfast will be Thursday morning of RSA Week (February 27) from 8-11 at Tabletop Tap House in the Metreon (fka Jillian’s). It’s an open door – come and leave as you want. The breakfast spread will be awesome (it always is), and the bar will be open. I am still drinking Decaf, but I’ve traded in my Bailey’s for a little Amarula after sampling the nectar on my recent trip to South Africa. Please always always always remember what the DR Breakfast is all about. There will be no spin, no magicians, and we’re pretty sure Rich will keep his pants on -– it’s just a place to find a bit of respite amongst the maelstrom of RSAC. To help us estimate numbers, RSVP to rsvp (at) securosis (dot) com. Share:

I never thought I would say this, but I am leaving Securosis. By the time you read this I will have started a new position with Bank of America. I have been asked to help out with application and cloud security efforts. I have been giving a lot of thought to what I like to do, what makes me happy, and what I want to do with the rest of my career, and I came to the realization it is time for a change. There are aspects of the practice of security which I can never explore with Securosis or DisruptOps. The bank offers many challenges – and operates at a scale – which I have never experienced. That, and I will get to work with a highly talented team already in place. I could not really have written a better job description for myself, so I am jumping at this opportunity. 12 years ago I sat down with Rich to discuss, “What comes next?” when the demise of my former company was imminent. When he asked me to consider joining him, I asked, “What exactly is it you do?” I really didn’t know what analysts actually do, nor how the profession works. Mike will tell you I still don’t, and he is probably right. When I joined, friends and associates asked, “What the hell are you doing?” and said, “That is not what you are good at!”, and told me Securosis would never survive – there was no way we could compete against the likes of Gartner, Forrester, and IDC. But Securosis has been an amazing success. After a few years I think we proved that “No Bullshit” research, and our open Totally Transparent Research model, both work. We have been very lucky to have found such a workable niche, and had so much fun filling it. But more than anything I am very thankful for being able to work with Mike and Rich over the last decade. I simply could not ask for better business partners. Both are smart to the point of being prescient, tremendously supportive, and have an intuitive grasp of the security industry. And when we get it wrong – which have have done more than we like to admit – we learn from our mistakes and move on. I recently read a quote from Chuck Akre: “Good judgement comes from experience, and experience comes from bad judgement.” We always wondered how three guys with big egos and aspiration could coexist, but I think our ability to work as a team has been due in large part to learning from each other, learning from our mistakes, and constantly trying to improve the business. And we have constantly pushed this business to improve and move in new directions: from pure research, to training, to the research Nexus, to cloud security, security consulting, investment due diligence, and eventually launching DisruptOps. Each and every change was to address something in the industry we felt was not being served. Even the Disaster Recovery Breakfast stems from that ethos – another way we wanted to do things differently. And we have gained a lot of – ahem – experience along the way. It has been one hell of a ride! Thank you, Rich and Mike. &nbsp A hearty thank you to Chris Pepper for enduring my writing style and lack of grammar all these years. Early on one reader went so far as to compare my writing to Nazi atrocities against the English language, which was uncalled for, but perhaps not so far off the mark. Chris has helped me get a lot better, and for that I am very grateful. Finally, I wanted to thank all the readers of the posts, Friday Summaries, Incites, and research papers we have produced over the years. Some 15,000 blog posts, hundreds of research papers, and more webcasts than I can count. The support of the security community has made this work so rewarding. Thank you all for participating and helping us make Securosis a success. -Adrian Share: