Confusing use of "Sensitive Data"

[woodbe]

FDP_DAR_EXT.1 is for sensitive application data, but then the third bullet states that sensitive data could be protected according to FCS_STO_EXT.1, which is specifically about credentials. While this does meet the definition of sensitive data (which includes credentials and keys), it seems to be putting too many things into that bucket.

I think it would be best to keep credentials and keys as one item (covered specifically by FCS_STO_EXT.1) and then Sensitive data to be everything else.

Just to keep things clean, having "data" and "keys" mixed as "sensitive data" is confusing, and ideally should be minimized.

[jmcdaniels]

I think that is how it originally was, but we had to add the STO reference in DAR otherwise it looked like you were mandated to also encrypt credentials.

[woodbe]

I think I would exclude credentials from sensitive data since they are explicitly called out as their own category. Sensitive data as a whole could encompass credentials, PII and other information, but PII is explicitly called out, as are credentials, so I would see the Sensitive data as not including any of those areas.

It would likely mean needing some new definition text, but would probably make the expectations a little easier to understand overall (including what types of sensitive data the vendor may be expected to protect).

[jvdsn]

I do think there is value in allowing FCS_STO_EXT.1 here. Otherwise the SFR would need to be written to explicitly say "sensitive data (excluding credentials)" everywhere, which is probably infeasible at this point.

Right now the SFR is pretty explicit in saying that credentials are covered by FCS_STO_EXT.1. Maybe it could be more explicit, i.e. the selection option is changed to "protect credentials in accordance with FCS_STO_EXT.1"?

[woodbe]

If there was a new definition for Sensitive Data that excluded credentials it wouldn't need to be changed here.

Change the Technical Term definition:

Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author.

to not have the middle sentence of "Sensitive data must minimally include PII, credentials, and keys."

The PII Technical Term definition would then say something to the effect of (in addition to what is there) "this is a subset of Sensitive Data".

It would mean checking where Sensitive Data is used elsewhere to make sure that keys/credentials are used instead of Sensitive Data, but it would be cleaner.

[jvdsn]

If there was a new definition for Sensitive Data that excluded credentials it wouldn't need to be changed here.

Right, but perhaps this impacts other areas? This is where I could find sensitive data used in the PP (outside FDP_DAR_EXT.1):

T.PHYSICAL_ACCESS: An attacker may try to access sensitive data at rest.

Would have to be replaced by "sensitive data or credentials at rest"

FDP_DEC_EXT.1.2: Application Note: "Sensitive information repositories" are defined as
those collections of sensitive data that could be expected to be shared
among some applications, users, or user roles, but to which not all of
these would ordinarily require access.

Maybe doesn't have to be updated?

FMT_MEC_EXT.1.1: Application Note: Configuration options that are stored remotely are
not subject to this requirement. Sensitive Data is generally not
considered part of configuration options and should be stored according
to FDP_DAR_EXT.1 or FCS_STO_EXT.1.

Would be replaced by "Sensitive data or credentials are generally not ..."

FTP_DIT_EXT.1

Probably also would have to be updated to disallow sending plaintext credentials over the network.

[jmcdaniels]

For the moment I am landing on separating them not being worth the effort to split them apart seeing as this STO fix is already in place. I am going to leave this issue open for future revision consideration, if we get TRRTs in the future indicating this is causing issues or confusion it can be addressed then.

[woodbe]

Just commenting that this works for me, pushing it out to discuss is good.