From 8778ff0f013d60d314439344dad64072deec3294 Mon Sep 17 00:00:00 2001 From: amanwithwings <68982632+amanwithwings@users.noreply.github.com> Date: Sat, 21 Dec 2024 00:37:07 +0530 Subject: [PATCH] Update daoip-8.md --- DAOIPs/daoip-8.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DAOIPs/daoip-8.md b/DAOIPs/daoip-8.md index 8a8d5e4..9c371c5 100644 --- a/DAOIPs/daoip-8.md +++ b/DAOIPs/daoip-8.md @@ -56,7 +56,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL | Ownership of assets | `[MANDATORY]` The DAO should make public a list of all assets it owns and controls. The list could include crypto tokens, ENS names and other naming services, dApps, frontends, physical assets, etc. | | Self defense, incident response, auditing, and vulnerability management |It is imperative to have a course of action or otherwise defensive capability for responding to security incidents and events which pose a risk to the core operations of a DAO or it's technical assets. This includes things such as CVE remediation, DNS hijacking/infrastructure compromise, KPI definitions for security event monitoring and response. The intention here is to prompt the creation of a plan - no critical details of the incident response plan need to be public. A template for inspiration is available [here](https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf) (not Web3/DAO specific). While there are many overlapping security considerations with Web2 practices, it is important to take DAO specific concerns into account. Additionally, it is necessary to also consider proactive controls for things such as MFA requirements, IAM best practices and regular reviews/audits of permissions for developers or technical contributors.

1. `[MANDATORY]` The DAO must publish a self-defense and emergency management plan.

2. `[RECOMMENDED]` The DAO should publish a vulnerability management plan. Sample [template](https://frsecure.com/vulnerability-management-policy-template/) (not Web3/DAO specific). | | Vendor/service provider management Policy | 1. `[MANDATORY]` The DAO should publish a list of vendors/service providers it relies upon.

2. `[RECOMMENDED]` The DAO should publish a vendor management policy. [Inspiration here](https://frameworks.securityalliance.org/external-security-reviews/vendor-selection.html).

*Vendors include all 3rd party service providers that provide a good or service to the DAO, including software services that are not paid by the DAO, but used for operations, governance or other avenues*.| -| Proposal safety | `[RECOMMENDED]` It is recommended to:

| +| Proposal safety | `[RECOMMENDED]` It is recommended to:

| | Physical security training | `[MANDATORY]` The DAO should publish a physical security recommendation and provide training to combat wrench attacks.

The DAO is recommended to focus on educational content that describes measures to be taken by key delegates, multisig signers, members of the foundation, and other important stakeholders to ensure security while traveling to conferences and other events. Inspiration taken from [here](https://github.com/OffcierCia/Crypto-OpSec-SelfGuard-RoadMap). Key recommendations could include the following:

| | Community management | `[MANDATORY]` The DAO should follow secure community management processes, to secure community accounts on Twitter, Discord, Telegram, and other applications. This section is intended to be a companion to the incident response and emergency management recommendations. For example, a defined process for responding to and remediating a compromised social media account. Template [here](https://frameworks.securityalliance.org/community-management/index.html). | | Compliance | `[MANDATORY]` The DAO must keep a record of its compliance efforts, including policies, procedures, and audit results. It should make its best efforts to comply with the regulatory frameworks applicable to its areas of incorporation.

Note that regardless of DAO jurisdiction or its regulatory standing, assets such as websites, frontends, forums, etc. can be subject to various data privacy laws. It is recommended to make a concerted effort to adhere to regulatory obligations to prevent future burdens or headaches such as “DSARs” and “Right to be forgotten” requests.|