Security Incident Response Plan
This document outlines specific procedures and guidelines to follow in case of a security incident.
Security Incidents
In order to activate a incident response procedure, a security incident needs to be identified. The following events or scenarios trigger this procedure.
Vulnerability in smart contract or other system component exposes user funds
Underlying bugs that affect users' ability to access funds
Third-party infrastructure flaws endanger protocol operations
Ethical hackers or active exploits confirm breach
Critical infrastructure compromised (e.g., founder keys)
These events might be alerted by internal monitoring systems or external reports.
Once the security incident is identified, the following steps need to be executed:
Communicate to all members of the Security Incident Response Team (SIRT)
Setup a War room
Evaluate the threat
Take defensive measures
Keep communication active
Fix bugs and vulnerabilities
Conduct a post-mortem
SIRT: Roles
The following roles need to be assigned to Concrete team members who will be involved in the security incident response plan :
Coordination
The Coordination role(s) will be responsible for overseeing this plan and ensuring that it is executed accordingly and that all team members are aware of their roles and responsibilities. They will also monitor the progress of the remediation efforts, identifying any potential obstacles or issues that may arise and taking corrective action as necessary.
Tech Lead
The Tech Lead role will play a crucial role in the incident response process by providing technical expertise and assistance in identifying the root cause of the issue. As part of the incident response team, the Core Devs will collaborate with the coordinator and the Smart Contract Lead to develop a remediation plan that addresses the underlying issue.
Community manager
The Community Managers will be ensuring that the organization's community is informed and engaged throughout the incident response process. As part of the incident response team, the Community Manager will be responsible for communicating, addressing any concerns or questions the community may have, and providing regular updates on the status of the incident and the progress of the remediation efforts.
War Room
Open the private chat room in Jitsi, ensure the audio and video are working. Invite only the team members who are available or who can fulfill the roles mentioned above. The War Room is only for those who are assigned to specific roles no one else should enter while problems are being fixed.
All the information that is gathered during the War Room should be documented by a technical lead for internal records.
Threat Evaluation:
Confirm evidence of bug/vulnerability.
Assess impact on users' funds and protocol components.
Determine immediate actions to mitigate losses.
Investigate root cause(s) of exploits.
Defensive Measures
Pause smart contracts
Update UI with security information
Communications
Transparent, reliable, and consistent communication with users.
Avoid unverified information or premature promises.
Utilize appropriate channels (Discord, Telegram, Twitter).
Provide regular updates, even if no new information is available.
Fix bugs and vulnerabilities
Brainstorm solutions based on root cause analysis.
Evaluate solutions based on complexity, timeline, and user impact
Once the issue has been confirmed we will turn on the parts of the protocol that can be operating as normal
Test patches
Review patch with security auditors
Implement solution using pre-assigned deployment scripts and multisig wallets
Post-Mortem:
Analyze incident, identify additional root causes, and share feedback
Gather information for vulnerability disclosure statement
Demonstrate commitment to security and user protection
Upon mutual agreement among the team, the coordinator will initiate the process of dismantling the War Room.
Last updated