Adjudicate "substantive changes" to the SharePoint Online Baseline Markdown

[ahuynhMITRE]

💡 Summary

This issue captures the high-level tasks required to convert the existing SHAREPOINT ONLINE Secure Configuration Baseline document to a new structure based on the existing markdown format. The updates will include reordering and regrouping of existing policy items, additional fields for each policy item, and policy changes to clarify relative to existing implementation guidance.

Motivation and context

The new baseline policy document format will provide additional clarity to readers and support better automated assessment of baseline policy items for SHAREPOINT ONLINE.

Implementation notes

In order to make the changes referenced above, the following tasks will need to be accomplished:

• CREATE and NUMBER policy group statements based on existing policy areas using updated markdown files found in Adjudicate "Structural Changes" to All Baseline Markdowns #212 and its associated branch

  • REMOVE “SHALL” and “SHOULD” language from new policy group statements
  • RENAME policy groups to cover associated policies (Naming should be descriptive vice prescriptive)
  • REGROUP baseline policies that are better orientated to the new Group Name if needed
  • CREATE short 1-2 sentence summary for each policy group

• ADD Rationale section and text for each policy
  Note: Suggested format for Rationale

  • 1st sentence: Security risk if policy is not implemented.
  • 2nd sentence: How this policy minimizes this risk.

• UPDATE policy item description to match the desired best practice and synchronize with implementation steps (e.g., setting should be 30 days or less when implementation shows setting days to <= 30)

Acceptance criteria

How do we know when this work is done?

• SHAREPOINT ONLINE baseline markdown has been updated with new policy groups and all policy items reordered into those groups
• All SHAREPOINT ONLINE baseline policy groups have been numbered
• Each SHAREPOINT ONLINE policy group contains a concise and clear 1-2 sentence summary
• Each SHAREPOINT ONLINE policy item contains a Rationale section using the suggested format
• Each SHAREPOINT ONLINE policy item has been reviewed and updated to synchronize with the implementation steps

[Sloane4]

2 Quick questions:

1. Should we have a tag or some sort of indicator for "optional steps"? This is when if a agency chooses to ignore or cannot do a specific policy that affects further policies down the line. Fore example A is not done, so they cannot do B. Or they cannot do A, so B should be done instead, but not done if A is.

2. Should we have an additional post script note in each policy that is being rolled over from the old baseline format? For example:

    MS.ONEDRIVE.2.1v1
    OneDrive Client SHALL Be Restricted to Windows for Agency-Defined Domain(s).
        •  Rationale: TODO
        •  Last modified: June 2023
    Note: Previous version 2.2

[Dylan-MITRE]

2 Quick questions:

1. Should we have a tag or some sort of indicator for "optional steps"? This is when if a agency chooses to ignore or cannot do a specific policy that affects further policies down the line. Fore example A is not done, so they cannot do B. Or they cannot do A, so B should be done instead, but not done if A is.
2. Should we have an additional post script note in each policy that is being rolled over from the old baseline format? For example:

    MS.ONEDRIVE.2.1v1
    OneDrive Client SHALL Be Restricted to Windows for Agency-Defined Domain(s).
        •  Rationale: TODO
        •  Last modified: June 2023
    Note: Previous version 2.2

My opinion:

1. I think we can add an note at the end of the policy indicate that if there is a dependency to clarify
2. Since we are starting to rewrite the baseline and giving it a v1 i think it might be okay not have that note, but i I would refer that question to @ahuynhMITRE for his input since we are trying to keep consistency throughout all docs

[ahuynhMITRE]

1. I agree with @Dylan-MITRE's notion of a note at the end of policy indicating dependencies.
2. no note at this time since this will be our v1.0; added and removed policies will have indicators going forward though!

[Sloane4]

Not the last question, but can dream. @ahuynhMITRE are you planning to have all the baseline changes in the branch 212-adjudicate-structural-changes-to-all-baseline-markdowns or make a separate branch for each baseline?

[ahuynhMITRE]

@Sloane4 I expect to merge this with main as a "starting point" for all baselines once I have gone through the errors @crutchfield has identified when testing the automation script. I expect to have the updates in today COB and will have each of the baseline POCs review for the pull request!

[Sloane4]

@tkol2022 I have updated the baseline for all the issues submitted, just need help with the rationals. Also for clarification are we still removing the should & shall language, because power bi is a current pull request without those changes. If so what is the preferred method to go about it. Thanks!

[tkol2022]

Thanks!

• The SHALL and SHOULD is to be removed only from the group introduction paragraph. So check all your section intros.
• Leave the Rationale empty. Assign a new issue to @schrolla to write the rationales.
• Also, I believe the Implementation section needs to be associated with each detailed policy. So each policy will have its own implementation section. @ahuynhMITRE can you confirm this and ensure that everybody is clear on that so we have consistency across the board.

[Sloane4]

Linking #359 for rationale

[ahuynhMITRE]

Thanks!

• The SHALL and SHOULD is to be removed only from the group introduction paragraph. So check all your section intros.
• Leave the Rationale empty. Assign a new issue to @schrolla to write the rationales.
• Also, I believe the Implementation section needs to be associated with each detailed policy. So each policy will have its own implementation section. @ahuynhMITRE can you confirm this and ensure that everybody is clear on that so we have consistency across the board.

Confirm that the current direction is to have an implementation section for each policy. This was also a note Ethan stressed as well!

[schrolla]

@ahuynhMITRE Just to tease out what exactly "an implementation for each policy" means... does that mean we have something like this:

MS.PRODUCT.1.1v1

Blah blah

Implementation

This is how we implement MS.PRODUCT.1.1v1.

MS.PRODUCT.1.2v1

Blah blah

---

Or more like how it shows now in SharePoint where we have all policies in a group and the separate Implementation section for ALL of them, but with each policy item getting its own section of the Implementation like so

---

Policies

MS.PRODUCT.1.1v1

Blah blah blah

#### MS.PRODUCT.1.2v1

Blah blah blah

#### MS.PRODUCT.1.3v1

blah blah blah

Implementation

MS.PRODUCT.1.1v1, in the Product admin center: do these things

MS.PRODUCT.1.2v1, Go to the Product settings page and do some other things

MS.PRODUCT.1.3v1, Go to the security settings and do yet more and different things here

---

Because both formats provide a separate implementation section for each policy, but are quite different in structure.

[ahuynhMITRE]

@ahuynhMITRE Just to tease out what exactly "an implementation for each policy" means... does that mean we have something like this:

MS.PRODUCT.1.1v1

Blah blah

Implementation

This is how we implement MS.PRODUCT.1.1v1.

MS.PRODUCT.1.2v1

Blah blah

Or more like how it shows now in SharePoint where we have all policies in a group and the separate Implementation section for ALL of them, but with each policy item getting its own section of the Implementation like so

Policies

MS.PRODUCT.1.1v1

Blah blah blah

#### MS.PRODUCT.1.2v1

Blah blah blah

#### MS.PRODUCT.1.3v1

blah blah blah

Implementation

MS.PRODUCT.1.1v1, in the Product admin center: do these things

MS.PRODUCT.1.2v1, Go to the Product settings page and do some other things

MS.PRODUCT.1.3v1, Go to the security settings and do yet more and different things here

Because both formats provide a separate implementation section for each policy, but are quite different in structure.

Good point on the clarification @schrolla! I am inclined to lean towards how is is shown in SharePoint with a single implementation section per group with distinct steps for each policy. Though this comes my bias that this will be easier when separating out the steps into the wiki / limit the human errors with cutting and reformatting if the steps are spread throughout the bodies of policies. Any preferences from anyone else?

[schrolla]

The single implementation section was my preference as well. I just wanted to make sure that's what we were talking about as its less disruptive to overall baseline development and flows better for the reader, in my opinion.

[tkol2022]

Single implementation section sounds good. @ahuynhMITRE let the authors know to follow this standard so we can wrap up those implementation sections.

[ahuynhMITRE]

I will type it up as a "style guide" and add the details to @Dylan-MITRE's issue #361 and tag all of the authors for awareness! I will also dictate section ordering as well to address @schrolla's issue #371

[ahuynhMITRE]

closed