Research

We reference this content a lot, so I decided to compile it all into a single post. This is the original content, including internal links, and has not been re-edited. Introduction Four years ago I wrote the initial Data Security Lifecycle and a series of posts covering the constituent technologies. In 2009 I updated it to better fit cloud computing, and it was incorporated into the Cloud Security Alliance Guidance, but I have never been happy with that work. It was rushed and didn’t address cloud specifics nearly sufficiently. Adrian and I just spent a bunch of time updating the cycle and it is now a much better representation of the real world. Keep in mind that this is a high-level model to help guide your decisions, but we think this time around we were able to identify places where it can more specifically guide your data security endeavors. (As a side note, you might notice I use “data security” and “information-centric security” interchangeably. I think infocentric is more accurate, but data security is more recognized, so that’s what I tend to use.) If you are familiar with the previous model you will immediately notice that this one is much more complex. We hope it’s also much more useful. The old model really only listed controls for data in different phases of the lifecycle – and didn’t account for location, ownership, access methods, and other factors. This update should better reflect the more complex environments and use cases we tend to see these days. Due to its complexity, we need to break the new Lifecycle into a series of posts. In this first post we will revisit the basic lifecycle, and in the next post we will add locations and access. The lifecycle includes six phases from creation to destruction. Although we show it as a linear progression, once created, data can bounce between phases without restriction, and may not pass through all stages (for example, not all data is eventually destroyed). Create: This is probably better named Create/Update because it applies to creating or changing a data/content element, not just a document or database. Creation is the generation of new digital content, or the alteration/updating of existing content. Store: Storing is the act committing the digital data to some sort of storage repository, and typically occurs nearly simultaneously with creation. Use: Data is viewed, processed, or otherwise used in some sort of activity. Share: Data is exchanged between users, customers, and partners. Archive: Data leaves active use and enters long-term storage. Destroy: Data is permanently destroyed using physical or digital means (e.g., cryptoshredding). These high-level activities describe the major phases of a datum’s life, and in a future post we will cover security controls for each phase. But before we discuss controls we need to incorporate two additional aspects: locations and access devices. Locations and Access In our last post we reviewed the Data Security Lifecycle, but other than some minor wording changes (and a prettier graphic thanks to PowerPoint SmartArt) it was the same as our four-year-old original version. But as we mentioned, quite a bit has changed since then, exemplified by the emergence and adoption of cloud computing and increased mobility. Although the Lifecycle itself still applies to basic, traditional infrastructure, we will focus on these more complex use cases, which better reflect what most of you are dealing with on a day to day basis. Locations One gap in the original Lifecycle was that it failed to adequately address movement of data between repositories, environments, and organizations. A large amount of enterprise data now transitions between a variety of storage locations, applications, and operating environments. Even data created in a locked-down application may find itself backed up someplace else, replicated to alternative standby environments, or exported for processing by other applications. And all of this can happen at any phase of the Lifecycle. We can illustrate this by thinking of the Lifecycle not as a single, linear operation, but as a series of smaller lifecycles running in different operating environments. At nearly any phase data can move into, out of, and between these environments – the key for data security is identifying these movements and applying the right controls at the right security boundaries. As with cloud deployment models, these locations may be internal, external, public, private, hybrid, and so on. Some may be cloud providers, other traditional outsourcers, or perhaps multiple locations within a single data center. For data security, at this point there are four things to understand: Where are the potential locations for my data? What are the lifecycles and controls in each of those locations? Where in each lifecycle can data move between locations? How does data move between locations (via what channel)? Access Now that we know where our data lives and how it moves, we need to know who is accessing it and how. There are two factors here: Who accesses the data? How can they access it (device & channel)? Data today is accessed from all sorts of different devices. The days of employees only accessing data through restrictive applications on locked-down desktops are quickly coming to an end (with a few exceptions). These devices have different security characteristics and may use different applications, especially with applications we’ve moved to SaaS providers – who often build custom applications for mobile devices, which offer different functionality than PCs. Later in the model we will deal with who, but the diagram below shows how complex this can be – with a variety of data locations (and application environments), each with its own data lifecycle, all accessed by a variety of devices in different locations. Some data lives entirely within a single location, while other data moves in and out of various locations… and sometimes directly between external providers. This completes our “topographic map” of the Lifecycle. In our next post we will dig into mapping data flow and controls. In the next few posts we will finish covering background material, and

One of the most common modern problems facing organizations is managing data migrating to the cloud. The very self-service nature that makes cloud computing so appealing also makes unapproved data transfers and leakage possible. Any employee with a credit card can subscribe to a cloud service and launch instances, deliver or consume applications, and store data on the public Internet. Many organizations report that individuals or business units have moved (often sensitive) data to cloud services without approval from, or even notification to, IT or security. Aside from traditional data security controls such as access controls and encryption, there are two other steps to help manage unapproved data moving to cloud services: Monitor for large internal data migrations with Database Activity Monitoring (DAM) and File Activity Monitoring (FAM). Monitor for data moving to the cloud with URL filters and Data Loss Prevention. Internal Data Migrations Before data can move to the cloud it needs to be pulled from its existing repository. Database Activity Monitoring can detect when an administrator or other user pulls a large data set or replicates a database. File Activity Monitoring provides similar protection for file repositories such as file shares. These tools can provide early warning of large data movements. Even if the data never leaves your internal environment, this is the kind of activity that shouldn’t occur without approval. These tools can also be deployed within the cloud (public and/or private, depending on architecture), and so can also help with inter-cloud migrations. Movement to the Cloud While DAM and FAM indicate internal movement of data, a combination of URL filtering (web content security gateways) and Data Loss Prevention (DLP) can detect data moving from the enterprise into the cloud. URL filtering allows you to monitor (and prevent) users connecting to cloud services. The administrative interfaces for these services typically use different addresses than the consumer side, so you can distinguish between someone accessing an admin console to spin up a new cloud-based application and a user accessing an application already hosted with the provider. Look for a tool that offers a list of cloud services and keeps it up to date, as opposed to one where you need to create a custom category and manage the destination addresses yourself. Also look for a tool that distinguishes between different users and groups so you can allow access for different employee populations. For more granularity, use Data Loss Prevention. DLP tools look at the actual data/content being transmitted, not just the destination. They can generate alerts (or block) based on the classification of the data. For example, you might allow corporate private data to go to an approved cloud service, but block the same content from migrating to an unapproved service. Similar to URL filtering, you should look for a tool that is aware of the destination address and comes with pre-built categories. Since all DLP tools are aware of users and groups, that should come by default. This combination isn’t perfect, and there are plenty of scenarios where they might miss activity, but that is a whole lot better than completely ignoring the problem. Unless someone is deliberately trying to circumvent security, these steps should capture most unapproved data migrations. Share:

Last Thursday I thought I was dying. Not a joke. Not an exaggeration. As in “approaching room temperature”. I was just outside D.C. having breakfast with Mike before going to teach the CCSK instructors class. In the middle of a sentence I felt… something. Starting from my chest I felt a rush to my head. An incredibly intense feeling on the edge of losing consciousness. Literally out of nowhere, while sitting. I paused, told Mike I felt dizzy, and then the second wave hit. I said, “I think I’m going down”, told him to call 9-1-1, and had what we in the medical profession call “a feeling of impending doom”. I thought I was having either an AMI (acute myocardial infarction (heart attack), not the cloud thing) or a stroke. I’ve been through a lot over the years and nothing, nothing, has ever hit me like that. The next thoughts in my head were what I know my last thoughts on this planet will be. I never want to experience them again. Seconds after this hit I checked my pulse, since that feeling was like what many patients with an uncontrolled, rapid heart rate described. But mine was only up slightly. It tapered off enough that I didn’t think I was going to crash right then and there. Fortunately Mike is a bit… inexperienced… and instead of calling 9-1-1 with his cell phone he got up to tell the restaurant. I stopped him, it relented more, and I asked if there was a hospital close (Mike lived in that area for 15 years). There was one down the road and he took me there. (Never do that. Call the ambulance – we medical folks are freaking idiots.) I spent the next 29 hours in the hospital being tested and monitored. Other than a slightly elevated heart rate, everything was normal. CT scan of the head, EKG, blood work to rule out a pulmonary embolus (common traveling thing), echocardiogram, chest x-ray, and more. I ate what I was told was a grilled cheese sandwich. Assuming that was true, I’m certain it was microwaved and the toast marks airbrushed. Once they knew I wasn’t going to die they let me loose and I flew home (a day late). I won’t lie – I was pretty shaken up. Worse than when I fell 30 feet rock climbing and punctured my lung. Worse than skiing through avalanche terrain, or the time my doctor called to ask “are you close to the hospital” after a wicked infection. Especially with my rescue and extreme sports background I’ve been in a lot of life-risking situations, but I never before thought “this is it”. Tuesday I went to the doctor, and after a detailed history and reviewing the reports she thinks it was an esophageal spasm. The nerves in your thorax aren’t always very discriminating. They are like old Ethernet cables prone to interference and cross talk. A spasm in the wrong spot will trigger something that is essentially indistinguishable from a heart attack (to your brain). I’ve been having some reflux lately from all the road food, so it makes sense. There are more tests on the way, but it seems you all are stuck with me for much, much longer. All that testing was like the best physical ever, and I’m in killer good shape. but I am going to chill a bit for the next few weeks, which was in the works anyway. False positives suck. Now I know why you all hate IDS. Update: I was talking with our pediatrician and he went through the same thing once. He asked “can I ask you a personal question?” “Sure” I replied. “So what was running through your head when it happened?” I said, “I can’t believe I won’t be there for my girls”. “Oh good” he went, “I’ve never talked to anyone else who went through it, but I was trying to figure out if I had enough life insurance for my family”. And a coworker of my wife’s mentioned she had the same thing, and called her kids to say goodbye. To be honest, now I don’t feel so bad. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on dangers to law enforcement from recent hack. My Spanish is good, no? Adrian’s DR article on Fraud Detection and DAM. Rich, Zach, and Martin on the Network Security Podcast. Favorite Securosis Posts Adrian Lane: Cloud Security Q&A from the Field. Mike Rothman: Spotting That DAM(n) Fake. Grumpy Adrian is a wonder to behold. And he is definitely grumpy in this post. David Mortman: Spotting That DAM(n) Fake. Rich: Beware Anti-Malware Snake Oil Other Securosis Posts Security Management 2.0: Revisiting Requirements. Fact-based Network Security: Outcomes and Operational Data. Incite 8/24/2011: Living Binary. Security Management 2.0: Platform Evolution. Favorite Outside Posts Adrian Lane: Visa Kills PCI Assessments and Wants Your Processor to Support EMV. This is the carrot I mentioned, which Visa is offering to encourage adoption. As Branden points out, most merchants take more than Visa, but I expect MC to follow suit. Mike Rothman: National Archives Secret Question Fail. H/T to the guys at 37Signals for pointing out this security FAIL. David Mortman: Soft switching might not scale, but we need it. Rich: Wim Remes petitioning to get on the ISC2 ballot. Although I burned someone’s certificate on stage at DefCon, the organization could do some good if they changed direction. (No, I don’t have a CISSP… as a DefCon goon I’m not sure how to answer that whole “Do you associate with hackers?” question.) Research Reports and Presentations Tokenization vs. Encryption: Options for Compliance. Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Top News and Posts Chinese Military

One of the great things about running around teaching classes is all the feedback and questions we get from people actively working on all sorts of different initiatives. With the CCSK (cloud security) class, we find that a ton of people are grappling with these issues in active projects and different things in various stages of deep planning. We don’t want to lose this info, so we will to blog some of the more interesting questions and answers we get in the field. I’ll skip general impressions and trends today to focus on some specific questions people in last week’s class in Washington, DC, were grappling with: We currently use XXX Database Activity Monitoring appliance, is there any way to keep using it in Amazon EC2? This is a tough one because it depends completely on your vendor. With the exception of Oracle (last time I checked – this might have changed), all the major Database Activity Monitoring vendors support server agents as well as inline or passive appliances. Adrian covered most of the major issues between the two in his Database Activity Monitoring: Software vs. Appliance paper. The main question for cloud )especially public cloud) deployments is whether the agent will work in a virtual machine/instance. Most agents use special kernel hooks that need to be validated as compatible with your provider’s virtual machine hypervisor. In other words: yes, you can do it, but I can’t promise it will work with your current DAM product and cloud provider. If your cloud service supports multiple network interfaces per instance, you can also consider deploying a virtual DAM appliance to monitor traffic that way, but I’d be careful with this approach and don’t generally recommend it. Finally, there are more options for internal/private cloud where you can route the traffic even back to a dedicated appliance if necessary – but watch performance if you do. How can we monitor users connecting to cloud services over SSL? This is an easy problem to solve – you just need a web gateway with SSL decoding capabilities. In practice, this means the gateway essentially performs a man in the middle attack against your users. To work, you install the gateway appliance’s certificate as a trusted root on all your endpoints. This doesn’t work for remote users who aren’t going through your gateway. This is a fairly standard approach for both web content security and Data Loss Prevention, but those of you just using URL filtering may not be familiar with it. Can I use identity management to keep users out of my cloud services if they aren’t on the corporate network? Absolutely. If you use federated identity (probably SAML), you can configure things so users can only log into the cloud service if they are logged into your network. For example, you can configure Active Directory to use SAML extensions, then require SAML-based authentication for your cloud service. The SAML token/assertion will only be made when the user logs into the local network, so they can’t ever log in from another location. You can screw up this configuration by allowing persistent assertions (I’m sure Gunnar will correct my probably-wrong IAM vernacular). This approach will also work for VPN access (don’t forget to disable split tunnels if you want to monitor activity). What’s the CSA STAR project? STAR (Security, Trust & Assurance Registry) is a Cloud Security Alliance program where cloud providers perform and submit self assessments of their security practices. How can we encrypt big data sets without changing our applications? This isn’t a cloud-specific problem, but does come up a lot in the encryption section. First, I suggest you check out our paper on encryption: Understanding and Selecting a Database Encryption or Tokenization Solution. The best cloud option is usually volume encryption for IaaS. You may also be able to use some other form of transparent encryption, depending on the various specifics of your database and application. Some proxy-based in-the-cloud encryption solutions are starting to appear. That’s it from this class… we had a ton of other questions, but these stood out. As we teach more we’ll keep posting more, and I should get input from other instructors as they start teaching their own classes. Share:

Recently I had a conversation with a security vendor offering a proxy-based solution for a particular problem (yes, I’m being deliberately obscure). Their technology is interesting, but fundamental changes in how we consume IT resources challenge the very idea that a proxy can effectively address this problem. The two most disruptive trends in information technology today are mobility and the cloud. With mobility we gain (and demand) anywhere access as the norm, redistributing access across varied devices. At the same time, cloud computing redefines both the data center and the architectures within data centers. Even a private internal cloud dramatically changes the delivery of IT resources. So both delivery and consumption models change simultaneously and dramatically – both distributing and consolidating resources. What does this have to do with proxies? Generally they have been a great solution to a tough problem. It’s a royal pain to distribute security controls across all endpoints, for both performance and management reasons. For example, there is no DLP or URL filtering solution on the market that can fully enforce the same sorts of rules on an endpoint as on a server. Fortunately for us, our traditional IT architectures naturally created chokepoints. Even mobile users needed them to pipe back into the core for normal business/access reasons – quite aside from security. But we’ve all seen this eroding over time. That erosion now reminds me of those massive calving glaciers that sunk the Titanic – not the slow-movers that created all those lovely fjords. From the networking issues inherent to private cloud, to users accessing SaaS resources directly without going through an enterprise gateway, the proxy model is facing challenges. In some cloud deployments you can’t use them at all. There are a many things I still like proxies for, but here are some rough rules I use in figuring out when they make sense. If you have a bunch of access devices in a bunch of locations, you either need to switch to an agent or reroute everything to the proxy (not always easy to do). Proxies don’t need to be in your core network – they can be in the cloud (like our VPN server, which we use for browsing on public WiFi). This means putting more trust in your cloud provider, depending on what you are doing. Proxies in private cloud and virtualization (e.g., encryption or network traffic analysis) need to account for (potentially) mobile virtual machines within the environment. This requires carefully architecting both physical and virtual networks, and considering how to define provisioning rules for the cloud. With a private cloud, unless you move to agents, you’ll need to build inline virtual proxies, bounce traffic out of the cloud, or find a hypervisor-level proxy (not many today – more coming). Performance varies. But the reality is that the more we adopt cloud, the fewer fixed checkpoints we’ll have, and the more we will have to evolve our definition of ‘proxy’ away from its currently meaning. Share:

Believe it or not, I’m not the biggest fan of travel. Oh, I used to be, maybe 10+ years ago when I was just starting to travel as part of my career. Being in your 20’s and getting paid to literally circle the globe isn’t all bad… especially when you’re single. But the truth is I got tired of travel long before I started a family. Traveling every now and then is a wonderful experience that can change the lens with which you view the world. Hitting the airport once or twice a month, on the other hand, does little more than disrupt your life (and I know plenty of people who travel even more than that). I miss being on a routine, and I really miss the strong local social bonds I used to have. Travel killed my chances of moving up to my next Black Belt. It wrecked my fitness consistency (yes, I still work out a ton, but not so much with other people, and bad hotel gyms and strange roads aren’t great for the program). It killed my participation in mountain rescue, although for a couple years it did let me ski patrol in Colorado while I lived in Phoenix. That didn’t suck. It mostly hurt my relationships with my “old” friends because I just wasn’t around much. Folks I basically grew up with, as we all congregated in Boulder (mostly) as we started college, and learned to rely on each other as surrogate family. Complete with Crazy Uncle Wade at the head of the Thanksgiving table (Wade is now in the Marshall Islands, after working as an electrician in Antarctica). On the other hand, I now have a social group that’s scattered across the country and the world. I see some of these people more than my local friends here in Phoenix, and we’re often on expense accounts without a curfew. I was sick last week at Black Hat and DefCon, but managed to spend a little quality time with folks like Chris Hoff, Alex Hutton, Martin and Zach from the Podcast, two good friends from Gartner days, Jeremiah, Ryan, Mike A., and the rest of the BJJ crew, and even some of these people’s spouses. Plus so many more that going to DefCon (in particular) now feels more like a week of summer camp than a work conference. With beer. And parties in the biggest clubs in Vegas (open bar). And… well, we’re not 13 anymore. What’s amazing and awesome is almost none of us work together, and most of us don’t live anywhere near each other. And it isn’t unusual to roll into some random city (for a client gig, not even a conference), and find out someone else is also in town. We live strange lives as digital nomads who combine social media and frequent flyer miles to create a personal network that’s different from seeing the same faces every weekend at the Rio (Boulder thing), but likely as strong. I don’t think this could exist without both the technical and physical components. I still miss the consistency of life with a low-travel job. But in exchange I have the kinds of adventures other people write books about, and get to share them with a group of people I consider close friends, even if I can’t invite them over for a BBQ without enough time to get through their personal gropings at the airport. -Rich On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on tokenization. Favorite Securosis Posts Mike Rothman: NoSQL and No Security. Nothing like poking a big security hole in an over-hyped market. Who needs DB security anyway? Adrian Lane: Data Security Lifecycle 2.0: Functions, Actors, and Controls. Why? Because the standard data security lifecycle fails when applied to cloud services – you need to take location and access into account. Our goal is to make the model simple to use, so please give us your feedback. David Mortman: Use THEIR data to tell YOUR story. Rich: Words matter: You stop attacks, not breaches. I know, I know, we should stop thinking marketing will ever change. But everyone has their windmill. Other Securosis Posts Say Hello to Chip and Pin. Incite 8/10/2011: Back to the Future. Introducing the Data Security Lifecycle 2.0. Data Security Lifecycle 2.0 and the Cloud: Locations and Access. Fact-Based Network Security: Defining ‘Risk’. Incite 8/3/2011: The Kids Are Our Future. Words matter: You stop attacks, not breaches. Cloud Security Training: August 16-18, Washington DC. Security has always been a BigData problem. New Blog Series: Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Favorite Outside Posts Mike Rothman: Marcus Ranum: Dangerous Cyberwar Rhetoric. Ranum can pontificate with the best of them, but this perspective is dead on. Attribution is harder, and even more important, as the lines between “cyber” and physical war inevitably blur. Adrian Lane: Comments about the $200,000 BlueHat prize. ErrataRob clarifies the security bounty program. David Mortman: Metricon 6 Wrap-Up. Chris Pepper: Badass of the Week: Abram A. Heller. Totally badass without being an ass. Rich: Sunset of a Blog. Glenn is a good friend and one of the people who helped launch my writing career, especially on the Mac side (via TidBITS). This post shows the difference between a blogger and a writer. Research Reports and Presentations Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Top News and Posts Microsoft Security Program & Vulnerability Data Now Available. Did Airport Scanners Give Boston TSA Agents Cancer? TSA says that’s BS. Survey Finds Smartphone Apps Store Too Much Personal Data. What? No way! 22 Reasons to Patch Your Windows PC via Krebs. Cameron Threatens To Shut Down UK Social Networks.

In our last post we added location and access attributes to the Data Security Lifecycle. Now let’s start digging into the data flow and controls. To review, so far we’ve completed our topographic map for data: This illustrates, at a high level, how data moves in and out of different environments, and to and from different devices. It doesn’t yet tell us which controls to use or where to place them. That’s where the next layer comes in, as we specify locations, actors (‘who’), and functions: Functions There are three things we can do with a given datum: Access: View/access the data, including copying, file transfers, and other exchanges of information. Process: Perform a transaction on the data: update it, use it in a business processing transaction, etc. Store: Store the data (in a file, database, etc.). The table below shows which functions map to which phases of the lifecycle: Each of these functions is performed in a location, by an actor (person). Controls Essentially, a control is what we use to restrict a list of possible actions down to allowed actions. For example, encryption can be used to restrict access to data, application controls to restrict processing via authorization, and DRM storage to prevent unauthorized copies/accesses. To determine the necessary controls; we first list out all possible functions, locations, and actors; and then which ones to allow. We then determine what controls we need to make that happen (technical or process). Controls can be either preventative or detective (monitoring), but keep in mind that monitoring controls that don’t tie back into some sort of alerting or analysis merely provide an audit log, not a functional control. This might be a little clearer for some of you as a table: Here you would list a function, the actor, and the location, and then check whether it is allowed or not. Any time you have a ‘no’ in the allowed box, you would implement and document a control. Tying It together In essence what we’ve produced is a high-level version of a data flow diagram (albeit not using standard programming taxonomy). We start by mapping the possible data flows, including devices and different physical and virtual locations, and at which phases in its lifecycle data can move between those locations. Then, for each phase of the lifecycle in a location, we determine which functions, people/systems, and more-granular locations for working with the data are possible. We then figure out which we want to restrict, and what controls we need to enforce those restrictions. This looks complex, but keep in mind that you aren’t likely to do it for all data within an entire organization. For given data in a given application/implementation you’ll be working with a much more restrictive subset of possibilities. This clearly becomes more involved with bigger applications, but practically speaking you need to know where data flows, what’s possible, and what should be allowed, to design your security. In a future post we’ll show you an example, and down the road we also plan to produce a controls matrix which will show you where the different data security controls fit in. Share:

Four years ago I wrote the initial Data Security Lifecycle and a series of posts covering the constituent technologies. In 2009 I updated it to better fit cloud computing, and it was incorporated into the Cloud Security Alliance Guidance, but I have never been happy with that work. It was rushed and didn’t address cloud specifics nearly sufficiently. Adrian and I just spent a bunch of time updating the cycle and it is now a much better representation of the real world. Keep in mind that this is a high-level model to help guide your decisions, but we think this time around we were able to identify places where it can more specifically guide your data security endeavors. (As a side note, you might notice I use “data security” and “information-centric security” interchangeably. I think infocentric is more accurate, but data security is more recognized, so that’s what I tend to use.) If you are familiar with the previous model you will immediately notice that this one is much more complex. We hope it’s also much more useful. The old model really only listed controls for data in different phases of the lifecycle – and didn’t account for location, ownership, access methods, and other factors. This update should better reflect the more complex environments and use cases we tend to see these days. Due to its complexity, we need to break the new Lifecycle into a series of posts. In this first post we will revisit the basic lifecycle, and in the next post we will add locations and access. The lifecycle includes six phases from creation to destruction. Although we show it as a linear progression, once created, data can bounce between phases without restriction, and may not pass through all stages (for example, not all data is eventually destroyed). Create: This is probably better named Create/Update because it applies to creating or changing a data/content element, not just a document or database. Creation is the generation of new digital content, or the alteration/updating of existing content. Store: Storing is the act committing the digital data to some sort of storage repository, and typically occurs nearly simultaneously with creation. Use: Data is viewed, processed, or otherwise used in some sort of activity. Share: Data is exchanged between users, customers, and partners. Archive: Data leaves active use and enters long-term storage. Destroy: Data is permanently destroyed using physical or digital means (e.g., cryptoshredding). These high-level activities describe the major phases of a datum’s life, and in a future post we will cover security controls for each phase. But before we discuss controls we need to incorporate two additional aspects: locations and access devices. Share:

In our last post we reviewed the Data Security Lifecycle, but other than some minor wording changes (and a prettier graphic thanks to PowerPoint SmartArt) it was the same as our four-year-old original version. But as we mentioned, quite a bit has changed since then, exemplified by the emergence and adoption of cloud computing and increased mobility. Although the Lifecycle itself still applies to basic, traditional infrastructure, we will focus on these more complex use cases, which better reflect what most of you are dealing with on a day to day basis. Locations One gap in the original Lifecycle was that it failed to adequately address movement of data between repositories, environments, and organizations. A large amount of enterprise data now transitions between a variety of storage locations, applications, and operating environments. Even data created in a locked-down application may find itself backed up someplace else, replicated to alternative standby environments, or exported for processing by other applications. And all of this can happen at any phase of the Lifecycle. We can illustrate this by thinking of the Lifecycle not as a single, linear operation, but as a series of smaller lifecycles running in different operating environments. At nearly any phase data can move into, out of, and between these environments – the key for data security is identifying these movements and applying the right controls at the right security boundaries. As with cloud deployment models, these locations may be internal, external, public, private, hybrid, and so on. Some may be cloud providers, other traditional outsourcers, or perhaps multiple locations within a single data center. For data security, at this point there are four things to understand: Where are the potential locations for my data? What are the lifecycles and controls in each of those locations? Where in each lifecycle can data move between locations? How does data move between locations (via what channel)? Access Now that we know where our data lives and how it moves, we need to know who is accessing it and how. There are two factors here: Who accesses the data? How can they access it (device & channel)? Data today is accessed from all sorts of different devices. The days of employees only accessing data through restrictive applications on locked-down desktops are quickly coming to an end (with a few exceptions). These devices have different security characteristics and may use different applications, especially with applications we’ve moved to SaaS providers – who often build custom applications for mobile devices, which offer different functionality than PCs. Later in the model we will deal with who, but the diagram below shows how complex this can be – with a variety of data locations (and application environments), each with its own data lifecycle, all accessed by a variety of devices in different locations. Some data lives entirely within a single location, while other data moves in and out of various locations… and sometimes directly between external providers. This completes our “topographic map” of the Lifecycle. In our next post we will dig into mapping data flow and controls. In the next few posts we will finish covering background material, and then show you how to use this to pragmatically evaluate and design security controls. Share:

Hey everyone, Just a quick announcement that we are holding another CCSK training class in a few weeks. This one is in the DC area (Falls Church) and includes the Basic, Plus, and Train the Trainer options. The Basic class is a day of lecture covering the CSA Guidance and cloud security basics. The second day is all hands-on, and you’ll launch instances, build an application stack, encrypt stuff, and get really confused by federated identity. Hope to see you there, and you can register. Share: