Securing Cloud-Native Data in Transit

Data is central to all cloud-native applications, and keeping that data safe and secure is a challenge all application owners struggle with.

When discussing securing the data you use with your cloud-native application, you need to think about two different types of data. The two types of data are data at rest and data in transit.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

Data at rest is data that is being stored within your application in some data store. We discussed data at rest in last week’s article. This week, we’re going to discuss data in transit.

Data in transit is data that is moving into and out of your application from either your customers or to external services and systems (data in transit externally). But it also refers to data moving from one service or location within your application to another service or location within your application (data in transit internally).

Figure 1. Data at rest and data in transit.

Figure 1 illustrates these data types in a simple application. Here, data is transmitted from the external user to an internal service, from an internal service to and from the database and between internal services are all examples of data in transit. Meanwhile, data stored in the database itself is data at rest.

Securing Data in Transit

Protecting data in transit involves preventing it from being read, misdirected, modified or misrepresented as it moves from one location to another. As shown in Figure 1, data in transit involves transmitting data external to your application as well as transmitting data between services within your application. The risks involved in protecting data in transit are very different than those of data at rest. Data at rest is mostly about preventing someone from reading or modifying stored data. The techniques involved all evolve around encryption and maintaining encryption keys.

But protecting data in transit involves three distinct types of risks, with different methods for addressing them. The three main types of risks to data in transit are:

• Data read threat. A data read risk is when sensitive data is sent between services. If a bad actor is able to read the data while it is in transit, the data could be used by the bad actor to compromise the system. Examples of data in transit that is vulnerable to a data read threat include passwords, credit card numbers and personally identifiable information such as social security numbers and phone numbers.
• Data change threat. A risk to data change is when sensitive data is vulnerable to being changed by a bad actor while it is being transmitted from one place to another. If a bad actor is able to intercept and then modify in-transit data, they could change the meaning of the data, compromising its integrity. For example, if a wire transfer between banks were intercepted and the dollar amount was changed or the destination of the transfer was changed, this would be a data change attack.
• Data origin threat. A data origin threat is when a bad actor can generate new data and make it look like the data was created by someone else. On the surface, this may appear similar to the data change threat, but usually, the origins and methods of attack are different. An example of a data origin attack includes creating a fraudulent bank transfer or issuing an illegal or damaging request on behalf of an unsuspecting person.

For the first two types of threats—data read and data change threats—the methods of preventing attack are similar to data at rest: We encrypt the data. By encrypting the data, we prevent unauthorized people from reading the request while it is in process. The encryption makes it harder to change the data as well.

Encrypting data in transit is typically less involved than encrypting data at rest because the transmission time is typically short. If you remember, encrypting data at rest can involve keeping data encrypted for very long periods of time. This creates problems in implementing good security practices such as key rotation. With data in transit, typically, the duration of the transmission is relatively short, meaning the need to keep legacy encryption keys around and manage them is substantially reduced. Figure 2 illustrates this difference.

Figure 2. Data in transit is encrypted for a shorter period typically than data at rest.

Data Origin Attacks Need More

But simple encryption does not help with data origin attacks. For data origin attacks, additional strategies need to be used to ensure messages come from the proper location. To do this, we typically have to use authentication tokens, signed certificates to validate ownership and similar advanced security strategies on top of simple data encryption.

In modern applications, TLS/SSL are the primary tools to implement these advanced security practices. These protocols provide end-to-end encrypted communications between two clients, which helps reduce read and change attacks. But in addition, they use certificates to validate the proper origin of the messages, which reduces data origin attacks.

Today, on-the-fly SSL encryption is so simple and commonplace that almost all web applications make use of it. SSL, in the form of the HTTPS web protocol, is used for most modern websites, whether sensitive data is being transferred or not. The cost to implement is so low that it’s typically considered best practice for all browser-to-website communications for nearly all web applications to use HTTPS.

Keeping data safe and secure is critical in most cloud-native applications. Virtually every business requires safe and secure communications in order to provide their business services. Bad actors abound, so keeping applications—and their data—safe and secure is critical to keeping our businesses operational.