CEK-03: System in the Middle is a violation of CEK-03 (as well as IPY-03) can we measure how often this occurs

[pritikin]

In this context "System in The Middle " is internal decryption of network traffic. Walt argues this violates "Provide cryptographic protection to data at-rest and in-transit, using cryptographic libraries certified to approved standards".

example 1: Such as an org sending traffic between an application and the db "in the clear" instead of encrypting that traffic. Such as when that traffic is on an internal network. For example terminating encryption at the perimeter and then pushing it internally as unencrypted traffic.

example 2: a proxy decrypts encrypted transport. does analysis. re-encrypts as it moves on.

example 3: web traffic is decrypted for inspection which violates privacy and security of individuals.

We want a metric that measures how often these cases occurs so we can evaluate how well the organization is realistically protecting data at-rest and in-transit. If this behavior is so wide spread that almost every flow is decrypted by intermediaries then can we realistically argue that CEK-03 is met?

[pritikin]

Proposed metric: Expression:

1) Pure Encrypted Traffic Analytics could tease out example1, but would be blind the other examples. e.g. align with existing IPY-03 (plus fixes proposed)

2) Test: from outside the network connect to a lot of extranal hosts. compare this against when you connect inside the network and count the proxies detected.

3) You can scan an asset registry for proxies or reverse proxies. And use configuration scanning of the proxies.

4) You can scan an asset registry for proxies or reverse proxies. And combine the results with the encrypted traffic analysis.

We choose number 4. And suggest the metric flesh out the details.

[pritikin]

For each detected proxy the number of external keys must match the internal keys. e.g. use ETA to detect if a system-in-the-middle is configured.

expression: % of TLS flows through proxies where keys mismatch / total number of TCP/UDP flows through proxies goal: 0%

[rajkrishnamurthy]

I have few questions on this metric?

1. Are we being too prescriptive? I hear the concern that terminating any traffic other than at the target application (beyond the perimeter) opens up questions on data protection and data privacy. However, isn't that for the the organization or the CSP to define? How can we fit this assumption to all architectures? For example, I may want to route traffic differently within my perimeter based on headers and payload. Why would I be forced to encrypt them with same key value pairs as i route the traffic within my perimeter?
2. Is this metric even practical? If we were to automate and measure, can we list the steps that we need to take. For example, In order to implement the traffic we will need to do the following:
   • Get an inventory of all traffic flows; particularly the origin (source) and the target (how do we determine the ultimate application target)
   • Identify which of those are terminated with proxies vs. pass through
   • For the ones terminated at the proxies, identify if we decrypt. how? Is it by re-encryption? If so, do we determine if the encryption key at the target (which target) is that same as that of the source? Who will maintain these states?
   • For the ones that are pass-through, recursively evaluate if they are terminated anywhere other than the target application (how do we do that?)

@pritikin: I quickly perused through Cisco Encryption Traffic Analytics. That does not solve this problem. As I understand it, Cisco ETA does not use any homomorphic encryption techniques but does pattern matching on unencrypted traffic fingerprints.

If you think there are simpler ways to do this, please outline. I would love to get some more opinions on this metric. @pritikin @mosi-k-platt @JonathanChristopherson @LefterisSk @apannetrat I don't have Walter's handle.

[mosi-k-platt]

All good points @rajkrishnamurthy. Some additional comments and questions:

1. How many CSPs view encryption of internal traffic as a reasonable and appropriate response to insider risk? If a CSP designed their security to manage risk with trusted internal networks for data communication and proxies for security analysis and inspection of content, then they wouldn't report on this metric unless they recently migrated to a new security architecture that relies on transport layer encryption for internal network traffic. Does the working group believe the majority of CSPs have done this or will have done this by the time continuous audit metrics are incorporated into the STAR registry?
2. What about CSPs that choose to encrypt data instead of the transport layer? Arguably, that's a better security solution. Is it more important for the metrics to measure outcomes or security architectures?

[pritikin]

team discussion:

• tease cek-03-m2 apart do we don't conflate at rest and in transit with "Number of assets responsible for data at-rest or in-transit"
• add cek-03-m3 that specifically measure if the library is being used for "at rest"
• ipy-03-m2 measures if the library is being used for "in transit" (thus we don't need to add that).

[pritikin]

team discussion:

We have general agreement that trying to allow CSPs to declare part of their network "safe" and therefore not meet the controls in that area is "not a good idea". We will instead expect the metric SLO to allow some wiggle room as the industry gets serious about internal encryption.

[pritikin]

max will assign this to "abd al moniem zaian" (Zaian). edit: unfortunately I don't see an github account for Zaian. Once he reaches out via email or comments on this thread we can formally assign. He took the action item to produce draft metrics for the above team discussion.

[zzaian]

Hi Max, here is a primary control description.

Metric ID:CEK-03-M2

Metric Description: These metrics indicate which data sources communicate their internal traffic through encrypted methods.

Expression:

B: Total number of servers A: is number of servers with unencrypted internal communication Formula: (A/B)*100

Or

B: Total number of channels A: Is number of channels with encrypted internal communication Formula: (A/B)*100

Rules: According to organization internal policy some servers/channels can be left unencrypted. The exceptions must be documented and risks mitigated through additional controls

[pritikin]

We'll want to have this as CEK-03-M3 (some other number) to distinguish from the existing metric

[pritikin]

The comment in the rules is reflective of what the target should be: 80+ 90+ % whatever

[pritikin]

discussion in call is toward the 'channel' approach. because any server may have many many channels of communications.

[yehia3]

I will create a visual for the pilot.

[LefterisSk]

Following metrics could be used to improve CEK-03-m3

Metric Description: Percentage of data transmissions occurring over encrypted connections using cryptographic protocols within the cloud environment.

*Expression: "(A/B)100"** A. Number of encrypted data transmissions B: Total number of data transmissions

Rules: Data Source: Implement mechanisms to capture information on all data transfers within the cloud environment. This can involve utilizing tools provided by your cloud service provider (CSP) or leveraging network monitoring systems. Data Transfer Identification: Differentiate between encrypted and non-encrypted data transfers. This can be achieved by analyzing specific data points like: Port used: Secure connections typically utilize ports like 443 for HTTPS and 22 for SFTP. Encryption protocol: Identify protocols like TLS/SSL being used to secure the communication channel. Data Aggregation: Regularly collect data on the number of encrypted and total data transfers over a defined period (e.g., hourly, daily). Calculation: Apply the formula ((A / B) * 100) to calculate the percentage of data transfers encrypted.

Example: Monitored data shows 1000 data transfers secured using TLS/SSL in the last hour. The total number of attempted data transfers during the same period is 1200. Percentage of Encrypted Data Transfers: ((1000 / 1200) * 100) = 83.33%