Proposed Time to Respond Expectations for Security Issues

[lmbr-pip]

This is an attempt to define the Service Level Agreement (SLA)/Expectations for triaging and fixing security issues for O3DE. These SLAs are proposed as guidance to SIGs so they can prioritize resources appropriately. When SLAs are breached SIG-Security will followup with SIGs to set new ETAs. The expectation is that in future we could setup automated reporting to highlight issues at risk.

WD == Working days (defining as O3DE "business" days)

SLAs are designed to be "generous" to SIGs and acknowledge they do not have dedicated resources but volunteers. But we also want to place security at the heart of O3DE processes.

These are SLAs for disclosed public security issues, private issues should be covered by our embargo time process. We have a default max embargo time to fix of 90 days, for private issues. However embargo time is negotiated with the reporter.

Priority	Expected Time to Triage (WD)	Expected Time to Fix (WD)
Blocker	3	7 (1 Week)
Critical	7	30 ( 1 Month)
Major	14	60 ( 2 Months)
Minor	14	None

Expectations for timeline:

• Gain agreement in SIG-security
• Take to TSC
• Take to SIG of SIGs
• Gain agreement from O3DE community and push to o3de/community as standard guidance.

[lmbr-pip]

Suggestions from TSC on 06/14

• Callout this time to fix for development
• Suggestion we engage with sig-release to define a release point patching process for blocker issues (currently sig-release has a process but its not built for speed).
• Call out to time to fix is, the time after triage has occurred (issue has been accepted by SIG)

[allisaurus]

Suggestion we engage with sig-release to define a release point patching process for blocker issues (currently sig-release has a process but its not built for speed).

This needs to be nailed down before we can commit to any SLA, since "time to fix" would need to accommodate research + implementation + release (unless we define "fixed" as "merged", vs. officially released).

[lmbr-pip]

Two quick followups:

• SIG/security has no real powers, beyond bringing issues to the TSC or asking for issues to a block a release, to get things fixed. So these should be read more as best practices.
• Time to fix would be to have a patch somewhere, we only need installers/release patching for severe blockers with high risk and again we would be asking rather than telling folks this should happen. So fixed means there is a code patch, the form of that code patch is dependent on the severity of the issue, agreed by impacted parties.

[nick-l-o3de]

It'd be good to get the actual process here. Suppose a Critical comes in, what does Sig-security actually do? Emails? Documents? Issues? Then how doe sig-security get it to be fixed? Or is that the end of the responsibility of sig-security? If so, by what mechanism is it actually fixed? If there's no (even dotted) line of action between report, expectation and fix, its unlikely to be actually fixed.

[lmbr-pip]

@lawsonamzn We have a response RFC that needs to be actioned by the SIG: https://github.com/o3de/sig-security/blob/main/rfcs/rfc-sec-20220316-1.md

As is SIG/Security runs campaigns, sets expectations, but we cannot fix any and all security issues in O3DE. We will escalate with TSC where needed to ensure issues are fixed by SIGs that own code.