Impact Analysis - Follow-up investigation of Microsoft change to Sharepoint custom scripting

[ahuynhMITRE]

🐛 Summary

Microsoft is making updates to the custom scripting configuration options for Sharepoint and OneDrive. The purpose of this issue is to determine if we need to remove or revise policies MS.SHAREPOINT.4.1v1 and 4.2 based on the changes.

https://techcommunity.microsoft.com/t5/sharepoint/removing-custom-scripting-on-sharepoint-sites/m-p/4055563

Original issue #977 was closed and this issue is opened to further investigate once the change is made.

Microsoft's suggestion is to remove the policies once change has been made but will further investigate once update is available in the test tenants.

Implementation notes

• Examine the Microsoft documentation which states that the scripting configuration is going to change.
• Perform a hands-on analysis of the Sharepoint admin center for the two affected settings and document the impacts.
• Document a recommendation on whether the baseline and ScubaGear need to change.
• If changes are needed, create new issues.

[schrolla]

17 Jul 2024 - This change hasn't yet appeared to have gone into effect. Check back again in two months.

[tkol2022]

Via hands-on testing, I verified that the MS.SHAREPOINT.4.1v1 (custom scripts for personal OneDrive sites) has been removed from the MS Sharepoint admin portal so @ahuynhMITRE we should remove it from the baseline. Create a new issue for that.
There are no code impacts because ScubaGear didn't have this field in the available cmdlets - it is currently not checked.

[tkol2022]

Via hands-on testing, I verified that Microsoft changed the way that MS.SHAREPOINT.4.2v1 (custom scripts for self-service (aka Sharepoint sites) is implemented in the admin portal. This impacts our baseline and I am currently still testing this for the next few days. My interim notes are saved below.

• I changed the custom scripts for self-service sites setting in the Sharepoint classic settings admin page (per our baseline) but it had no effect on the configuration setting checked by ScubaGear. I am guessing that changing the respective value from that classic page is OBE so we might need to change the baseline instructions.
• I was able to change the custom scripts for self-service setting in Powershell using the commands below and I verified that the setting was changed by running ScubaGear so it is still possible to modify this settings via API call.

To set it to a non-compliant value use $false. For compliant use $true

set-sposite -identity https://tedstoplevelsite.sharepoint.com/ -DenyAddAndCustomizePages:$false

• Apparently there is a new place in the GUI to set the value for the custom scripts for self-service sites and that is on the Sharepoint Admin > Sites > Active Sites page. Open the top level site and click the Settings tab. There is a new option there named Custom scripts which changes the value of the setting and therefore impacts the ScubaGear policy check. I tested this.

• When you change the configuration setting to a non-compliant value in the admin portal (i.e. to allow custom scripts), the portal warns you that the setting will automatically be reverted back to Blocked within 24 hours. I set a few of the sites (including the top level site) to Allowed and I will check back on Friday to see if they get reverted back.

[tkol2022]

I set the Custom Scripts setting to Allowed at the site level for the following three sites on 7/17. According to Microsoft they were supposed be automatically reverted back to Blocked within 24 hours. As of today 7/19 only one of the sites was automatically reverted back to Blocked. I checked back again on Monday 7/22 and the the two sites listed below are still allowed (they were not reverted).

Sharepoint site name	Custom Scripts status 7/17	Custom Scripts status 7/19
Communication site	Allowed	Reverted back to Blocked
Digital Initiative Public Relations	Allowed	still Allowed
Mark 8 Project Team	Allowed	still Allowed

[tkol2022]

Update the status of #622 once we determine if we are keeping or removing Sharepoint policy 4.2. We are currently in back and forth discussions and hands-on testing with Microsoft.

[ahuynhMITRE]

After speaking with Ted to get updated on the status of this investigation following meeting with Microsoft, current suggestion by me is the following with Jellyfish not expecting to have any SCB changes due to the BOD:

• Update ScbaGear report to remove check for 4.2 and have the setting be N/A
• add notes in the details section of 4.2 report noting that the policy is expected to be decommissioned in the future.
  • sample language can be "The Custom Script setting in SharePoint is planned to be removed. The NoScriptSite setting will be configured to True for all existing sites except for specific site templates. If you change this setting for a classic team site, it will be overridden by the Custom Script setting in the admin center within 24 hours." this text was lifted from Microsoft's documentation on the change (links listed below).
  • https://learn.microsoft.com/en-us/sharepoint/allow-or-prevent-custom-script
  • https://mc.merill.net/message/MC714186
    -Future issue to be added to remove the policy from the SCB and ScubaGear set for Kraken.

Tagging in @mitchelbaker-cisa and @tkol2022 on review on the recommend next steps prior to creating a new issues.

[tkol2022]

Thank you!

• I am good with the action plan to change the Rego to produce an N/A for 4.2 as a short-term implementation.

• I am good with updating the language in the baseline. I would not put too much detail because I find the message from the website confusing and can likely confuse users. Instead I recommend just putting something like "The configuration setting that this policy was based on has been deprecated in its original form and we expect to decommission it from the baseline in the near future."

[schrolla]

@tkol2022 Is this analysis complete? There are 2 checkboxes in the implementation notes... if those are complete can this issue be closed out?

[ahuynhMITRE]

analysis complete. Follow actions are captured in #1324 and #1325