ðSecurity and Risk Management
This page summarizes our Security Documentation, Audits, Processes and Security Management Plan, which is our strategy for reducing risks and preventing and responding to incidents.
Last updated
This page summarizes our Security Documentation, Audits, Processes and Security Management Plan, which is our strategy for reducing risks and preventing and responding to incidents.
Last updated
Our security Github repository is publicly available at: https://github.com/KintoXYZ/security
It includes our Security Audits, Security Contact PGP keys, all future Public Disclosures and our soon TBA Bug Bounty Program.
Security is an essential pillar of the Kinto L2 design. Our team understands that security is an ongoing process, not an 'add-on' or review that happens once every few months. We follow a security-by-design process that includes continuous actions at the infrastructure and SDLC (Software Development Life Cycle) level. This continuous process is part of our Security Management Plan, which is our strategy for reducing risks and preventing and responding to incidents.
The following agile methodology has been defined in order to identify, address and protect the network from the most dangerous risks:
As part of the risk assessment and management process, some of the most relevant security risks are identified below. As part of the security-by-design methodology, our team has identified and implemented several countermeasures to reduce their impact and/or the probability of occurrence.
The scope of our technical security analysis includes but it is not limited to the following elements:
Nodes infrastructure
Nodes RPC providers
Arbitrum Nitro stack + Kinto Fork
Kinto-Core smart contracts
KYC/KYB providers
AML/Fraud detection providers
DDBBs
KYT providers
Autotasks secure enclaves
OpenZeppelin relayers
Bridges/Inbox/Outbox
Sequencer
Smart contract analysis providers
Kinto domains & DNS
Kinto serverless functions
Kinto websites and UI packages
Multisig strategies
Governance strategies
Threat actors
Auditors, white hackers and bug bounty programs
Most organizations run a technical security analysis at certain moments. However, we think it's important to have a continuous security analysis process. Any new change, fix or pull request is audited using a security-by-design pattern. The audit is run by a different team member and there should be a minimum of two different team members auditing any code pushed by a third team member.
Issues are categorized according to severity:
The continuous process helps us to identify problems and fix them quickly while we document the pull request that solves the issue. The fix usually includes the exploit to reproduce, validates the issue is exploitable, and includes the patch that disables the exploit.
We work with external security audit partners to review our code at different snapshots in time. These companies work closely with our internal security audit team.
We work with three different security companies for three complete audits (each audit has one to two rounds).
All partners have completed their audits, critical issues have been addressed and all published results can be found in our security repository.
After a security analysis we implemented several countermeasures, each of which are in a different stage today. This process is considered one of the most important parts of Risk Management. Security Projects are defined by different topics, each with different actions and countermeasures.
Some examples of the most relevant additional countermeasures are:
Internal (continuous) security audit (ISA) process
External security audits by different security audit firms
KintoID freezer
Reentrancy guard
Key management policy (2FA, Multisig, etc.)
Security test coverage
Pair programming
Security event management (monitoring and detection)
Cyber exercises
Incident response plan
Vulnerability management
Bug bounty planned
Need to know policy
Awareness raising
Community education
Following the standards like ISO27K and best practices, we are also identifying new proposals to implement in the future (Deming cycle).
Nearly every organization experiences cyber attacks, and unfortunately, Kinto will not be an exception. This is why we have an incident response plan that will allow us to respond more rapidly and contain an incident if/when one occurs.
As part of the incident response plan, we identify different phases, each of them with different sub-processes:
We know that 100% security does not exist, so we need to be prepared for recovery; this is why we work on containment and recovery measures that help Kinto and its users in the event of an incident.
We have implemented different mechanisms to provide monitoring and detection capabilities. Some of them are well-known, such as OpenZeppelin Defender, Turnkey, Hypernative, and IronBlocks. We also work with business partners who help Kinto improve its alerting system channels and continuous monitoring systems.
Users are a key aspect of any chain, so we have opened a support channel for our users - this has the potential to help detect hidden issues or bugs. Any new issue is validated, categorized, and prioritized to support users better.
Note: All security incidents and vulnerabilities must be reported using an encrypted email, as described in the next section below.
Our Vulnerability Management Program has two parts:
Bug bounty program (starting soon)
Vulnerability / Security Incident report intake channel (please use encrypted communications using our public PGP/encrypted communication channel)
At Kinto, we are committed to working with researchers who submit security vulnerability notifications. We will resolve issues within an appropriate timeline and perform a coordinated release, giving credit to the reporter if you prefer.
For all security-related issues, Kinto has the following main points of contact:
For complete information for disclosure please visit: https://github.com/KintoXYZ/security
We believe that crypto security will improve if we foster collaboration between the different chains, Dapps and protocols. If you're interested in sharing best practices or working together, please feel free to reach out.
OpenZeppelin Defender entries from [Advisor](https://defender.openzeppelin.com/#/advisor/doclist?).
Magoo graveyard at Github.
Thesis paper from MIT research.
Yearn finance security process: https://github.com/yearn/yearn-security, https://github.com/yearn/yearn-security/blob/master/SECURITY.md
SEI (Carnegie Mellon): https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=6305
Reference Security Incident Taxonomy Working Group. Reference Security Incident Classification Taxonomy: https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/master/working_copy/humanv1.md
ISO 22301: https://www.iso.org/standard/75106.html
| Security risk | Associated countermeasures |
|---|---|
| Severity | Description |
|---|---|
| Contact | Public key | Key ID | |
|---|---|---|---|
Step 0
Methodology: This section defines the agile methodology influenced by the ISO 27000/27001 standards for conducting Risk Assessments and risk Management and setting up an Incident Response Plan.
Step 1
Threat modeling: Threat modeling and risk identification through in-depth research about prior, L1s / L2s / DeFi security incidents.
Step 2
Technical security analysis: Identify security issues and bugs by running continuous security audits by internal and/or external staff/companies.
Step 3
Risk Assessment and Countermeasures: Identify main risks and their ideal countermeasures and remediations based on the state of play.
Step 4
Projects and initiatives and their prioritization: Define the Security Risk Management projects, their prioritization and suggest some proposals to improve (Deming Cycle).
Step 5
Approval: Get Approval
Step 6
Launch the Security Master Plan
Step 7
Launch the Incident Response Plan
Re-entrancy attacks
CI/CD, Audits, Dev. best practices
Running untested code
CI/CD, Certora live audit, Dev. best practices
Set-up malicious smartcontracts as official
Network monitoring, Official documentation
Financial attacks
Network monitoring, Partners best practices
Business logic bugs
CI/CD, Audits, Dev. best practices
Losing control/ownership of the service
IT multisig, security council, governance
3rd party attacks
Network monitoring, Provider monitoring, Access control
Private keys/credentials theft
Secure enclaves, credential rotation
Spear phishing
SSNN monitoring, emailing services, official documentation, community education
Impersonation/social engineering attacks
SSNN monitoring, emailing services, official documentation, community education
RPC Nodes attack
Multiple providers, Network monitoring, Multisig, Governance
DDoS attacks
Multiple providers, Cloudflare, Network monitoring
PII exfiltration
Audit logs, key rotations, strictly limited access, end to end encryption
PII modification
Webhook verification
Identity theft
KYC/KYB, liveness check, criminal ddbb checkups
Counterparty risk
KYC/KYB, jurisdiction monitoring, AML, fraud detection
Source of funds risk
KYT, AML, Fraud detection
Malicious smart contract deployment
Smart contract static analysis
Malicious smart contract exploits
Smart contract dynamic analysis
Critical
Critical severity issues need to be fixed as soon as possible. They can cause a drastic reduction in the balance of the system or its users without consent. They put in danger the integrity of the system and they can completely stop expected functioning. They damage and negatively impact the future of the whole system and its brand reputation. They represent high risk to the feasibility and future of the system.
High
High severity issues are problems that should be fixed. They potentially allow a reduction in the balance of the system or its users without consent. They potentially put in danger the integrity of the system or they can potentially stop expected functioning. They carry the potential to damage company brand reputation and can put the feasibility or future of the system at risk.
Medium
Medium severity issues could potentially result in problems and should be fixed when bandwidth becomes available.
Low
Low severity issues are minor details or warnings that can remain unfixed but should preferably be fixed at some point in the future.
Informative
This category is raised so all the team is aware of particular behavior of the code. This informs new discussion and potential future decisions.
To Check
This category represents pending checks identified by the security auditor to be discussed with the code author before being classified into the corresponding section. They can also be disregarded during this process.
Checked
This category represents checks already done not representing an issue (e.g., false positives or not relevant).
Security
security at kinto.xyz
4C0552D8
