From b9b209d545714f0d092b88615fd2d0eff4776c46 Mon Sep 17 00:00:00 2001 From: JosepBove Date: Sun, 6 Apr 2025 19:00:32 +0200 Subject: [PATCH 1/2] start stage 1 fma draft --- security/fma-stage-1.md | 106 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 security/fma-stage-1.md diff --git a/security/fma-stage-1.md b/security/fma-stage-1.md new file mode 100644 index 00000000..693c8894 --- /dev/null +++ b/security/fma-stage-1.md @@ -0,0 +1,106 @@ +# [Project Name]: Failure Modes and Recovery Path Analysis + + + + +- [Introduction](#introduction) +- [Failure Modes and Recovery Paths](#failure-modes-and-recovery-paths) + - [[Name of Failure Mode 1]](#name-of-failure-mode-1) + - [[Name of Failure Mode 2]](#name-of-failure-mode-2) +- [Audit Requirements](#audit-requirements) +- [Action Items](#action-items) +- [Appendix](#appendix) + - [Appendix A: This is a Placeholder Title](#appendix-a-this-is-a-placeholder-title) + + + +_Italics are used to indicate things that need to be replaced._ + +| | | +| ------------------ | -------------------------------------------------- | +| Author | JosepBove | +| Created at | 2025-04-06 | +| Initial Reviewers | | +| Need Approval From | | +| Status | Draft | + +> [!NOTE] +> ๐Ÿ“ข Remember: +> +> - The single approver in the โ€œNeed Approval Fromโ€ must be from the Security team. +> - Maintain the โ€œStatusโ€ property accordingly. An FMA document can have the following statuses: +> - **Draft ๐Ÿ“:** Doc is created but not yet ready for review. +> - **In Review ๐Ÿ”Ž:** Security is reviewing, and Engineering is iterating on the design. A checklist of action items will be created during this phase. +> - **Implementing Actions ๐Ÿ›ซ:** Security has signed off on the content of the document, including the resulting action items. Engineering is responsible for implementing the action items, and updating the checklist. +> - **Final ๐Ÿ‘:** Security will transition the status of the document to Final once all action items are completed. + +> [!TIP] +> Guidelines for writing a good analysis, and what the reviewer will look for: +> +> - Show your work: Include steps and tools for each conclusion. +> - Completeness of risks considered. +> - Include both implementation and operational failure modes +> - Provide references to support the reviewer. +> - The size of the document will likely be proportional to the project's complexity. +> - The ultimate goal of this document is to identify action items to improve the security of the project. The FMA review process can be accelerated by proactively identifying action items during the writing process. + +## Introduction + +This document covers _[project name, high-level summary of the project, and scope of this analysis]._ + +Below are references for this project: + +- _Link 1, e.g. project charter or design doc_ +- _Link 2, etc._ + +## Failure Modes and Recovery Paths + +**_Use one sub-header per failure mode, so the full set of failure modes is easily scannable from the table of contents._** + +### FM1: [Name of Failure Mode 1] + +- **Description:** _Details of the failure mode go here. What the causes and effects of this failure?_ +- **Risk Assessment:** _Simple low/medium/high rating of impact (severity) + likelihood._ +- **Mitigations:** _What mechanisms are in place, or what should we add, to:_ + 1. _reduce the chance of this occurring?_ + 2. _reduce the impact of this occurring?_ +- **Detection:** _How do we detect if this occurs?_ +- **Recovery Path(s)**: _How do we resolve this? Is it a simple, quick recovery or a big effort? Would recovery require a governance vote or a hard fork?_ + +### FM2: [Name of Failure Mode 2] + +- **Description:** _Details of the failure mode go here. What the causes and effects of this failure?_ +- **Risk Assessment:** _Simple low/medium/high rating of impact (severity) + likelihood._ + **Mitigations:** _What mechanisms are in place, or what should we add, to:_ + 1. _reduce the chance of this occurring?_ + 2. _reduce the impact of this occurring?_ +- **Detection:** _How do we detect if this occurs?_ +- **Recovery Path(s)**: _How do we resolve this? Is it a simple, quick recovery or a big effort? Would recovery require a governance vote or a hard fork?_ + +### Generic items we need to take into account: + +See [generic hardfork failure modes](./fma-generic-hardfork.md) and [generic smart contract failure modes](./fma-generic-contracts.md). +Incorporate any applicable failure modes with FMA-specific mitigations and detections directly into this document. + +- [ ] Check this box to confirm that these items have been considered and updated if necessary. + +## Action Items + +Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from: + +- [ ] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author) +- [ ] _Action item 2 (Assignee: tag assignee)_ +- [ ] _Action item 3 (Assignee: tag assignee)_ + +## Audit Requirements + +_Given the failure modes and action items, will this project require an audit? See [FMAs in the SDLC](https://github.com/ethereum-optimism/pm/blob/main/src/fmas.md#determine-audit-requirements) for a reference decision making framework. Please explain your reasoning._ + +## Appendix + +### Appendix A: This is a Placeholder Title + +_Appendices must include any additional relevant info, processes, or documentation that is relevant for verifying and reproducing the above info. Examples:_ + +- _If you used certain tools, specify their versions or commit hashes._ +- _If you followed some process/procedure, document the steps in that process or link to somewhere that process is defined._ From 77de1990c03fe9312b1aab92d52ebcb3b61f431b Mon Sep 17 00:00:00 2001 From: JosepBove Date: Sun, 6 Apr 2025 19:06:08 +0200 Subject: [PATCH 2/2] clean template --- security/fma-stage-1.md | 41 ++++------------------------------------- 1 file changed, 4 insertions(+), 37 deletions(-) diff --git a/security/fma-stage-1.md b/security/fma-stage-1.md index 693c8894..edb21b82 100644 --- a/security/fma-stage-1.md +++ b/security/fma-stage-1.md @@ -14,8 +14,6 @@ -_Italics are used to indicate things that need to be replaced._ - | | | | ------------------ | -------------------------------------------------- | | Author | JosepBove | @@ -24,39 +22,18 @@ _Italics are used to indicate things that need to be replaced._ | Need Approval From | | | Status | Draft | -> [!NOTE] -> ๐Ÿ“ข Remember: -> -> - The single approver in the โ€œNeed Approval Fromโ€ must be from the Security team. -> - Maintain the โ€œStatusโ€ property accordingly. An FMA document can have the following statuses: -> - **Draft ๐Ÿ“:** Doc is created but not yet ready for review. -> - **In Review ๐Ÿ”Ž:** Security is reviewing, and Engineering is iterating on the design. A checklist of action items will be created during this phase. -> - **Implementing Actions ๐Ÿ›ซ:** Security has signed off on the content of the document, including the resulting action items. Engineering is responsible for implementing the action items, and updating the checklist. -> - **Final ๐Ÿ‘:** Security will transition the status of the document to Final once all action items are completed. - -> [!TIP] -> Guidelines for writing a good analysis, and what the reviewer will look for: -> -> - Show your work: Include steps and tools for each conclusion. -> - Completeness of risks considered. -> - Include both implementation and operational failure modes -> - Provide references to support the reviewer. -> - The size of the document will likely be proportional to the project's complexity. -> - The ultimate goal of this document is to identify action items to improve the security of the project. The FMA review process can be accelerated by proactively identifying action items during the writing process. - ## Introduction This document covers _[project name, high-level summary of the project, and scope of this analysis]._ Below are references for this project: -- _Link 1, e.g. project charter or design doc_ -- _Link 2, etc._ +- [Design Doc](https://github.com/ethereum-optimism/design-docs/pull/202/) +- [Specs](https://github.com/ethereum-optimism/specs/pull/625) +- [Implementation](https://github.com/ethereum-optimism/optimism/pull/15174) ## Failure Modes and Recovery Paths -**_Use one sub-header per failure mode, so the full set of failure modes is easily scannable from the table of contents._** - ### FM1: [Name of Failure Mode 1] - **Description:** _Details of the failure mode go here. What the causes and effects of this failure?_ @@ -89,18 +66,8 @@ Incorporate any applicable failure modes with FMA-specific mitigations and detec Below is what needs to be done before launch to reduce the chances of the above failure modes occurring, and to ensure they can be detected and recovered from: - [ ] Resolve all comments on this document and incorporate them into the document itself (Assignee: document author) -- [ ] _Action item 2 (Assignee: tag assignee)_ -- [ ] _Action item 3 (Assignee: tag assignee)_ -## Audit Requirements -_Given the failure modes and action items, will this project require an audit? See [FMAs in the SDLC](https://github.com/ethereum-optimism/pm/blob/main/src/fmas.md#determine-audit-requirements) for a reference decision making framework. Please explain your reasoning._ +## Audit Requirements ## Appendix - -### Appendix A: This is a Placeholder Title - -_Appendices must include any additional relevant info, processes, or documentation that is relevant for verifying and reproducing the above info. Examples:_ - -- _If you used certain tools, specify their versions or commit hashes._ -- _If you followed some process/procedure, document the steps in that process or link to somewhere that process is defined._