data protection in the cloud v6 - kenneth g. hartman · data protection, such as retention,...

Data Protection in the CloudA Look at the Good, the Bad, and the Ugly

Kenneth G. Hartman

Data Protection in the Public Cloud—a look at the Good, the Bad, and the Ugly

ABSTRACTCustomers want to ensure that they can entrust their sensitive data to public cloud providers. This often leads to discussions with the cloud provider on various aspects of data protection, such as retention, encryption, and key management. If encryption is not implemented properly it will not provide the security assurance customers expect, resulting in misplaced trust. This talk will look at encryption at rest in various layers of the application stack with a focus on the risks each type of encryption mitigates. We will also look at various cloud‐related key management schemes, including “bring your own key” (BYOK) and cloud‐based Hardware Security Modules (HSMs). Lastly, we will cover potential problems with customer data‐retention that should be explored with the cloud service provider.

1

© 3/14/2019 Kenneth G. Hartman

AboutMe

“I help my clients earn and maintain the trust of their customers”

Kenneth G. Hartman• BS Electrical Engineering, Michigan Technological University• MS Information Security Engineering, SANS Technology Institute• Multiple Security Certifications: CISSP, GIAC Security Expert, etc.• SANS Instructor

The content and opinions in this presentation are my own and do not necessarily reflect the positions, strategies, or

opinions of any current or previous employer.

www.kennethghartman.com@kennethghartman

Originally considered calling this talk “Confessions of a Cloud Security Product Manager” to be more scintillating but in truth, I have always tried to honor the trust of the customers of the various companies I have worked for by being very candid about the current state of the security control that they were inquiring about.

That being said, I have come across some data protection issues that surface in various forms in the cloud and I thought that it would be interesting to discuss them in contrast with some good examples.

I will not be up here trying to convince you to use the cloud. One thing is for sure, the cloud is here to stay and most organizations are using the cloud, whether they know it or not.

I am Ken Hartman, among other things, I am a SANS Instructor for the SEC545 – Cloud Security Operations course. I have worked for a variety of cloud service providers, but am speaking here today, on my own…and am not speaking about any of them in particular…just things I have seen along the way.

2


Murder in the Amazon Cloud

https://www.infoworld.com/article/2608076/data‐center/murder‐in‐the‐amazon‐cloud.html

June 2014

Infoworld Article: Murder in the Amazon Cloud

Also See: https://www.itgovernance.co.uk/blog/the‐attack‐that‐forced‐code‐spaces‐out‐of‐business‐what‐went‐wrong/

3


��

� ��

��

��

��

��

��

��

!��"�� !��"�� !��"�� !��"��

�#� �� #� �� #� �� #� ��

Cloud Delivery Models

When asked to define “cloud computing, ” the tongue‐in‐cheek answer is “well, it is someone else’s computer.” But let’s dig into this a little deeper to set the context for our discussion on data protection. There are three different conceptual delivery models, Infrastructure as a service, Platform as a Service (“PaaS”) and Software as a service (“SaaS”).

One this slide, I am contrasting these with Colocation, where you put your computing hardware in someone else’s data center. The service provider will provide you with physical security and basic utilities, but the rest is your responsibility. With Infrastructure as a service, the CSP provides the hardware and a hypervisor that allows you to provision virtual machines, either via a web application or by making API calls to their infrastructure. As the customer, you are responsible for everything else. Going up a level, with PaaS, you are using a platform of some sort…this could be a DBMS, an engine that runs customer supplied program code, containers, or what have you.. Software as a Service is typically a web application that delivers a set of niche functionality.

Most CSP’s have articulated a Shared Responsibility Model of some sort. The purpose of which is to clearly delineate where their security responsibilities end and the customer’s begin. The large CSP’s have them online so that everyone can read them.

Sometimes SaaS solutions are built on another’s CSP’s IaaS offering (example AWS). And by far, the largest number of cloud providers are SaaS…something like 80%

I mentioned that these are conceptual models. Sometimes it is hard to pigeonhole a provider because they offer multiple services. But the model is helpful to keep in mine as we discuss data protection responsibilities

4


Public Cloud Adoption

https://www.zdnet.com/article/cloud‐providers‐ranking‐2018‐how‐aws‐microsoft‐google‐cloud‐platform‐ibm‐cloud‐oracle‐alibaba‐stack/

RightScale 2018 State of the Cloud Report:81% of enterprises have a multi‐cloud strategy, leveraging almost 5 clouds on average57% of enterprises already have a central cloud team with another 24% planning one

Which cloud services are being used

5

© 3/14/2019 Kenneth G. Hartman https://www.cnbc.com/2018/04/27/microsoft‐gains‐cloud‐market‐share‐in‐q1‐but‐aws‐still‐dominates.html

Amazon is still the market leaderMicrosoft is aggressively ramping upGoogle is definitely a player.It will be interesting to see what IBM does with their recently announced acquisition of RedHatAnd Alibaba will be certainly important to track as well

How much each cloud service is being used

6


https://financesonline.com/uploads/2016/12/saas2.jpg

Lost of players in the SaaS space, including some well‐known players…

7


DocuSignWorkdayAsanaService Now

https://appealie.com/saas‐awards‐2017/

8


Data Resolution LLC Christmas Eve 2018

Ransomware

• ERP Hosting, BCP, Cloud Services

• Hosted Dynamics GP

• 30,000 Business Customers

• 5 Data Centers Worldwide

• Ryuk Ransomware 12/25/18

• Via a Compromised Account

• Locked out of its Systems

• Shutdown Network to Eradicate Malware

https://krebsonsecurity.com/2019/01/cloud‐hosting‐provider‐dataresolution‐net‐battling‐christmas‐eve‐ransomware‐attack/

Posting on the right is from the company as shared via Dropbox

9


“Your data does not look compromised” –Dataresolution.net

Jan 2, 2019

What exactly does compromised data look like?

10


Can I trust the cloud?

Where is my data?

Who is accessing my data?

Who is protecting my data?

During one of the breaks when I was teaching at a SANS Conference, I was chatting with a student from another course in the line for coffee. After exchanging the introductory pleasantries the conversation shifted to the course I was teaching: SANS SEC545 – Cloud Security Operations. And she said, “my organization could never use the cloud, because our data is too sensitive. I asked her what her primary concerns were, and right off the top of her head she said:• Where is my data?• Who is accessing it?, and • Who is protecting it

And I said…”well said….mind if I write that down”

As humans, we are hardwired with trust issues, this has helped us to survive throughout the generations. We also have a tendency to be more likely to trust those that are near us, those we spend time with, and those that look like us.

As a result, sometimes that trust is misplaced. As Security Professionals, our job is to make sure the trust we put in the systems that secure our data is well‐founded.

This has the formal name of “Security Assurance”

Security assurance is confidence that an entity meets its security requirements, based on specific, tested evidence.

11


Reluctance to Trust

Assume that external systems are insecure

Consider any data you receive from a system you do not have complete control over to be insecure and a source of attack.

Minimize the system elements to be trusted

Trust is transitive. Once you dole out some trust, you often implicitly extend it to anyone the trusted entity may trust.

Trusted programs should not invoke untrusted programs, ever.

https://www.us‐cert.gov/bsi/articles/knowledge/principles/reluctance‐to‐trust

Excerpts from the US‐CERT.GOV “Build Security In” article on Reluctance to Trust

“Developers should assume that the environment in which their system resides is insecure. Trust, whether it is in external systems, code, people, etc., should always be closely held and never loosely given.”

“Sometimes it is prudent not to trust even yourself. It is all too easy to be short sighted when it comes to your own ideas and your own code.”

12


Data ManagementLife Cycle

https://www.nordstargroup.com/life‐cycle/attachment/lifecycle‐management/

No discussion on data protection can be complete without discussing the Data Management Life Cycle. To set the stage, I want to highlight some of the life cycle phases that can be problematic in the cloud.• Because it is so easy to open an account with a cloud service provider, Data Creators

may not focus data protection.• Advances in data science and artificial intelligence tempts some to play with data in

ways not permitted by Data Use Agreements or without the permission of the data subjects

• Many cloud systems (i.e Google Drive and Dropbox) make it so simple to share files, but sometimes the data is regulated and disclosures of data needs to be tracked—for example, with HIPAA

• And speaking of HIPAA, what about transforming data, such as De‐Identification (removing the personally identifiable information?

• Who owns the data then? And what about the metadata?

Data gives our company competitive advantageOur goal / Attackers goal

Movement across Trust BoundariesProd to Corp movement Same data protections (data use agreements)

Archive & Backups *Remember Code Spaces

Data Destruction at the CSP?Common Answer: “We keep your data for the duration of your subscription with us”Any selective deletes are your responsibility

Ok, but how are backups deleted?

13


https://antonioperez.pro/crear‐crud‐basico‐ruby‐on‐rails/

When talking to the developers of SaaS offerings, I always want to know if they understand CRUD. And implemented itWhen it comes to sensitive data, it is paramount to log all CRUD operations

Read Access too! (CUD ?)

Additional Issues:• Direct Database Access by DBAs not shown in application access Logs

I push for services to have only one door – the front door, the API. And that is the only way data is allowed to move in and out, so it is logged

14


Applications must also log changes to user accounts. User “Bob” couldn’t have changed that data record, he doesn’t have permission…but did he once have access?

I call this out because I have seen Software that was not designed from the beginning to provide this level of accountability. It had to be refactored later after customers clamored for it, and the implementation was clearly not very well thought out.

I have not performed a security review of Sales Force, but am going to use them for a couple of examples (good examples) because of their great name recognition and their clear documentation.

15


In addition to user permissions, what about user records themselves?

What happens when Sally Brown gets married and becomes Sally Jones? We would hope that all of the system activity that Sally made when she was Sally Brown is tied to her activity with her new name, Sally Jones. For most systems, it is…because they use a database table Key (“User Key”) to uniquely identify the user record in the table. Unfortunately, I have reviewed systems where they did not track changes to this user record. Therefore one could not tell when Sally Brown became Sally Jones in the system.

It is even more problematic when the application exposes the database table key to the user and it is used as a user ID and the user id cannot be changed (sjones). Sally Jones gets divorced and is adamant that she does not want her user ID to be sjones….So they have no choice but to make her a new account!!

But typically, the DB table key will be either a GUID or a sequential Integer. I prefer a GUID (Globally Unique Identifier) and here is one example of why….A horror story

A particular application was designed to be single tenant and had integer database table keys for the user table. As most of you may know, this primary key can then be used in other database tables to reference the user. For example, a table that tracks user history would not refer to the user Sally, by name, but by her Key in the User Table.

In the process of converting “this particular application” from a single‐tenant SaaS application to a multi‐tenant application and merging databases, the User Key was no longer unique and havoc ensured.‐‐‐‐‐‐After all, what is it that that we are after? …

16


As an administrative user who is a tenant of a SaaS Cloud Product, can you:

• Reconstruct a single user’s activities in the system across a period of time?

• Determine when an administrator modified a user’s permissions

• Determine when every system configuration setting was changed, and by

whom?

How easy is this data to view and understand?

Does it show the before and after state of the setting?

The quality of this audit reporting capability is what differentiates the good from the great SaaS providers

17


User Impersonation

Keeping all this in mind…User Impersonation is another area where system designers need to tread very carefully. Tenant Administrators like the User Impersonation feature of an application because it allows them to see the system and its data the way a user sees it. Great for trouble shooting and making sure the user’s permissions are dialed in properly.

But, how does the system log activity while a user is being impersonated? As the user or the impersonator? The right answer is BOTHAfter all, with regard to system activity, our goal is Nonrepudiation, right? That is why we assign users unique accountsAlso, are there limits on what a user impersonator should be able to do?

Salesforce: If MFA is enabled, the user needs to provide the impersonator with their MFA code. Seems like a good idea to me.

18


Services Acting on Your Behalf

AWS CloudTrail logs every API callfrom both users and services

Administrative Users must explicitly configure AWS Services to Assume a Role

AWS CloudWatch can trigger alerts and actions based on CloudTrail logs

By requiring services to assume a role to perform work that gets logged by CloudTrail, AWS increases the transparency of how they access your data

By requiring services to assume a role to perform work that gets logged by CloudTrail, AWS increases the transparency of how they access your data

One of the big concerns that most tenants of the cloud have is they wonder what is the CSP doing with my data? In the past couple of years, AWS has redesigned all of their services such that you, as the tenant have to grant the particular service permission via an IAM role. At the same time, AWS made sure that every time those permissions are used by a service, a log entry gets created in CloudTrail.

I really appreciate the transparency that this creates for the tenant.

19


Encryption Snake Oil

• “Trust us, we know what we are doing”

• Technobabble

• Conflation of Terminology (i.e. “Passphrase” & “Key”)

• Secret Algorithms / Proprietary Cryptography

• “Unbreakable Encryption” or Military‐Grade Encryption

• Expert Reviews

http://www.interhack.net/people/cmcurtin/snake‐oil‐faq.html

I have to constantly remind folks that encryption is not a magic bullet. For some, it is almost like a Jedi mind trick. “Oh, you are using encryption. I guess my data is safe. Not so fast. Just because they are using AES‐256, it does not mean that they are twice as secure as AES‐128!

You have to drill into the details, and when you do, you may be surprised. My ears perk up when I hear the vendor conflating terminology. Such as:• Encoding or obfuscating versus encryption• Checksums versus secure digital hashing

I once had to extricate myself from a conversation with a guy who was convinced that he discovered “magnetic energy” in rare earth magnets. He drew up a diagram of what amounted to a perpetual motion machine. No that is not “magnetic energy” it is magnetic force. Two different but related concepts.

So, with any system that involves encryption, you have to dig deep enough to verify that the vendor knows what they are talking about.

20


Creation

Backup

Deployment

RotationExpiration

Archival

Destruction

Monitoring

http://www.secureconsulting.net/2008/03/the_key_management_lifecycle_1.html

Key Management Life Cycle

One very good way to do this is to dig into the Key Management Life Cycle. I have spent hours talking with very savvy customers in the Financial Sector grilling me about the source of entropy used to generate the keys at a company that I worked for. I thought that was fine. I understood their need to feel confidence in our implementation of encryption.

Next, where are you backing up the encryption keys? That is another area that can be attacked. And if you are not backing up the keys, that could create an availability issue.

I won’t belabor the Key Management Life Cycle, but in my opinion, Cloud Service Providers should have this well documented and available for customers. Of particular interest is Key Rotation and how they implement tenant‐specific keys.

SaaS providers need the closest scrutiny

21


The system that holds the encryption key controls access to the protected data!

Ok, the CSP says they use encryption, but what is it that they are encrypting? How do they respond when you ask them why they are encrypting? “To protect the data” How does it protect your data? ANSWER: It helps enforce access control!

Encryption should be used as a technical control to treat a specific risk. Therefore, it is critical to be cognizant of what a particular type of encryption actually does and does not mitigate.

{discuss table}

Attacker: How can I get the key or impersonate something (user, service, function, etc) that has the rights to use the key?

22


Crypto‐shredding (Cryptographic Erasure)

• Proper sanitization considers the media and data classification

• Sanitization methods: Clear, Purge, Destroy

• Destruction of Data ≠ Destruction of Media

Per NIST SP 800‐88r1 (2014), Cryptographic Erasure:

• Sanitizes the cryptographic keys used to encrypt the data, as opposed to sanitizing the storage locations of the encrypted data.

• Sanitizes media very quickly and supports partial (selective) sanitization

• Can be difficult to verify, so combine with another technique if needed

• Depends on strong crypto (FIPS 140‐2) and strict control of the encryption key

How is my data actually deleted? Some CSPs may be evasive and some may not have completely thought through how they want to answer this

Do you really think the CSP overwrites or shreds all of the drives that touched your data? Thousands of HDDs

How much does it cost to overwrite a Petabyte of Data?Issues with overwriting Solid State Drives (wear leveling)Mirroring and striping => fragments of files everywhere

Degaussing does not always work and shredding is hard for very small media (Micro CF)

Post Quantum Computing Threat? Don’t put that data into the cloud!

23


Symmetric Encryption

Key

CiphertextPlaintext E

Key

PlaintextCiphertext E

Goal of Encryption: To ensure privacy by keeping the information hidden from anyone for whom it is not intended, even those who can see the encrypted data.

Recall that the goal of encryption is to keep data secret from an adversary even if they have the cipher text. Also, recall that for symmetric encryption we use the exact same cryptographic cypher and key to decrypt the data as was used to encrypt it.

So with that in mind, any issues with this next slide?

24


Application Encryption

John

John

John

John

John

[email protected]

(650) 123‐1234

Column Data

FirstName JIrj3s5AjdNx1o1yuwZedw==

LastName JIrj3s5AjdNx1o1yuwZedw==

ScreenName JIrj3s5AjdNx1o1yuwZedw==

Email Sm5g3g5n45IJJGjcDAvfng==

Phone MJpVA3rGz8ZBu9kqXRSZ6Q==

Password JIrj3s5AjdNx1o1yuwZedw==

Column Data


LastName OtfbKkSZAfgUgs2GOTM4ig==

ScreenName Eon/hPL9ZU2CTehVZZMSZQ==


Phone v82HPTqV7joaQ7vexGFwTA==

Password Jy6VF4BVbUMAkxxT6cnToQCXDJEUa8

This?

Or This?

Here we see the data in the form, and the data in the database. You are the attacker, and somehow you are able to query the database. (Rouge DBA, SQLi, etc)

• Base64 encoding is not encryption• Let’s say they Base64 encoded the Cipher Text• No IV, or same IV for all columns• WORST: Not Salting or Hashing the PW

When using encryption, you want to do everything you can to prevent the attacker from seeing patterns in your ciphertext

25


Application Encryption

John

Jy6VF4BVbUMAkxxT6cnToQCXDJEUa

John

John

Jy6VF4BVbUMAkxxT6cnToQCXDJEUa

[email protected]

(650) 123‐1234

Column Data






Password Jy6VF4BVbUMAkxxT6cnToQCXDJEUa

Column Data






Password John

When reviewing the code for one system, I saw that they were using symmetric encryption for the password.So I copied the Password from the Database and Pasted it in the Password field for a new record and was able to get the plaintext password out of the database by looking at the new record.

Facepalm! But, hey, they were using AES256

So their first attempt to fix this was to concatenate the email to the password before running it through the encryption. Yeah, this prevented my simple trick, but if there is one thing that everyone learned from multiple breaches similar to the Linkedin Security Incident of 2012 (117 Million Passwords Breached), is that you HAVE to SALT and HASH your passwords

26


Chosen Plaintext Attack

Key

CiphertextPlaintext E

Attacker obtains ciphertext (i.e. SQLi or system compromise)

Attacker controls certain plaintext (operating as a user of the system)

Goal of Attack: Glean information that can help determine the encryption key that is then used to decrypt other sensitive information protected by the same key.

So, if an attacker can insert one or more records of their choosing, and can see the resulting cypher text they may be able to perform a chosen plaintext attack. This is made even easier if the attacker has created one or more accounts on systems that allow free trial accounts….Kinda like Linkedin

27

Types of Cryptographic Attacks

Theoretical Models

• Known‐plaintext attack

• Chosen plaintext attack

• Ciphertext‐only attack

• Chosen‐ciphertext attack

• Chosen‐key attack

Practical Attacks

• Brute force attack

• Man‐in‐the‐middle attack

• Frequency attack

• Replay attacks

• etc.

My goal in discussing this, is not to make anyone an expert in crypto. In fact I am not a crypto expert. My primary goal is to emphasize that if you ARE implementing encryption in a SaaS application, you probably should have a third party expert review your implementation.

Some companies will spend hundreds of thousands of dollars on Pen Testing, despite the fact that they have known vulnerabilities that they are not patching. Maybe spend some of that on application code reviews instead.

Other common mistakes:Using immutable memory storage structures like “String” variables in Java that contain important secrets. You may end up with multiple copies in memory. Instead use Char[ ] data typeHold secrets in memory only as long as needed, but no more. Then overwrite it.

Remember Heatrbleed? Sometimes vulnerabilities will spill server memory. Reduce this exposure by limiting time in memory

Speaking of server memory…

28


Heapdump (as a Service) ?!?

Spring Boot 2.x Actuator API Endpoints:• /configprops – allows us to fetch all@ConfigurationProperties beans

• /env – returns the current environment properties. Additionally, we can retrieve single properties

• /flyway – provides details about our Flyway database migrations

• /health – summarizes the health status of our application

• /heapdump – builds and returns a heap dump from the JVM used by our application

• /info – returns general information. It might be custom data, build information or details about the latest commit

• /logfile – returns ordinary application logs

• /loggers – enables us to query and modify the logging level of our application

• /scheduledtasks – provides details about every scheduled task within our application

• /sessions – lists HTTP sessions given we are using Spring Session

• /shutdown – performs a graceful shutdown of the application

https://www.baeldung.com/spring‐boot‐actuators

A heap dump is a snapshot of the memory of a Java™ process.The snapshot contains information about the Java objects and classes in the heap at the moment the snapshot is triggered.

29


Client Side Encryption with AWS S3

https://www.slideshare.net/AmazonWebServices/encryption‐and‐key‐management‐in‐aws/

Encrypting Data BEFORE it goes into S3S3 = AWS Simple Storage Service (Think Dropbox but with an API)

This slide shows 3 different scenarios for encrypting data before loading it into S3.

(Not good or bad) As I discuss, think how you would attack it

1.) Encrypt it locally with your local key2.) Encrypt it with a VM with your local key3.) Encrypt it with a VM with your key from your cloud‐based key vault (like HashicorpVault)

30


S3 SSE With AWS Managed Keys


Alternatively: let AWS do it.

AWS generates a tenant‐specific master key for S3 (kept in KMS) and then a Data Encryption Key the DEK is used by the S3 Service to encrypt data on your behalf when you enable encryption for your S3 bucketsThe DEK is encrypted with the master key and stored as well

When a tenant wants to fetch the data, the S3 Service pulls the master key from the KMS, decrypts the DEKThe DEK decrypts the customer’s ciphertext and the S3 service sends the plaintext to the customer

31


S3 SSE with Customer Provided Keys


Another Scenario: You BYOK and send that key with along with the data you want stored as cyphertext in S3.S3 deletes the key from memory as soon as it completes its taskTo retrieve data from S3, you have to send your key to AWS so that they can decrypt the data and send you the cleartext

BYOK means you bring your own Key and GIVE IT to the Cloud Service Provider!!…Over and Over Again with every read or write

Lots of passing the Key back and forth.Requires proper key handling by CSP and the Customer

32


Bring Your Own Key (BYOK)

• Several cloud service providers support BYOK• Amazon Web Services• Microsoft Azure• Google Cloud Platform• Salesforce

• Gives customers a sense of control

• Creates some additional risks related to key management throughout the key lifecycle

• Lose/Destroy the Key and the Data is gone

• Forces legal actions requesting data access to involve customer

“Assuming sole control over an encryption key, however, is a hefty responsibility. Loss or error could prevent a business from decrypting its own data, resulting in paralysis. Theft of the encryption key puts the entire security operation in jeopardy, meaning that the user’s back up process must itself be subject to high‐security measures. What’s more, if the key is lost or stolen, help is very hard to come by. The service provider, having already been relieved of their key liability, is powerless to assist. In many ways BYOK replicates the problems associated with more traditional usernames and passwords. Key ubiquity, like password ubiquity, replaces one security headache with another: should there be a key to all the keys? How is that key secured? And so on.”

Excerpt from: https://www.cryptomathic.com/news‐events/blog/cloud‐encryption‐bring‐your‐own‐key‐is‐no‐longer‐enough

How well are you managing your SSH Keys? How about SSL Certificates?

33


• Not all CSPs are equal, especially in the SaaS space• Encryption and other data protection controls must be closely examined

• Ultimately, it is a trust calculation:

Can I trust the cloud? Where is my data? Who is accessing my data? Who is protecting my data?

The Trust‐Value Equation:“I must trust that the benefit that I gain from using your service exceeds the concerns (Fear, Uncertainty, and Doubt) that I have about using it.”

Service providers must focus on tilting the equation ever more in their favor by:• Increasing the utility of the service,• Improving the user‐friendliness of the service, and• Enhancing the perceived trustworthiness of the service.

My advice to CSP’s:Naturally, the best way to enhance the perceived trustworthiness of the application is to improve its security such that it will withstand scrutiny from each customer’s security experts. It is also important to articulate the security considerations of the service in a credible way without overstating it.

My advice to customers of Cloud Services:Dig into the details. The Devil is in the Details. Only partner with the CSPs that welcome the scrutiny.

34


More Information:

• Google Infrastructure Security Design Overview

• AWS Key Management Service Best Practices

• AWS KMS Cryptographic Details

• Blog: The Trust‐Value Equation

35

data protection in the cloud v6 - kenneth g. hartman · data protection, such as retention,...

Documents