feature: added new metrics:

[d-pizhuk]

• added descriptions and configurations for BlockCipher and BlockCipherMode metrics

[d-pizhuk]

@immqu from what I understand, you prefer using the compare function, but I don’t think it’s possible in this case. The code works as tested, though it depends on your requirements. Looking forward to your suggestions for improvement.
P.S. I guess a check failed due to the access issue.

[lebogg]

Please refer the issues you are closing @d-pizhuk

[oxisto]

Dont we already have this? https://github.com/Cybersecurity-Certification-Hub/security-metrics/blob/main/metrics/TransportEncryption/TlsCipherSuite/TlsCipherSuite.yaml or at least the old one should be deleted then and maybe we need to establish a common naming scheme, meaning that it would be TransportEncryptionBlockCipher or something

[immqu]

Thanks @d-pizhuk! Looking at the existing metric that @oxisto pointed out, it seems that you would split the existing metric up into 1) ciphers and 2) mode, correct?

[d-pizhuk]

this PR closes #145 and #146

[d-pizhuk]

Thanks @d-pizhuk! Looking at the existing metric that @oxisto pointed out, it seems that you would split the existing metric up into 1) ciphers and 2) mode, correct?

@immqu not just these 2 metrics, I would split it even into 3: block cipher, block cipher mode and secure mac (possibly, can be even 4, including secure key exchange metric). Also, we have metrics AESStandard and AESKeyLength (which are also related to the cipher suites)

[immqu]

Thinking about it, we could even split it up further. A TLS "configuration" consists of the following elements: protocol version, key exchange, authenticaiton, encryption (with algorithm, key length, block cipher, and block cipher mode), and hash.
But in my opinion, this is not very useful in practice: As a user, I would have to figure out which configurations are acceptable (say TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256) and then I would have to configure multiple metrics for the cross product of all accepted configs. I think it is better to use a metric like ValidTLSConfigurations where the allowed target values are a list of the configs shown above (e.g. TLS_AES_128_GCM_SHA256) rather than putting every config option into one metric. But I am curious about other suggestions!

Related PRs:

• https://github.com/Cybersecurity-Certification-Hub/security-metrics/pull/74/files
• metrics: Add AESKeyLength metric #197 which points to TLSCipherSuite https://github.com/Cybersecurity-Certification-Hub/security-metrics/blob/153-migrate-emerald-metric-aeskeylength/metrics/TransportEncryption/TlsCipherSuite/TlsCipherSuite.yaml

[lebogg]

Thinking about it, we could even split it up further. A TLS "configuration" consists of the following elements: protocol version, key exchange, authenticaiton, encryption (with algorithm, key length, block cipher, and block cipher mode), and hash. But in my opinion, this is not very useful in practice: As a user, I would have to figure out which configurations are acceptable (say TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256) and then I would have to configure multiple metrics for the cross product of all accepted configs. I think it is better to use a metric like ValidTLSConfigurations where the allowed target values are a list of the configs shown above (e.g. TLS_AES_128_GCM_SHA256) rather than putting every config option into one metric. But I am curious about other suggestions!

Related PRs:

• https://github.com/Cybersecurity-Certification-Hub/security-metrics/pull/74/files
• Add AESKeyLength metric #197 which points to TLSCipherSuite https://github.com/Cybersecurity-Certification-Hub/security-metrics/blob/153-migrate-emerald-metric-aeskeylength/metrics/TransportEncryption/TlsCipherSuite/TlsCipherSuite.yaml

@immqu and I discussed this issue. For sake of simplicity and to avoid complicated metric rules, I would also favor to check just complete cipher suties (e.g. "TLS_AES_128_GCM_SHA256") instead of splitting it up. What do you think @d-pizhuk ?

I like the idea with regex expression in rego 👍 I will add an issue to start discussion if we went to have that in the future.