In my opinion, risk assessments focused toward identifying and mitigating cloud based security and privacy risks are different for different companies. Even prior to understanding or performing a risk assessment, one needs to understand the business, the business processes, where the data flows, what data is collected, and how it's processed, stored and transmitted. For me, being a security leader for a healthcare company, through my assessments, I needed to identify risks. At the same time, I needed to mitigate these risks in such a way that I established trust with my business partners, my business leaders, and my patients more often than not. Whenever I spoke to some of my patients, they wanted to know, what we were doing to manage the trust of making sure that their data is safe, secure, and rightfully used.

My experience stems from being at the US Navy followed by joining a Silicon Valley company. And both these places view cybersecurity practices very differently. On the military side, we definitely care a lot about security. I really don't know of any organization that cares more about security than the US military. I feel like in the military, we have to because if we don't, people are going to die. Whereas in Silicon Valley, if you don't, you’d probably lose some money, but then you'd come back with another service to make up the lost money. Another big difference is that working for the government allows you to have unlimited resources. Whereas in Silicon Valley, you really need a business reason for doing security. You are always resource constrained, and you have to prioritize, while mitigating the risks and knowing that the exploitable risks can have a significant impact on the company.

As Lokesh said, you first need to gain a lot of trust with your business leaders and then have a clear cut ROI methodology for prioritizing your security investments. From that perspective, conducting an in-depth assessment of risks around data is critical for paving the way for a defined return on investments. And truly it doesn’t matter whether the data is in cloud or endpoints or servers or containers or bare metal. One deep audit of the meaning of data across all systems can provide me a path to prioritize implementation of technology controls around cybersecurity.

Building on top of what Bob mentioned, we don't treat cloud data risk as a separate animal than our other data risk. Basically, we try to leverage the existing governance policies and processes that we’ve established for our data in general. Being a government entity, we have many data privacy obligations like the California Street and Highway Code, which has some special requirements toward data privacy. We already have the processes which are integrated with our contracting and vendor management process. We leverage the same processes and the same infrastructure which is in place, and we didn't derive any separate thing for cloud data.

It really comes down to a sense of trust, which obviously needs to be backed up by a contract. One of the most common questions that I get is around data residency. To me, that's all part of data governance, it's not just how you manage what data is in there. But do you know what data is allowed to be where? I get questions from a lot of European banks that will say, “All right, we're a SaaS company, and so, if we give you our data, whatever data that might be, how do we know that you know where the data is? How do you know that the data is not going to go across regions and that you have control over?” To me, that's part of data governance, and it's part of the plan that we have built into our security processes because we have to give the assurance to our customers that from a GDPR perspective it's not crossing those borders. And yes, you're right. Even for GDPR there's no certification to prove compliance. It's almost self-attesting. Typically, contracts will mention where the data can live, where it can't live, and you have to allow yourself enough flexibility in the contractual language. For instance, it's very hard to say things like “this data always lives only in Germany”. Because you may need the ability to switch cloud providers or have multiple regions for backup inside of Germany. We have internal policies that go all the way from deployment to database creation to business processes from the perspective where the data resides, and also from the perspective of how we deal with governance & residency requirements.

The problem from my perspective is that it is no longer about where the data is, rather about who has access to it. Data risk assessment to me becomes a privilege access problem. And what's more interesting is that it is not about all data access, but about critical data access.

I bet every one of us has compiled more data in OneDrive and Microsoft Teams this year than anywhere else without even knowing it. Something I've learnt while working at a lot of companies is that if you have very strict policies like “this data type should be put in this storage or shared in that way”, it only works to a point till the end user figures out an easier alternative. People tend to do whatever is more convenient. For example, I worked with an insurance company, where they worked with third party agents that resell their insurance. I discovered that these agents would write out all the clients details in an email and then email it back to us. The company’s security team was building complex backend encryption stuff and I was like, “Yes, but all your sensitive data is coming from your agents and it’s an email that they just cut and pasted and sent it to you. They take pictures of the driver's license and attach them to the email. That's your problem.” From my perspective, given the changing dynamics, the right way to set governance policies is to leverage unsupervised machine learning models to start observing how access occurs, who has access, who doesn’t, where do they access it from, when do they access, how do they access it, etc. Rather than being strict, you start to learn the access models so that you can start to learn the deviations and say, “Oh, I know the CFO works from home right now. He uses Microsoft Office and goes to teams.” If you start to see access models that deviate from that from different places, that's enough for you to care and start to say, “I should look into this.” It is the same way how banks handle credit card fraud - they look for common access patterns and block whenever major deviations from the common pattern occur.

It is a collaboration effort - you have to work with HR, Legal, Engineering. You have to come up with a policy that works within the culture of the organization and that your stakeholders are willing to buy into. You have to come up with a policy that works within the culture of the organization that your stakeholders are going to buy into. If you're buying into it, you’re going to say, “Yes, this is a great policy and will help us out and we are going to abide by it.” One thing we started doing at Directly when I joined is now we have annual training. Every single year, everybody has to review the employment guide, the acceptable use policy, the security policy and privacy training. This way we have it recorded. “Yes, indeed, you know about what you're supposed to do and what you're not supposed to do.” You can’t really punish someone for doing something that they didn't know they weren't supposed to do.

I think at the end of the day, the most important thing is knowing where your data is and controlling where you're going to put the data. Relying on end user awareness on where your data is will never get you to the finish line. If you're not controlling the user behavior, around what apps they can use and cannot use eventually, sooner than later, I think you'll never be done. You will always have something to run after, you will never be not even 30% where you need to be right in terms of achieving your goals.

One of the best ways I've seen enforcement happen is when the problem is delegated to the management of the business unit by tying simple metrics to performance bonuses. This can work if you are doing broad strokes across the business, you can’t be very micro about it. You first have to agree as a business what is the data we really care about. e.g. for the manufacturing business unit, the manufacturing process which lets say is 5% more efficient than the other countries, is important to protect. If they lose that process, they've lost any equilibrium of profit within it.

Knowing exactly what is important and critical to the organization. Being able to know how that data is collected/created, where it is stored, how it is being used, who it is being shared with, and then finally, is it being disposed of if unused.

I think just having a good handle on what data is where. I think that's a problem that's just perennially hard to solve. Just having Google Drive, or AWS, Google Cloud, Box, just having a magic wand that you can wave to know, here's where we store all of our data, here's where all of our file shares are.

I have a very similar point of view. I could just do it in one word - Visibility.

If I had a magic wand, I would really want that super visibility in all my multi-cloud environments. Not only where the data is, what kind of data, who has access to it, and also the operational visibility when people are operating on data. On top of that, being able to know violations that are currently occurring against our policies.

I would say continuous visibility. The way the data moves, the way the data is stored, transmitted, and processed among these cloud workloads, and across different workloads are quite different. As a security leader, I need accurate continuous visibility, not just any visibility.