Extend Object Storage Controls

[mlysaght2017]

Addresses #188

• Adds 7 new control objectives with mappings
• New column to include MITRE ATT&CK TTP mappings directly
• New column to give the full service feature name
• New column to including mappings to existing controls with examples for CSA CCM

[nas-hub]

Can we consider having Control Testing Requirements as a column; These requirements will define the scope of tests which comprehensively ensures that Control is fullfilling the defined Objective.

[mlysaght2017]

We can certainly experiment, yes. Can you give a rough feel for what the hierarchy would look like from objective -> test reqs -> tests, relative to one or two of the control objectives/tests here.

[nas-hub]

Objective in general are highlevel - there may be a need for us to have a level of hierarchy where an Object maps to multiple Test Requirements and each requiremnt has multiple Tests.

[eddie-knight]

I'm wondering whether we should switch up our approach here.

Perhaps we start with a summary table that is a pared-down version of this, and then the rest of the document can contain deep-dives of each control.

Here's a quick and dirty example... I created a template very loosely inspired by CIS and threw a few rows in.

Would something like this fit with y'alls vision / experience?

@mlysaght2017 @nas-hub @jared-lambert @rowan-baker @kennydunn72

---

---

CCC.OS: Object Storage

Control Id	Service Taxonomy Id	Control
CCC.OS.C1	CCC-020115	Prevent unencrypted requests to object storage bucket
CCC.OS.C2	CCC-020114	Prevent object storage data encrypted for impact
CCC.OS.C3	CCC-020116	Prevent granting direct public access to object storage bucket

---

CCC.OS.C1: Prevent unencrypted requests to object storage bucket

Corresponding Feature: CCC-020115 (Encryption in Transit)
NIST CSF: Protect (PR.DS-2)
MITRE ATT&CK TTP: T1040 - Network Sniffing

Objective

Prevent any unencrypted HTTP requests to the object storage bucket, ensuring that all communications are encrypted in transit to protect data integrity and confidentiality.

Tests

CCC.OS.C1.01: Ensure HTTPS succeeds

• Given you own the object storage bucket
• When an encrypted HTTPS request is made to the bucket
• Then the request is allowed

CCC.OS.C1.02: Ensure HTTP fails

• Given you own the object storage bucket
• When an unencrypted HTTP request is made to the bucket
• Then the request is denied

Control Mappings

• CCM: IVS-09, DSI-03

---

CCC.OS.C2: Prevent object storage data encrypted for impact

Corresponding Feature: CCC-020114 (Encryption at Rest)
NIST CSF: Protect (PR.DS-1)
MITRE ATT&CK TTP: T1486 - Data Encrypted for Impact

Objective

Ensure that data within the object storage bucket is not encrypted with an untrusted Key Management Service (KMS) key, thereby protecting data integrity and preventing unauthorized access.

Tests

CCC.OS.C2.01: Ensure trusted KMS key succeeds

• Given you own the object storage bucket
• When a data plane request with a trusted KMS key is made to the object storage bucket
• Then the request is allowed

CCC.OS.C2.02: Ensure untrusted KMS key fails

• Given you own the object storage bucket
• When a data plane request with an untrusted KMS key is made to the object storage bucket
• Then the request is denied

Control Mappings

• CCM: DSI-01, DSI-02

---

CCC.OS.C3: Prevent granting direct public access to object storage bucket

Corresponding Feature: CCC-020116 (Identity Based Access Control)
NIST CSF: Protect (PR.AC-4)
MITRE ATT&CK TTP: T1530 - Data from Cloud Storage Object

Objective

Prevent the object storage bucket from being publicly accessible by controlling and restricting access permissions to only authorized users, thus protecting the data from unauthorized access.

Tests

CCC.OS.C3.01: Ensure privileged requests succeed

• Given you own the object storage bucket
• When a request is made from a privileged user
• Then the request is allowed

CCC.OS.C3.02: Ensure non-privileged requests fail

• Given you own the object storage bucket
• When a request is made from a non-privileged user
• Then the request is denied

Control Mappings

• CCM: IVS-07, DSI-04

[mlysaght2017]

@nas-hub @damienjburks @eddie-knight @rowan-baker - made updates to align to template and added in separate gherkin feature files for two of the controls. The test requirements map to the gherkin features and then within each test requirement/feature there are individual tests/scenarios. There are links between the testing requirement in the catalog and the corresponding feature within the gherkin files. Agree with @damienjburks that we should have the taxonomy features tagged so we can link to those as well.

[mlysaght2017]

@eddie-knight - thanks, separating out a summary table is a nice idea and one we can follow. We were going to follow through with a previous proposal to link to the gherkin tests in a separate file, but having those here in this template looks to work well - we try a mix. Remaining elements to incorporate would be the threat, high-level abstract control and possibly the high level test requirements. We can work on getting those in next.

…

On Sun 21 Jul 2024, 04:06 Eddie Knight, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In services/storage/object/controls.md <#263 (comment)> : > \ No newline at end of file +| Control Id | Objective | Test | Service Taxonomy Id | Full Service Feature Name | NIST CSF | MITRE ATT&CK TTPs | Control Mappings | +|------------|-----------|------|---------------------|---------------------------|----------|-------------------|------------------| I'm wondering whether we should switch up our approach here. Perhaps we start with a summary table that is a pared-down version of this, and then the rest of the document can contain deep-dives of each control. Here's a quick and dirty example... I created a template *very* loosely inspired by CIS and threw a few rows in. Would something like this fit with y'alls vision / experience? @mlysaght2017 <https://github.com/mlysaght2017> @nas-hub <https://github.com/nas-hub> @jared-lambert <https://github.com/jared-lambert> @rowan-baker <https://github.com/rowan-baker> ------------------------------ ------------------------------ CCC.OS: Object Storage Control Id Service Taxonomy Id Control CCC.OS.C1 CCC-020115 Prevent unencrypted requests to object storage bucket CCC.OS.C2 CCC-020114 Prevent object storage data encrypted for impact CCC.OS.C3 CCC-020116 Prevent granting direct public access to object storage bucket ------------------------------ Detailed Objectives and Tests CCC.OS.C1: Prevent unencrypted requests to object storage bucket Feature ID: CCC-020115 Feature Name: Encryption in Transit Objective Prevent any unencrypted HTTP requests to the object storage bucket, ensuring that all communications are encrypted in transit to protect data integrity and confidentiality. Tests *CCC.OS.C1.01*: Ensure HTTPS succeeds - *Given* you own the object storage bucket - *When* an encrypted HTTPS request is made to the bucket - *Then* the request is allowed *CCC.OS.C1.02*: Ensure HTTP fails - *Given* you own the object storage bucket - *When* an unencrypted HTTP request is made to the bucket - *Then* the request is denied ------------------------------ CCC.OS.C2: Prevent object storage data encrypted for impact Feature ID: CCC-020114 Feature Name: Encryption at Rest Objective Ensure that data within the object storage bucket is not encrypted with an untrusted Key Management Service (KMS) key, thereby protecting data integrity and preventing unauthorized access. Tests *CCC.OS.C2.01*: Ensure trusted KMS key succeeds - *Given* you own the object storage bucket - *When* a data plane request with a trusted KMS key is made to the object storage bucket - *Then* the request is allowed *CCC.OS.C2.02*: Ensure untrusted KMS key fails - *Given* you own the object storage bucket - *When* a data plane request with an untrusted KMS key is made to the object storage bucket - *Then* the request is denied ------------------------------ CCC.OS.C3: Prevent granting direct public access to object storage bucket Feature ID: CCC-020116 Feature Name: Identity Based Access Control Objective Prevent the object storage bucket from being publicly accessible by controlling and restricting access permissions to only authorized users, thus protecting the data from unauthorized access. Tests *CCC.OS.C3.01*: Ensure privileged requests succeed - *Given* you own the object storage bucket - *When* a request is made from a privileged user - *Then* the request is allowed *CCC.OS.C3.02*: Ensure non-privileged requests fail - *Given* you own the object storage bucket - *When* a request is made from a non-privileged user - *Then* the request is denied — Reply to this email directly, view it on GitHub <#263 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQNCXE22XPY77GR2DN3QZLZNMJSLAVCNFSM6AAAAABLCQGCTKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOJQGE4TKMJRGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nas-hub]

Yes, that looks good, the idea is that a control will require multiple tests to ensure its complete assessment and fulfillment of its objective. Parallel to that defining the expectations of assessment as "Testing Requirements" will set the scope and draw boundaries of the tests that are expected. Both above combined together will help lead towards automated assessments.

For Example:

CCC.OS.C1: Prevent unencrypted requests to object storage bucket

Corresponding Feature: CCC-020115 (Encryption in Transit)
NIST CSF: Protect (PR.DS-2)
MITRE ATT&CK TTP: T1040 - Network Sniffing Consider: T1573 - Encrypted Channels

Objective

Prevent any unencrypted requests to the object storage bucket, ensuring that all communications are encrypted in transit to protect data integrity and confidentiality.

Testing Requirements

The follow validations must be performed against corresponding Control Implementation capabilities to ensure the Control Objective is thoroughly assessed:

CCC.OS.C1.TR.01 {#CCC.OS.C1.TR.01} : All supported network data protocols must be running on secure channels.

CCC.OS.C1.TR..02 {#CCC.OS.C1.TR.02} : All clear text channels should be disabled

CCC.OS.C1.TR..03 {#CCC.OS.C1.TR.03} : The cipher suite implemented for ensuring the integrity and confidentiality of data should conform with the latest suggested cipher suites. ^{TODO: Link NIST/MITRE proposed latest standard cipher suites.}

CCC.OS.C1.TR..04 {#CCC.OS.C1.TR.04}: Add new requirement here

Tests

CCC.OS.C1.01: Ensure HTTPS succeeds

• Given you own the object storage bucket
• When an encrypted HTTPS request is made to the bucket
• Then the request is allowed

Requirements Coverage [ CCC.OS.C1.TR.01, ]

CCC.OS.C1.02: Ensure SFTP succeeds

• Given you own the object storage bucket
• When an encrypted SFTP request is made to the bucket
• Then the request is allowed

Requirements Coverage [ CCC.OS.C1.TR.01, ]

CCC.OS.C1.02: Ensure gRPC over TLS succeeds

• Given you own the object storage bucket
• When an encrypted gRPC request is made to the bucket
• Then the request is allowed

Requirements Coverage [ CCC.OS.C1.TR.01, ]

CCC.OS.C1.02: Ensure HTTP fails

• Given you own the object storage bucket
• When an HTTP request is made to the bucket
• Then the request is denied

Requirements Coverage [ CCC.OS.C1.TR.02, ]

CCC.OS.C1.02: Ensure FTP fails

• Given you own the object storage bucket
• When an FTP request is made to the bucket
• Then the request is denied

Requirements Coverage [ CCC.OS.C1.TR.02, ]

CCC.OS.C1.02: Ensure gRPC fails

• Given you own the object storage bucket
• When an unencrypted gRPC request is made to the bucket
• Then the request is denied

Requirements Coverage [ CCC.OS.C1.TR.02, ]

CCC.OS.C1.02: Ensure all known weak cipher suites are not supported

Referenced List of WEAK_CIPHERS = {ref:}

• Given you own the object storage bucket
• When an request with CIPHER: < list:WEAK_CIPHERS > made to the bucket
• Then the request must fail

Requirements Coverage [ CCC.OS.C1.TR.03, ]

[damienjburks]

I like the way this is going. I think we will want to break out the gherkin tests into their own files and tag them accordingly. We can create a tests folder in the parent directory, and move all Gherkin files into it. This'll make it easier to implement automated tests for the assessments of the controls, rather than parsing the markdown file and attempting to derive all the information from there.

Example:

@CCC.OS.C1.05
Feature: Ensure all known weak cipher suites are not supported
  Scenario: Ensure all known weak cipher suites are not supported
    GIVEN you own the object storage bucket
    WHEN an request with CIPHER: < list:WEAK_CIPHERS > made to the bucket
    THEN the request must fail

@CCC.OS.C1.04
Feature: Ensure gRPC fails
  Scenario: Ensure gRPC fails
    GIVEN you own the object storage bucket
    WHEN an unencrypted gRPC request is made to the bucket
    THEN the request is denied

If we do plan to follow this, I also think it would be ideal to include links to the headings of both the controls and the taxonomy IDs, as listed below as a brief example:

| Control Id | Taxonomy Service ID| Objective |
|------------|-----------|---|
|[CCC.OS.C1](#ccc.os.c1)|[CCC-020115](./taxonomy.md#ccc-020115)| Prevent unencrypted requests to object storage bucket|

[nas-hub]

Yes, separating gherkin in its own file sounds good. We need to ensure that there is mechanism in place for us to reference the Control Testing Requirement ID from the gherkin test file: Probably we can use a structured preamble that references the testing requirements being fulfilled by the test.

Feature: Ensure all known weak cipher suites are not supported

  """
  Requirement Ids: [CCC.OS.C1.TR.03, ]
  This feature describes the user login process.
  It includes scenarios for successful and unsuccessful login attempts.
  """

Scenario: Successful login
   Given the user is on the login page
   When the user enters their username and password
   And the user clicks the login button
   Then the user should be redirected to the home page

Key points:

• From a mapping point of view - A Test can fulfill multiple Control Testing Requirements. (N-N relationship between Test and Testing Requirement. Mapping can be maintained in gherkins file.)
• Roles and Responsibilities can also be better defined and managed. A Controls Assessment Team can be responsible for define the Controls Testing Requirements, Controls Security Engineer can be developing the gherkins. Over time the Tests will grow to improve the effectiveness of fulfilling a defined set of Controls Testing Requirements.

[eddie-knight]

I recommend merging a CODEOWNERS change in a separate PR, to make sure that the Taxonomy WG isn't errantly required as reviewers.