Ah, a very astute point. This is a very costly but sometimes popular methods :-(
Originally published at Medium.
Monday, April 26, 2021
Ah, a very astute point. This is a very costly but sometimes popular methods :-(
Ah, a very astute point. This is a very costly but sometimes popular methods :-(
Originally published at Medium.
Friday, April 16, 2021
Well, fixed per employee cost per year, and the cost per employee is low-ish
Well, fixed per employee cost per year, and the cost per employee is low-ish
Originally published at Medium.
Well, fixed per employee cost per year, and the cost per employee is low-ish
Well, fixed per employee cost per year, and the cost per employee is low-ish
Originally published at Medium.
Monday, April 12, 2021
For sure, this is definitely true for Chronicle, and it also may be true for others.
For sure, this is definitely true for Chronicle, and it also may be true for others. However, if they backend to cloud and pay retail prices for cloud, there is only so much one can do to reduce the price….
Originally published at Medium.
Wednesday, March 03, 2021
Tuesday, March 02, 2021
Is Your Fate In the Cloud?
This is a quick “let’s think about it together” post focused on the future of cloud security.
This is a quick “let’s think about it together” post focused on the future of cloud security.
Our logical starting point is: “Through 2025, 99% of cloud security failures will be the customer’s fault.” (source: Gartner) My experience in my analyst days and perhaps today mostly confirms it. I’d say that “it feels right.” So, let’s agree that it describes today’s reality correctly.
Next point: now that we agree that this model describes reality in a useful manner, may I suggest that it indicates a problem. In other words, this means something needs to be changed or fixed. Why? Because who is better resourced (in terms of money, knowledge, people) to deal with tricky cloud security challenges, those who built it or those who use it?
Next naive point: if it feels like “99% is too high”, then there is an easy (and very wrong) solution: use a security-incompetent cloud provider who would then make more mistakes and can be blamed for them. Thus, customers will be less at fault, but will perhaps lose more. So, let’s not go there.
Next, still naive, point: if you do the opposite, and choose a more security-focused cloud provider, we may end up “99.99% of cloud security failures are customer’s fault” which is not what we want as per item above.
Now, can you solve this puzzle? How to keep the customers secure without cloud security failures mostly being their fault?
Well? Got ideas?!
This seems impossible to fix in the above context, but as with many puzzles and mysteries, the solution is lateral, not direct.
To arrive at it, let’s now ask “what is the context for this conundrum?” The shared responsibility model, of course. I will say that to crack this nut, we need to transcend the shared responsibility model somehow. Note my word choice: transcend, not discard.
And, drumroll, I think that we figured out how to do just that!
For this, I must explain the concept of “SHARED FATE” first introduced in this post about operations (2016). Share fate happens when “they [a cloud provider and a client] work together as a team for a common goal and share a fate greater than the dollars that pass between them.”
Security shared fate may be about preparing a secure landing zone for a client, guiding them while there, being clear and transparent about the security controls, perhaps sometimes offering guardrails for what they can do and then if something still happens, helping them out via insurance!
This will transcend the shared responsibility and get us some of the way to SHARED FATE, where “whose fault is it” may not have the same meaning … or any meaning. Thus, we will have a more secure, more trusted cloud for everybody.
Read the details here.
Related blog posts:
Originally published at Medium.
Is Your Fate In the Cloud?
This is a quick “let’s think about it together” post focused on the future of cloud security.
This is a quick “let’s think about it together” post focused on the future of cloud security.
Our logical starting point is: “Through 2025, 99% of cloud security failures will be the customer’s fault.” (source: Gartner) My experience in my analyst days and perhaps today mostly confirms it. I’d say that “it feels right.” So, let’s agree that it describes today’s reality correctly.
Next point: now that we agree that this model describes reality in a useful manner, may I suggest that it indicates a problem. In other words, this means something needs to be changed or fixed. Why? Because who is better resourced (in terms of money, knowledge, people) to deal with tricky cloud security challenges, those who built it or those who use it?
Next naive point: if it feels like “99% is too high”, then there is an easy (and very wrong) solution: use a security-incompetent cloud provider who would then make more mistakes and can be blamed for them. Thus, customers will be less at fault, but will perhaps lose more. So, let’s not go there.
Next, still naive, point: if you do the opposite, and choose a more security-focused cloud provider, we may end up “99.99% of cloud security failures are customer’s fault” which is not what we want as per item above.
Now, can you solve this puzzle? How to keep the customers secure without cloud security failures mostly being their fault?
Well? Got ideas?!
This seems impossible to fix in the above context, but as with many puzzles and mysteries, the solution is lateral, not direct.
To arrive at it, let’s now ask “what is the context for this conundrum?” The shared responsibility model, of course. I will say that to crack this nut, we need to transcend the shared responsibility model somehow. Note my word choice: transcend, not discard.
And, drumroll, I think that we figured out how to do just that!
For this, I must explain the concept of “SHARED FATE” first introduced in this post about operations (2016). Share fate happens when “they [a cloud provider and a client] work together as a team for a common goal and share a fate greater than the dollars that pass between them.”
Security shared fate may be about preparing a secure landing zone for a client, guiding them while there, being clear and transparent about the security controls, perhaps sometimes offering guardrails for what they can do and then if something still happens, helping them out via insurance!
This will transcend the shared responsibility and get us some of the way to SHARED FATE, where “whose fault is it” may not have the same meaning … or any meaning. Thus, we will have a more secure, more trusted cloud for everybody.
Read the details here.
Related blog posts:
Originally published at Medium.
Monday, March 01, 2021
Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…
This is about the Security Operations Center (SOC). And automation. And of course SOC automation.
This is about the Security Operations Center (SOC). And automation. And of course SOC automation.
Let’s start from a dead-obvious point: you cannot and should not automate away all people from your SOC today. Or, as my esteemed colleague said, “Stop Trying To Take Humans Out Of Security Operations.”
Despite this point being dead-obvious today, I want to present a few arguments to further support it — it will be clear why in the end…
We need humans because the attackers are humans with their own creativity, irrationality, weirdness, etc. As one vendor once said, “you have an adversary problem, not a malware problem.” We need to hunt and not rely solely on automated systems for things like detection — hence humans are a must. This side of the argument boils down to “we need humans because the attackers are [also human].” This argument is also enhanced by arguments “why robots suck for security” and all that.
So good automation is a “force multiplier,” not a force replacer. Admittedly, some tasks — like data enrichment — are better done by machines, and humans can — and should — be rid of them. The point is to remove some tasks from humans and not to remove the humans from the SOC [entirely].
Furthermore, bad automation kills. This is due to a perennial problem that also plagues the use of ML/AI in security: garbage in — garbage out. This problem is further boosted with the fact that today’s automation logic (whether for detection or remediation) is just not smart enough for the complex world of IT around it. So, neither the data quality, nor the algorithms measure up. This is all true, while “cybersecurity is the most intellectually demanding profession on the planet.”
So. Convinced? Sure. But let’s continue on our journey…
All the while, there are more and more voices for more automation. Their logic is also very understandable. We need automation, because we need to scale better and go faster, we have too much data, alerts, signals, threats, etc. There is much to be said about the value of various forms of automation in security (in general) and in security operations (in particular).
However, as I said above, to keep the discussion sane we always remind ourselves that trying to take the humans out of SOC is more or less insane.
Still with me? OK, but now you’d be somewhat surprised where our journey will suddenly turn…
Now, go and imagine the following scenarios:
- You face the attacker in possession of a machine that can auto-generate reliable zero day exploits and then use them (an upgraded version of what was the subject of 2016 DARPA Grand Challenge)
- You face the attackers who use worms for everything, and these are not the dumb 2003 worms, but these are coded by the best of the best of the offensive “community”
- Your threat assessment indicates that “your” attackers are adopting automation faster than you are and the delta is increasing (and the speed of increase is growing).
Would you still say the same? Would you still give the same advice? All these are very hypothetical in 2021, to be sure, but what about 2025? 2030? 2035?
Frankly, you can cheat and say “the middle way is the way: humans need to work with machines.” And things would feel nice for a moment, until you realize this is what chess players said sometime after their first rout in 1997. There was a concept of human+machine chess that looked really awesome in 1998–2015, but then was quickly and mercilessly killed by the improving neural networks. Naturally, one may counter that chess is mathematically solvable while information security is not (by a wide, wide, wide margin). Sure, this argument holds water …today.
Conclusion
Today, I will still also say “Stop Trying To Take Humans Out Of Security Operations” but somewhere in the very back of my mind, a scary and cold uncoiling worm of doubt is born …
Thanks to Brandon Levene for a great discussion and some text contributed to this post.
Thanks to Dave Aitel for the disruptive ideas that triggered me to write this.
Originally published at Medium.
Friday, February 26, 2021
From Google Cloud Blog: “New Cloud Security Podcast by Google is here”
Those who follow me on social media already knows this, but we have launched THE Cloud Security Podcast.
Those who follow me on social media already knows this, but we have launched THE Cloud Security Podcast.
TL;DR:
Find this on Google Podcasts, Apple Podcasts, Spotify, Stitcher and wherever else podcasts can be found. You can also download the episodes directly here. Follow @CloudSecPodcast.
The whole story from our GCP blog is cross-posted below:
Security continues to be top of mind for large enterprises as well as smaller organizations and businesses. Furthermore, cloud security continues to puzzle many security leaders and technologists. That is why we are excited to announce the launch of the Cloud Security Podcast by Google.
This podcast will bring you stories and insights on security in the cloud, delivering security from the cloud, and, of course, on what we’re doing at Google Cloud to help keep customer data safe and workloads secure. We’ll do our best to avoid security theater (but perhaps have some reverse security theater), and cut to the heart of real security questions and issues. We’ll question threat models and determine whether security tactics are deployed for the data subject’s benefit or just for organizational benefit.
We hope you’ll join us if you’re interested in the ways technology overlaps with process and bumps up against organizational design. We’re hoping to attract listeners who want to hear conventional wisdom questioned, who are curious about what lessons we can and can’t keep, as the world moves from on-premises computing to cloud computing.
Launching a podcast is a commitment to listeners and our guests. We’re starting out with three episodes available, each 20–25 minutes, and have plenty more planned for the next weeks and months. If you have topics you’re interested in hearing about, please reach out and let us know.
Your cloud security podcast hosts are Anton Chuvakin, Head of Solutions Strategy, and Timothy Peacock, Product Manager, both at Google Cloud. We both have long backgrounds in security, Anton with many years as a Gartner analyst, and Tim with nearly a decade of experience managing enterprise security products.
All of our episodes can be found below, and you can expect more to come every few weeks.
Episode 1 “Confidentially Speaking” (episode download link)
- Guest: Nelly Porter, Group Product Manager @ Google.
- Topics covered:
- What is confidential computing?
- What risks are mitigated by confidential computing?
- What types of organizations must adopt confidential computing?
- How and where the data is encrypted?
- Resources: Confidential computing at Google Cloud
Episode 2 “Data Security in the Cloud” (episode download link)
- Guest: Andrew Lance, Founder of Sidechain
- Topics covered:
- What is special about data security in the cloud?
- How data security plays in the shift from perimeter and network security to identity-based security?
- Can I use detective data security controls and turn them into preventative controls?
- Resources: “Designing and deploying a data security strategy with Google Cloud” paper
Episode 3 “Automate and/or Die?” (episode download link)
- Guest: Joe Crawford, formerly in charge of cloud-native security at a large bank
- Topics covered:
- Can we automatically remediate (or is it response!) vulnerabilities and threats in the cloud?
- Did you require humans to be in the loop for your automation? Is that still automation if we do?
- Does security’s fear of automation have a place in the cloud?
Future episodes
After the first three episodes above, the topics we plan to cover in the near future include:
- Zero trust approach to security
- Modern Security Operations Centers (SOC)
- Security during cloud migration
- Role of IAM in cloud security
- More on data security in the cloud
- The role of trust in cloud security
- Cloud-native network security
- Container security
Learn more
Find this on Google Podcasts, Apple Podcasts, Spotify, Stitcher and wherever else podcasts can be found. You can also download the episodes directly here.
You can reach your hosts on Twitter (@CloudSecPodcast), and we really hope to hear from you, whether you agree or disagree with our takes. Please also suggest new topics for us to cover!
See you at Cloud Security Podcast by Google.
Originally published at Medium.
Wednesday, February 10, 2021
SOC Threat Coverage Analysis — Why/How?
As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my…
As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my analyst days, we looked at it as a part of a security use case lifecycle process. For example, we focused on things like number and quality of alerts per SIEM use case, false/useless alert (“false positive”) numbers and ratios (to useful alerts), escalations to incident response, tuning, etc.
But what about a more comprehensive look at detection coverage inside each tool? Is there a way to assess the net threat coverage represented by the aggregate detection coverage inside each tool and then all tools? What about coverage analysis down to the rules presence, performance and quality?
A recent SIEM data analysis released by CardinalOps, a startup in the threat coverage space, suggests that the detection coverage gap is large at many organizations. Log source configuration errors, broken log collectors, insufficient breadth of rules, rule errors, noisy rules, and other factors contribute to poor coverage in the average organization. This got me thinking about this detection-in-depth and detection coverage again.
To an extent, some Breach and Attack Simulation (BAS) vendors try to go there. But ultimately this is NOT a job for a BAS that needs to retain its judge or arbiter role, rather than live deep inside the security operations machinery. Here we need something a lot more operational and a lot more plugged into the SOC tools and processes.
Also to an extent, MITRE ATT&CK (and especially CAR) would be helpful for this, but it is a framework, not a tool or even a methodology. You can MITRE content to map some of the threats to detections, but there are more things involved in obtaining and, especially, keeping your detection coverage map current.
So, how would I approach systematically looking at detection coverage in my SOC?
- Do I know what threats I want to detect? Threat assessment process will answer that.
- Do I know what detection content (rules, algorithms, models, etc) I need for this? Detection engineering or use case management process will lead to the right content here.
- Do I know what data I need to run the detection content on? Some form of log/data source optimization process helps.
- Am I collecting this data? A checklist can help here.
- Is the data being collected in the right format, being parsed correctly (if needed) to drive the detection content in question?
- Is the rule actually working in real life? Test automation process will reveal that.
A few of these needs to be run in a loop (“Is this working? Is this working after some system changes were made?”). This is a clear security engineering challenge and opportunity.
(P.S.: Related to this topic, I want to announce that I joined the Advisory Board of CardinalOps; they call this area Threat Coverage Optimization; they have a research report out)
Related blog posts:
Originally published at Medium.
SOC Threat Coverage Analysis — Why/How?
As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my…
As I mentioned in Detection Coverage and Detection-in-Depth, the topic of threat detection coverage has long fascinated me. Back in my analyst days, we looked at it as a part of a security use case lifecycle process. For example, we focused on things like number and quality of alerts per SIEM use case, false/useless alert (“false positive”) numbers and ratios (to useful alerts), escalations to incident response, tuning, etc.
But what about a more comprehensive look at detection coverage inside each tool? Is there a way to assess the net threat coverage represented by the aggregate detection coverage inside each tool and then all tools? What about coverage analysis down to the rules presence, performance and quality?
A recent SIEM data analysis released by CardinalOps, a startup in the threat coverage space, suggests that the detection coverage gap is large at many organizations. Log source configuration errors, broken log collectors, insufficient breadth of rules, rule errors, noisy rules, and other factors contribute to poor coverage in the average organization. This got me thinking about this detection-in-depth and detection coverage again.
To an extent, some Breach and Attack Simulation (BAS) vendors try to go there. But ultimately this is NOT a job for a BAS that needs to retain its judge or arbiter role, rather than live deep inside the security operations machinery. Here we need something a lot more operational and a lot more plugged into the SOC tools and processes.
Also to an extent, MITRE ATT&CK (and especially CAR) would be helpful for this, but it is a framework, not a tool or even a methodology. You can MITRE content to map some of the threats to detections, but there are more things involved in obtaining and, especially, keeping your detection coverage map current.
So, how would I approach systematically looking at detection coverage in my SOC?
- Do I know what threats I want to detect? Threat assessment process will answer that.
- Do I know what detection content (rules, algorithms, models, etc) I need for this? Detection engineering or use case management process will lead to the right content here.
- Do I know what data I need to run the detection content on? Some form of log/data source optimization process helps.
- Am I collecting this data? A checklist can help here.
- Is the data being collected in the right format, being parsed correctly (if needed) to drive the detection content in question?
- Is the rule actually working in real life? Test automation process will reveal that.
A few of these needs to be run in a loop (“Is this working? Is this working after some system changes were made?”). This is a clear security engineering challenge and opportunity.
(P.S.: Related to this topic, I want to announce that I joined the Advisory Board of CardinalOps; they call this area Threat Coverage Optimization; they have a research report out)
Related blog posts:
Originally published at Medium.
Tuesday, February 02, 2021
Friday, January 22, 2021
From Google Cloud Blog: “New whitepaper: Designing and deploying a data security strategy with…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security strategy on Google Cloud.
- Read our launch blog here — a long excerpt is quoted below.
- Read Sidechain blog here — look for a useful data security migration checklist.
- Read the paper here[PDF]
— —
William Gibson said it best: “The future is already here — it’s just not evenly distributed.”
The cloud has arrived. Data security in the cloud is too often a novel problem for our customers. Well-worn paths to security are lacking. We often see customers struggling to adapt their data security posture to this new reality. There is an understanding that data security is critical, but a lack of well understood principles to drive an effective data security program. Thus, we are excited to share a view of how to deploy a modern and effective data security program.
Today, we are releasing a new white paper “Designing and deploying a data security strategy with Google Cloud” that accomplishes exactly that. It was written jointly by Andrew Lance of Sidechain (Sidechain blog post about this paper) and Dr. Anton Chuvakin, with a fair amount of help from other Googlers, of course.
Before we share some of our favorite quotes from the paper, let me spend a few more minutes explaining the vision behind it.
Specifically, we wanted to explore both the question of starting a data security program in a cloud-native way, as well as adjusting your existing daily security program when you start utilizing cloud computing.
Imagine you are migrating to the cloud and you are a traditional company. You have some data security capabilities, and most likely you have an existing daily security program, part of your overall security program. Perhaps you are deploying tools like DLP, encryption, data classification and possibly others. Suddenly, or perhaps not so suddenly, you’re migrating some of your data processing and some of your data to the cloud. What to do? Do my controls still work? Are my practices current? Am I looking at the right threats? How do I marry my cloud migration effort and my other daily security effort? Our paper seeks to address this scenario by giving you advice on the strategy, complete with Google Cloud examples.
On the other hand, perhaps you are the company that was born in the cloud. In this case, you may not have an existing data security effort. However, if you plan to process sensitive or regulated data in the cloud, you need to create one. How does a cloud native data security program look like? Which of the lessons learned by others on premise I can ignore? What are some of the cloud-native ways for securing the data?
As a quick final comment, the paper does not address the inclusion of privacy requirements. It is a worthwhile and valuable goal, just not the one we touched in the paper.
Here are some of our favorite quotes from the paper:
- “Simply applying a data security strategy designed for on-premise workloads isn’t adequate [for the cloud]. It lacks the ability to address cloud-specific requirements and doesn’t take advantage of the great amount of [cloud] security services and capabilities”
- A solid cloud data security strategy should rely on three pillars: “Identity / Access Boundaries / Visibility” (the last item covers the spectrum of assessment, detection, investigation and other monitoring and observability needs)
- Useful questions to ponder include ”How does my data security strategy need to change to accommodate a shift to the cloud? What new security challenges for data protection do I need to be aware of in the cloud? What does my cloud provider offer that could streamline or replace my on-premise controls?”
- “You will invariably need to confront data security requirements in your journey to the cloud, and performing a “lift and shift” for your data security program won’t work to address the unique opportunities and challenges the cloud offers.”
- “As your organization moves its infrastructure and operations to the cloud, shift your data protection strategies to cloud-native thinking.”
Originally published at Medium.
From Google Cloud Blog: “New whitepaper: Designing and deploying a data security strategy with…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security strategy on Google Cloud.
- Read our launch blog here — a long excerpt is quoted below.
- Read Sidechain blog here — look for a useful data security migration checklist.
- Read the paper here[PDF]
— —
William Gibson said it best: “The future is already here — it’s just not evenly distributed.”
The cloud has arrived. Data security in the cloud is too often a novel problem for our customers. Well-worn paths to security are lacking. We often see customers struggling to adapt their data security posture to this new reality. There is an understanding that data security is critical, but a lack of well understood principles to drive an effective data security program. Thus, we are excited to share a view of how to deploy a modern and effective data security program.
Today, we are releasing a new white paper “Designing and deploying a data security strategy with Google Cloud” that accomplishes exactly that. It was written jointly by Andrew Lance of Sidechain (Sidechain blog post about this paper) and Dr. Anton Chuvakin, with a fair amount of help from other Googlers, of course.
Before we share some of our favorite quotes from the paper, let me spend a few more minutes explaining the vision behind it.
Specifically, we wanted to explore both the question of starting a data security program in a cloud-native way, as well as adjusting your existing daily security program when you start utilizing cloud computing.
Imagine you are migrating to the cloud and you are a traditional company. You have some data security capabilities, and most likely you have an existing daily security program, part of your overall security program. Perhaps you are deploying tools like DLP, encryption, data classification and possibly others. Suddenly, or perhaps not so suddenly, you’re migrating some of your data processing and some of your data to the cloud. What to do? Do my controls still work? Are my practices current? Am I looking at the right threats? How do I marry my cloud migration effort and my other daily security effort? Our paper seeks to address this scenario by giving you advice on the strategy, complete with Google Cloud examples.
On the other hand, perhaps you are the company that was born in the cloud. In this case, you may not have an existing data security effort. However, if you plan to process sensitive or regulated data in the cloud, you need to create one. How does a cloud native data security program look like? Which of the lessons learned by others on premise I can ignore? What are some of the cloud-native ways for securing the data?
As a quick final comment, the paper does not address the inclusion of privacy requirements. It is a worthwhile and valuable goal, just not the one we touched in the paper.
Here are some of our favorite quotes from the paper:
- “Simply applying a data security strategy designed for on-premise workloads isn’t adequate [for the cloud]. It lacks the ability to address cloud-specific requirements and doesn’t take advantage of the great amount of [cloud] security services and capabilities”
- A solid cloud data security strategy should rely on three pillars: “Identity / Access Boundaries / Visibility” (the last item covers the spectrum of assessment, detection, investigation and other monitoring and observability needs)
- Useful questions to ponder include ”How does my data security strategy need to change to accommodate a shift to the cloud? What new security challenges for data protection do I need to be aware of in the cloud? What does my cloud provider offer that could streamline or replace my on-premise controls?”
- “You will invariably need to confront data security requirements in your journey to the cloud, and performing a “lift and shift” for your data security program won’t work to address the unique opportunities and challenges the cloud offers.”
- “As your organization moves its infrastructure and operations to the cloud, shift your data protection strategies to cloud-native thinking.”
Originally published at Medium.
From Google Cloud Blog: “New whitepaper: Designing and deploying a data security strategy with…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security…
Here is another very fun resource we created (jointly with Andrew Lance from Sidechain), a paper on designing and running data security strategy on Google Cloud.
- Read our launch blog here — a long excerpt is quoted below.
- Read Sidechain blog here — look for a useful data security migration checklist.
- Read the paper here[PDF]
— —
William Gibson said it best: “The future is already here — it’s just not evenly distributed.”
The cloud has arrived. Data security in the cloud is too often a novel problem for our customers. Well-worn paths to security are lacking. We often see customers struggling to adapt their data security posture to this new reality. There is an understanding that data security is critical, but a lack of well understood principles to drive an effective data security program. Thus, we are excited to share a view of how to deploy a modern and effective data security program.
Today, we are releasing a new white paper “Designing and deploying a data security strategy with Google Cloud” that accomplishes exactly that. It was written jointly by Andrew Lance of Sidechain (Sidechain blog post about this paper) and Dr. Anton Chuvakin, with a fair amount of help from other Googlers, of course.
Before we share some of our favorite quotes from the paper, let me spend a few more minutes explaining the vision behind it.
Specifically, we wanted to explore both the question of starting a data security program in a cloud-native way, as well as adjusting your existing daily security program when you start utilizing cloud computing.
Imagine you are migrating to the cloud and you are a traditional company. You have some data security capabilities, and most likely you have an existing daily security program, part of your overall security program. Perhaps you are deploying tools like DLP, encryption, data classification and possibly others. Suddenly, or perhaps not so suddenly, you’re migrating some of your data processing and some of your data to the cloud. What to do? Do my controls still work? Are my practices current? Am I looking at the right threats? How do I marry my cloud migration effort and my other daily security effort? Our paper seeks to address this scenario by giving you advice on the strategy, complete with Google Cloud examples.
On the other hand, perhaps you are the company that was born in the cloud. In this case, you may not have an existing data security effort. However, if you plan to process sensitive or regulated data in the cloud, you need to create one. How does a cloud native data security program look like? Which of the lessons learned by others on premise I can ignore? What are some of the cloud-native ways for securing the data?
As a quick final comment, the paper does not address the inclusion of privacy requirements. It is a worthwhile and valuable goal, just not the one we touched in the paper.
Here are some of our favorite quotes from the paper:
- “Simply applying a data security strategy designed for on-premise workloads isn’t adequate [for the cloud]. It lacks the ability to address cloud-specific requirements and doesn’t take advantage of the great amount of [cloud] security services and capabilities”
- A solid cloud data security strategy should rely on three pillars: “Identity / Access Boundaries / Visibility” (the last item covers the spectrum of assessment, detection, investigation and other monitoring and observability needs)
- Useful questions to ponder include ”How does my data security strategy need to change to accommodate a shift to the cloud? What new security challenges for data protection do I need to be aware of in the cloud? What does my cloud provider offer that could streamline or replace my on-premise controls?”
- “You will invariably need to confront data security requirements in your journey to the cloud, and performing a “lift and shift” for your data security program won’t work to address the unique opportunities and challenges the cloud offers.”
- “As your organization moves its infrastructure and operations to the cloud, shift your data protection strategies to cloud-native thinking.”
Originally published at Medium.
Subscribe to:
Posts (Atom)
Dr Anton Chuvakin
