Security

How Does Dfns handle key management?

Dfns emerged from the realization that blockchains have introduced an irreversible risk of losing digital assets without recourse. Our security thesis is grounded in the recognition that human errors are inevitable, and people and businesses will continue to face daily key loss. Therefore, to drive blockchain adoption and reap their incredible benefits, blockchains must not overly penalize human behavior. In light of this, Dfns embarked on a mission to simplify blockchain key management, allowing developers and users to interact with digital assets confidently. We serve as a safety layer, offering an error margin and protection against irreparable mistakes. Our goal is to shield individuals from themselves without inadvertently creating new threats within our own solution. In essence, Dfns’s security philosophy and mission revolve around safeguarding the blockchain economy, making it accessible, user-friendly, and reliable, while addressing the inherent challenges and risks posed by human actions.

Security is complex, hence we believe it is best for people to not carry keys on wearable hardware like phones. Private keys are sensitive material, and as such, they must be stored within specialized and secure environments. These environments must provide comprehensive protection, incorporating robust countermeasures against a wide array of potential disaster scenarios and risk vectors. This understanding has led us to rethink the traditional notions of digital asset ownership, setting us apart from the historical cypherpunk movements that birthed crypto. We have a different take on key management, which goes against the "not your keys, not your coins" dogma. Instead, we believe asset owners should remain involved in approving asset movements, but without the burden of safeguarding the private keys. 

To address this dilemma, Dfns has implemented a thoughtful separation between key security and governance. From a security perspective, we have opted to distribute the management of private keys to ensure that no single entity can gain control over them. The responsibility for safeguarding private keys lies with a network of rigorously screened, secure, and compliant participants. These participants are motivated to protect the keys and authorize transactions at the request of asset owners. Importantly, these participants cannot unilaterally compromise the network or defy asset owner requests. To achieve this, we utilize Multi-Party Computation (MPC) to generate five partial keys. These keys are stored in isolated instances within Tier 3+/4 data centers spread across different availability regions. Additionally, we employ the Threshold Signature Scheme (TSS) to ensure that three out of the five partial keys are necessary for conducting business operations, including creating wallets and signing transactions. Continuously enhancing the system's robustness and its neutrality and availability, we regularly integrate independent third-party partners into our infrastructure.

These partners encompass private cloud providers, electric utilities, insurance companies, telcos, and more. It is this meticulous design scheme that prevents Dfns from succumbing to the $74 million hack Fireblocks experienced in 2021 as they prefer letting clients secure keys on their own. 

Note that Dfns adheres to this steadfast security model with one notable exception: this exemption comes into play exclusively when our enterprise-grade clients, possessing a well-demonstrated track record of internal compliance and security acumen, expressly solicit custom key deployment schemes including on-prem storage of private keys and/or editable threshold parameters. In such instances, we extend our support to facilitate the secure retention of keys, be it in whole or in part, as per their specific requirements.

From a governance perspective, we have opted to provide clients with a distinct signing authority through the API, rather than directly exposing the private key. To access the private keys, clients or users need to interact with Dfns's secure API using passkey-based authentication credentials. This system maintains control over the key management network, responsible for protecting these private keys. We have integrated passwordless login procedures using advanced WebAuthn/FIDO2 technology, which offers various options tailored to specific requirements. These alternatives cater to both end-users, such as facial scans and PIN codes, and institutional needs, encompassing TouchID and Yubikey. This comprehensive strategy not only improves user experience but also strengthens security, thereby simplifying the Web3 onboarding process for individual users or employee-used applications. By utilizing the API credentials as signing keys for day-to-day activities and abstracting the private key, we ensure that our clients (or their clients) retain ownership of their assets.

This methodology creates a dual-layered safety net against key loss, substantially enhancing the overall management of digital assets. The concept here is clear: what is more manageable becomes more secure. In simpler terms, losing credentials no longer equates to losing the private keys. Furthermore, the system permits the generation of multiple API credentials and/or passcodes, ensuring uninterrupted business operations. Lastly, Dfns’s model transforms the API passkey into proof of custodianship, granting complete access, control, and ownership over signing processes and asset transfers. Organizations and applications now have the flexibility to choose whether they want to retain the API passkeys on-site ("custodial wallets" or "developer-controlled wallets") or delegate control, enabling end-users' devices to generate passkeys. This delegation exempts them from any custodial responsibility ("self-custodial wallets," "non-custodial wallets," or "user-controlled wallets").

‍

Where are the key shares stored?

Key shares are stored on a per-organization basis leading to variable approaches.

In our standard key management network, the key material is securely stored within isolated cloud-based Trusted Execution Environments (such as AWS Nitro Enclaves, GCP Confidential VMs, and other instances). These secure enclaves are situated in T4/3+ data centers distributed across various geographical regions either through Dfns hosting or by external partners in countries like the US, Canada, France, Germany, UK, Switzerland, UAE, and more.

For enterprise-level clients seeking top-tier solutions, we also provide customized key deployment schemes requiring on-prem key storage either within proprietary facilities using bare-metal or in dedicated cloud environments.

Cloud-based
AWS Nitro Enclaves

‍
‍On which hardware does Dfns's KMS store key shares?

Dfns employs a diverse range of hardware configurations, including Graviton3, AMD, ARM architectures, and other specialized Hardware Security Modules (HSMs) as demanded by our clientele of enterprise-caliber, such as the exemplary Luna Network HSM.

‍

Can I choose where to store the key shares?

To utilize on-prem key deployments, customers need to subscribe to our Enterprise Plan. They must either comply with Dfns's established security configuration guidelines or provide specific instructions that Dfns considers equivalent to the standard security setup. The possibility of on-prem key storage is not offered to other customers. This approach is adopted to protect our customers from possible drawbacks and to maintain Dfns's reputation. Unforeseen incidents or disasters resulting from non-standard security implementations could have negative outcomes.

Contact
For more information on our security instructions, please contact us at sales@dfns.co

‍

Can Dfns steal or misuse the key shares?

No individual engineer possesses exclusive access to an enclave. Access is provided only once – during the execution of the doomsday recovery process. In this scenario, multiple anonymous parties collaborate under the directives of an appointed Judge, should a disaster hinder the proper operations of Dfns.

Furthermore, it is important to note that the theft of a single key share does not give access to the wallet's funds. To achieve that level of access, a minimum of 3 out of 5 key shares (known as the "threshold") would be required. This essentially implies that a collusion involving 3 root engineers from 3 distinct organizations would be necessary for any significant damage to occur. Furthermore, this internal breach would need to be executed simultaneously or, at the very least, expeditiously, as the attack carries the risk of triggering a key share refresh. This refresh effectively shifts the "epoch" of the keys, rendering those generated before the refresh incompatible with those generated after it. Consequently, attackers would be constrained to coordinate their efforts within a limited timeframe.

Regarding the misuse of key shares: despite the presence of audited procedures, there remains a well-defined and closely monitored risk. Nevertheless, the misuse of a single key share does not have a significant impact on the funds themselves. Dfns's Key Management System (KMS) is equipped to rectify such situations through key share repairs, refreshes, or as a last resort, a complete rotation. While the latter option may be more disruptive to our clients' operations due to changes in public keys and addresses, it guarantees the overall security of the wallet. Note that for any financially damaging consequences to unfold, Dfns and its partners would need to collectively misuse a minimum of 3 out of 5 key shares, which is an extremely unlikely risk.

‍

How does Dfns guarantee I am in control of my assets?

Dfns is a tech service provider focused on creating secure software tailored to our clients' needs. Our top security priority is to eliminate weaknesses and prevent disruptions to client operations. This is achieved through a dual approach: defense in-depth and zero-trust security. Defense in-depth is a comprehensive security paradigm characterized by the implementation of multiple tiers of security measures, while Zero Trust Security is an operating model that focuses on continuous validation of every entity seeking access to resources. These two strategies together work synergistically in the establishment of a resilient defense framework. While defense in-depth orchestrates a range of protective layers, zero trust counters any unauthorized access through rigorous authentication protocols, thus collectively mitigating a wide spectrum of potential risks. This fusion proves highly adaptive in the face of evolving threats, consequently stopping the potential leakages and waterfall effects of vulnerabilities.

In practical terms, substantial efforts are invested in several key areas:

• Developing and enhancing passkey-based security empowering users to create unique, personal on-device credentials granting exclusive access to their wallet.
• Incorporating and leveraging MPC protocols to decentralize private keys and eradicate vulnerable single points of failure.
• Implementing and harnessing tamper-proof hardware alongside public key cryptography for all critical components integrated within the Dfns system.
• Introducing alerting and monitoring tools, in addition to audit logs that undergo client verification.
• Integrating break-the-glass access protocols into both the disaster recovery plan (DRP) and the incident response plan (IRP).

Nonetheless, it's important to acknowledge that the execution of these strategies is at times more challenging than what words can convey. Candidly, we also acknowledge that there are still several outstanding product features on Dfns’s security roadmap.

‍

Does Dfns provide custodial or non-custodial wallets?

To better understand the distinctions, it's essential to differentiate between key management providers and custodians. The former offers technology solutions, while the latter delivers qualified financial services. Dfns specializes in developing enabling technology for digital assets, focusing on technology rather than financial servicing or asset management.

When it comes to key management solutions, it's important to shift the focus from simplistic custodial categories (such as custodial, self-custodial, co-custodial) and instead consider their value proposition, design, and implementation for classification. Relying solely on oversimplified categories can lead to misunderstandings, as it requires thorough architectural assessments and precise legal definitions beyond what's easily accessible online.

In the context of Dfns, the qualification of custodial and non-custodial wallets varies based on one's perspective. By default, Dfns makes non-custodial wallets where clients maintain complete control over their private keys and digital assets. Yet, from the client's viewpoint, especially those functioning as custodians, Dfns enables the creation of custodial wallets, also known as "developer-controlled wallets." Additionally, Dfns caters to clients who prefer acting as pass-through applications offering non-custodial wallets, also known as "user-controlled wallets", and allowing end-users to retain control over their private keys and assets without involving any third-party custodian or intermediary platform between the user and Dfns. In summary, Dfns is a composable key management solution that provides a range of wallet options spanning from non-custodial wallets for end-users to custodial wallets for custodians.

Last, it's important to recognize that the terms "custodial" and "non-custodial" are used technically here, but their interpretation can vary in regulatory and contractual contexts. To fully grasp these nuances, the expertise of a legal professional or attorney is crucial. The legal perspective delves into contract-specific and jurisdictional considerations, demanding a thorough evaluation for accurate understanding and compliance.

Dfns is dedicated to ensuring adequacy and strives to ensure the usability of its solutions without encountering regulatory obstacles. To achieve this, Dfns has procured two legal assessments from prominent regulatory law firms in France, namely Kramer Levin and Arao Avocats. Additionally, a comprehensive evaluation covering all US states has been obtained from Kenwick.

Contact
If you're interested in accessing these resources, reach out to sales@dfns.co

‍

Does Dfns provide cold or hot wallets?

Dfns offers hot MPC wallets, which differ significantly from typical hot wallets like Metamask for instance. The usual categorization of cold vs. hot wallets can be misleading. Dfns's hot wallets utilize cutting-edge Multi-Party Computation (MPC) technology, ensuring strong security even for hot wallets. This challenges the conventional notion that hot wallets are less secure.
In fact, Dfns's hot MPC wallets provide security comparable to or even exceeding cold wallets.

‍

What issues related to private keys does Dfns eliminate?

• Security Vulnerabilities: Blockchain-based apps often rely on private keys for both user authentication and transaction approvals. This approach is vulnerable to security breaches, as private keys can be compromised through various methods like hacking, phishing, or malware attacks. Dfns utilizes advanced cryptography and MFA to enhance security, significantly increasing the barriers to impersonation and unauthorized access.
• Single Points of Failure: With public blockchains, losing or having a private key stolen means permanently losing access to associated digital assets. Dfns tackles this risk by leveraging decentralized key management and distributing key shares across multiple secure locations. This eliminates the single point of failure seen in hardware-first KMS.
• Usability Challenges: Managing private keys can be complex and daunting for many application developers. Dfns simplifies this process by seamlessly integrating developer-friendly APIs and straightforward key recovery mechanisms. This developer-centric approach improves the accessibility and adoption of blockchains.
• Lack of Flexibility: Traditional private key solutions in blockchain offer limited flexibility in terms of access control and permissions. Dfns introduces a dynamic access control model, allowing for granular authorizations. This empowers developers to grant specific permissions to different entities without exposing their private keys.
• Regulatory Compliance: Adhering to regulatory standards often requires secure and auditable key management practices. Dfns offers features that facilitate compliance with regulations by providing transparent and traceable key management processes.

Dfns effectively addresses these challenges associated with private keys by implementing innovative cryptography, decentralized key management, developer-friendly APIs, dynamic access controls, and compliance-first features. This global effort ensures a wallet-as-a-service platform that is not only more secure and developer-friendly, but also highly modular.

Does Dfns backup keys?

Yes. Dfns employs a sophisticated key management network that incorporates several layers of key backups. These layers serve specific purposes, including facilitating client migration, ensuring disaster recovery readiness, and more.

However, it's important to note that Dfns entrusts its clients with the responsibility of supervising the passkey credentials of their employees and/or users. These credentials are crucial for gaining access to the Dfns Key Management System (KMS) through the API.

‍

How does passkey recovery work with Dfns?

Dfns offers clients two main choices for regaining access to their passkeys. The initial option entails utilizing additional passkey credentials, while the second relies on passcodes. These approaches follow the highest security standards and require a minimum of two-factor authentication (2FA) for operation. Nevertheless, clients can bolster security by incorporating extra verification measures beyond Dfns's standard recovery procedures.

Importantly, it's worth noting that Dfns can accommodate specific demands for passkey recovery from clients subscribed to the Enterprise Plan.

‍

Can I add KYC to passkey recovery?

Dfns operates as a key management solution distinct from a custodial service, so our platform does not incorporate KYC procedures inherently. Nevertheless, certain clients choose to implement KYC protocols independently to onboard their users, establishing their individual KYC associations. When collaborating with a KYC vendor, these clients ensure that the vendor only verifies user identities, without any access to wallets.

For Enterprise Plan clients, Dfns offers the option to integrate any KYC provider into our API. This integration aims to elevate security measures and optimize the developer experience.

‍

How does Disaster Recovery (DR) work with Dfns?

Disclaimer:
We are unable to disclose all specific details of our disaster recovery plan (DRP) publicly due to security concerns. Our DRP is accessible to clients upon request. Below is a concise overview of our DRP.

Dfns's disaster recovery plan has the following objectives:

• Prevent unauthorized access to client keys.
• Prevent malicious use of client keys for signing messages.
• Ensure clients can still use their keys for signing messages.‍

‍

To achieve this, our DRP is designed as a five-tier protocol inspired by ICANN and IANA principles, enabling clients to recover assets in various levels of critical situations:

1. Layer 1 - Failover and Recovery:

• 🔧 Key share repair:
  If one private key share is compromised, other signers can restore or replace it without affecting the public key.

• ⏱️ Key share refresh:
  To counter regular compromises, signers can automatically generate new private key shares, preventing attackers from amassing enough shares.

‍‍

• 🔄 Key share rotation:
  In the worst case of full compromise, all signers can securely replace compromised key pairs, although this changes the public key.

‍

2. Layer 2 - Cloud-Managed Recovery:

1. Key shares are duplicated on an encrypted database within a secure cloud environment managed by the key hosting partner.

‍

3. Layer 3 - Local Self-Managed Recovery:

1. Key shares are re-duplicated on an encrypted database within an offline HSM (Hardware Security Module) of the key hosting partner.
2. Unlike L2, manual movement of key shares into the database is required via scripts.

‍

4. Layer 4 - Organization-Specific Recovery:

1. Clients under the Enterprise Plan can use key shares to eject themselves and retain cryptographic key material for wallets.
2. Access to this recovery layer requires an encryption key split between Dfns, the Client, and a Trusted Third-Party.

‍

5. Layer 5 - Doomsday Recovery:

1. Designed for catastrophic failures, this layer involves sharded backup keys shared among trusted parties like law firms, notarial agencies, and banks.
2. Parties remain anonymous and must be notified by a Judge in extreme cases of prolonged communication loss or major disasters.

‍
Important to note that Dfns backs up various data types alongside key shares:

• Encryption keys for key shares
• Authentication encryption keys
• Authentication signing key (public key)
• Authentication database
• Node coordinator database
• Permissions database

Contact
‍security@dfns.co for further information.

‍Has Dfns’s Disaster Recovery Plan already been tested?

Dfns conducts multiple Disaster Recovery Drills per year. The initial drill happened in February 2023 and was successful, with meticulous execution of the planned actions, leading to a swift recovery within less than an hour. The upcoming drill is scheduled for November 2023.

Have security controls or key backups ever failed?

No, not to date.

Is Dfns insured against cyber hacks? 

Yes, Dfns is insured for D&O and cybersecurity risks by AXA Insurance and Liberty Insurance.
Also, if you are interested in acquiring crime insurance, we can connect you to multiple brokers we work with on a regular basis. Dfns qualifies for coverage of up to 30 million dollars.

Contact
For more information, reach out to sales@dfns.co

Is Dfns insured against financial loss?

No, currently we have not identified insurance agreements for digital assets that offer substantial value in cases where clients commit errors and experience fund loss. Typically, such insurance is procured by the custodian (i.e. Dfns’s client) rather than the KMS (i.e. Dfns). 

Also, we highly recommend carefully reviewing terms of insurance agreements and exercising caution. This is crucial as certain wallet providers in the industry often publicly claim substantial coverage against financial losses. Yet, they frequently fail to deliver satisfactory solutions when faced with issues.

Can WebAuthn trigger a tamper-proof system dialog?

Yes. Currently, the system dialog operates exclusively through this method. The browser, rather than the application, governs this dialog. Yet, the scope of information that can be presented is restricted to domain-specific details (such as origin and rpid). Regrettably, there is no method available to exhibit the hash or a comprehensible rendition of the message while maintaining security. We are actively considering this issue internally and aspire to find a resolution in a forthcoming release.

Has Dfns’s code already been audited?

Code audits have been conducted multiple times. In 2022, Distrust undertook a comprehensive assessment of Dfns’s general security architecture. Kudelski Security meticulously reviewed Dfns's cryptographic protocol design and implementations both in 2022 and 2023.

Contact
Contact security@dfns.co to access the reports.

‍

Has Dfns’s product already been pentested?

Yes, several times. Yogosha ran two API-related pentests in 2021 and 2022, and [redacted] performed another, more comprehensive API and authentication-related one in 2023. Additional read team exercises are currently being conducted with Halborn and Cat Labs across 2023.

Contact
Contact security@dfns.co to access the reports.

‍

Is there a bug bounty program offered by Dfns?

No, not at the moment. However, we are planning to launch our bug bounty program early 2024.

‍

Has Dfns undergone any financial audits?

Dfns undergoes an annual financial audit conducted by RSM. The audit is then submitted for approval to a board comprising five directors: two founders, two investors, and one independent member. Additionally, multiple observers are also present during this process.

Has Dfns implemented internal controls?

Yes, we follow industry-leading practices that are in line with the principles of our certifications, such as SOC 2 Type 1 and 2, which are annually audited by Deloitte. These certifications encompass over 200 specific controls, guaranteeing the security and reliability of our processes.

‍

Who holds root access in Dfns and other key hosting partners?

Dfns and our key hosting partners maintain single accounts with root privileges on our different cloud environments. The accounts are established with randomly generated passwords, which are securely stored, and also possess Yubikeys, kept in distinct accounts. These accounts are exclusively utilized for emergency situations, and any activity associated with them prompts an alert in our Security Information and Event Management (SIEM) system. Additionally, we have two users authorized to attain admin-level permissions for our cloud accounts. Both these users are mandated to acquire just-in-time credentials, which are approved by different parties.

‍

How is the AWS root admin account secured with IAM policies?

We implement a multi-layered approach. The root access is limited to a single individual, who doesn't possess all security credentials. Additionally, a second person's involvement is mandated, requiring Multi-Factor Authentication (MFA). All access is meticulously recorded, both within our audit system and through notifications sent to a group via messaging platforms.

‍

What is Dfns’s IAM policy tampering detection time and response protocol?

We thoroughly examine each instance of root access upon receiving notifications. This involves directly verifying with the individual possessing root access. Additionally, we conduct weekly random reviews of the audit logs.

‍

Does Dfns have official security policies?

You can obtain a copy of our information security policy by making a request and receiving approval through a Non-Disclosure Agreement (NDA). This document undergoes an annual review and receives approval from our management team. Additionally, we can provide our SOC 2 Type 1 and 2 reports, offering a summary of the controls outlined in our security policy.

Contact
For more information, please contact sales@dfns.co

Are Dfns’s audit logs tamper-proof?

Yes, AWS CloudTrail logs are intentionally immutable, meaning they cannot be altered. AWS CloudTrail logs are made immutable through cryptographic hashing and secure storage. When an event occurs, CloudTrail generates a log entry with event details, timestamp, and metadata. This entry is stored securely with a unique cryptographic hash, acting as a digital fingerprint. Any alteration would change the hash, instantly flagging tampering. Strict access controls and limited administrator access further enhance security. This multi-layered approach guarantees accurate, consistent, and reliable audit trails, ensuring transparency, compliance, and accountability in AWS.

The audit table comprises:

1. UserActionToken (encompassing user ID, org ID, credential ID for action signing, and request hash)
2. User-provided request signature
3. Signed request (comprising payload, HTTP method, HTTP path, and human-readable summary)

Currently, log entries lack interconnection. However, in the future, the option of including the prior entry's hash may arise to enable log integrity validation.

Note:
‍AWS CloudTrail

‍

Can I access Dfns's audit logs in real-time?

Currently, we provide access to a transaction history API at the wallet level, and the API operations log can be made available upon request. Our future plans include exposing more detailed audit logs of all microservices in use accessible programmatically through our API.

We are committed to enhancing security by relocating critical infrastructure components such as microservices and authentication services into secure enclaves. These enclaves are equipped with tamper-proof cryptographic audit logs to thwart unauthorized access by root engineers. We are also investigating the option of implementing multisignatures at the enclave entrance level. This involves distributing keys to partners and clients, ensuring that no individual root engineer can access them alone without the cryptographic approval of the asset owner(s). This approach significantly amplifies our ability to monitor and control any actions related to keys.

Furthermore, our dedicated research team, led by Chelsea Komlo, is actively working on introducing both private and public accountability and data verifiability for MPC (Multi-Party Computation). We are enthusiastic about the progress achieved so far and anticipate rolling out new features in the coming months. These features will guarantee that all signed events and associated metadata are securely recorded through encrypted audit logs or stored on the blockchain. While our ideal scenario involves broadcasting every system event on a blockchain, we also acknowledge the challenges, particularly in terms of privacy.

Cryptographic protocols
‍Threshold Signatures with Private Accountability

‍

Can users securely verify their signatures with Dfns?

Each user creates a secret passkey for accessing Dfns. This passkey is generated on the user's device locally and links to Dfns’s authentication protocol and API. We make use of the signing key in the TPM/enclave to validate requests. The secure passkey is also used to verify the user's identity and to sign significant changes made on our platform. These changes are registered in an audit log, along with their respective signatures. Any alterations not added to this log or lacking valid user credential signatures (the secure key) are immediately identified, flagged, and reported as a security breach. In the future, we plan to introduce real-time validation of the event sequence. This will enable us to proactively block further actions if any unauthorized modifications are detected.

Note
‍CodeQL

‍

Does Dfns use automated code analysis for pre-production security checks?

Yes, all code undergoes deep scanning using CodeQL before its release.

‍

Does Dfns manually analyze source code for security flaws before production?

Yes, every source code modification undergoes a thorough security evaluation prior to being incorporated or implemented. Also, we maintain a comprehensive repository of security assessments designed specifically for our API.

‍

Does Dfns monitor upstream provider failures for service continuity?

Yes, we possess a vigilant monitoring and alert system designed to detect and report failures, encompassing those resulting from issues with our upstream providers.

‍

Does Dfns follow industry standards for threat detection updates of all components?

Yes, all security tools and detection mechanisms receive updates on a weekly basis, ensuring comprehensive coverage across all components.

‍

Does Dfns follow industry standards for regular vulnerability scans across its network, applications and operating systems?

Yes, we have a vulnerability management protocol in place encompassing thorough vulnerability assessments of our network, applications, operating systems and their various components. This document is meant for internal reference only and is not disclosed externally. However, we can release a version of this policy, subject to NDA, which explains the exact SLA we follow when addressing newly identified flaws or security issues.

‍

Is Dfns able to patch vulnerabilities across all devices, applications, and systems?

Yes, we have the capability to fix and update all our systems as needed. Our vulnerability management policy encompasses the frequency of updates and SLA requirements. This policy is an internal document and isn't disclosed externally. However, we can provide a section from the policy, under NDA, outlining the SLA we follow when identifying new security flaws or issues.

‍

Can clients access vulnerability scan results upon request?

We avoid sharing vulnerability reports with our clients to protect our system's security. However, there is one exception: we may share such reports upon a client's request, but only after a minimum of 90 days from the completion of the vulnerability scan. Moreover, we only share if the vulnerabilities have been completely resolved or significantly mitigated to minimize risks. 

Contact
For more information, contact sales@dfns.co

Does Dfns’s software suppliers follow industry standards for SDLC security?

Dfns monitors and evaluates essential third-party suppliers on an annual basis. Dfns adheres to Deloitte’s Risk Assessment Framework, which is integrated into our Third-Party Risk Management Policy.

‍

Does Dfns use multiple providers for each service you rely on?

Not all systems employ multiple providers, but we ensure redundancy in vital areas of our product, such as key share storage, token price data, and blockchain nodes. Our objective is to establish redundant providers for each component in the coming times.

‍

Does Dfns reveal data communication vulnerabilities to clients and offer guidance?

We will promptly notify our clients upon detecting any potentially harmful or unusual actions originating from their accounts. Additionally, in the case of a security breach, we will inform both our customers and third-party reporting agencies.

‍

Is authorized mobile code aligned with Dfns’s security policy?

Every third-party code undergoes version locking, scanning, and manual approval prior to being deployed to the production environment.

‍

Is unauthorized mobile code always prevented from executing?

Every third-party code undergoes version locking, scanning, and manual approval prior to being deployed to the production environment.

‍

Does Dfns have safeguards against commonly used intrusion methods?

Dfns utilizes a Web Application Firewall (WAF) to proactively thwart familiar exploit techniques targeting production systems. Additionally, we have implemented intrusion detection systems on all endpoints and conduct regular scans to identify any malicious or anomalous behavior across our systems.

Is Dfns GDPR compliant?

Yes, we adhere to the eight essential rights of data subjects as outlined by the GDPR.

‍

Is Dfns SOC 2 certified?

Yes, Dfns has effectively obtained certification from Deloitte for SOC 2 Type 1 in 2022 and subsequently for Type 2 in 2023.

‍

Is Dfns pursuing other certifications?

Dfns is aiming to achieve the following certifications in 2023/2024:

• CCSS Level 3 for key management standard
• ISO 27001 for information security management
• ISO 27017 for cloud security management
• ISO 27018 for PII protection in the cloud
• FFIEC for financial security

‍

Is Dfns following security industry standards for its SDLC?

Yes, we synchronize our CI/CD and software development procedures with CIS guidelines. We rigorously assess all releases against the OWASP Top 10, both for standard applications and APIs. Furthermore, we thoroughly evaluate against a range of well-known CVEs and exploit techniques. This comprehensive security evaluation employs techniques such as SAST, DAST, SCA, Fuzzing, and customized security regression tests.

Info
‍Top 10 Web Application Security Risks

What tradeoffs exist between server-side and client-side applications?

Currently, we anticipate that the majority of users will utilize client-side applications. Server-side applications were conceived to offer comprehensive validation for API calls from start to finish. While user action signatures authenticate end-users to the designated framework, they do not extend validation to the intermediate stages of the call sequence. If you find yourself in a situation where it's imperative to ensure the integrity of all API calls as they go through your server without any unauthorized modifications, then a server-side application is the optimal choice. Through server-side applications, every API call is endorsed with a signature (in addition to the user action signature for modification requests), encompassing the request body and important headers. This process grants authorization for the legitimacy of the API call. 

Contact
If you wish to further discuss this matter, please contact security@dfns.co 

‍

How should I securely manage my Dfns API credentials?

To securely handle your Dfns API credentials, follow these steps:

• Limited Access: Grant credentials only to authorized users who require them.
• Secrets Managers: Utilize tools like HashiCorp Vault or AWS Secrets Manager for encrypted storage.
• Encryption: Store credentials in a secret store and/or encrypted on disk/decrypted in memory for an added layer of security.
• Git and Version Control: Avoid storing credentials directly within version control systems. Instead, use tools like `.gitignore` to exclude sensitive files.
• Least Privilege: Configure minimal permissions when setting up API access.
• Regular Updates: Frequently refresh API keys and tokens.
• Audit Trail: Maintain a record of credential access for monitoring purposes.
• Multi-Factor Authentication: Enable MFA for associated accounts.
• Secure Communication: Transmit credentials over HTTPS.
• Security Testing: Routinely assess application security.
• Security Training: Train your team on secure coding practices.

‍

How should I configure policies using Dfns?

By focusing on these key aspects, you can effectively configure the policy engine in Dfns:

• Clear Objectives: Clearly define policy goals and objectives to guide your configuration.
• Regular Review: Continuously review and update policies to adapt to changing security needs.
• Approval Workflows: Set up multi-approval workflows to ensure proper authorization before policy changes are applied or transactions get executed.

‍

How should I configure permissions using Dfns?

Dfns recommends applying the principle of least privilege for maximum security. This entails identifying the roles of employees within your organization and assigning them only the permissions they need on the platform to fulfill their job duties. This can be accomplished through our dashboard or our API/SDK. 

‍

What is the recommended authentication method to set up Dfns?

The choice of authentication method depends on the intended users and purpose of your application. Whether it's for users or employees, consumer use or institutional services, different factors come into play. Typically, fintech companies lean towards biometrics, while banks prefer Yubikeys for internal tasks. Striking a balance between security and user-friendliness is crucial when implementing authentication methods (Dfns). Dfns enforces two-factor authentication (2FA) and as such ensures a certain level of security. However, it's your responsibility to select an option that enhances user experience (UX) to ensure app engagement. Remember, secure software that goes unused loses its security and becomes ineffective.

‍

How do I set up multi-factor authentication for my Dfns account?

Dfns requires multi-factor authentication (MFA) for all user accounts in production. Upon registering your account, you will be guided by WebAuthn to set up a passkey that utilizes several authentication factors.

‍

Any best practices for IP allowlisting with Dfns?

We advise routing all communication to Dfns via a server under your control, where you can provide IP addresses that will be required to access Dfns. This allowlist will be utilized to validate all service requests, serving as an extra authentication layer.

‍

How can I ensure my requests are handled securely by Dfns?

Dfns' authentication requires that any requests capable of altering the state of the system or the chain must be signed using a unique secret held exclusively by you or your user. Dfns does not have access to this secret. The authentication service compares this signature against the corresponding public key to confirm its validity before allowing any transaction to enter the platform.
This establishes a cryptographic proof that the transaction originated from the intended sender.  

API Authentication
For additional details, refer to the Authentication Section in our API docs.

‍

Tips for integrating third-party apps with Dfns securely?

The Dfns API operates at a sufficiently low level of granularity that deep technical integrations are rarely needed between value added services. For example, Dfns wallet addresses can simply be passed into fiat onboarding SDKs as described here.

Contact
For recommendations on specific third-party integrations, don't hesitate to contact sales@dfns.co.  

‍

Any common threats Dfns users should guard against?

For developers, it's important to ensure the safety of critical data utilized in Service Accounts. 

For end-users, the concern lies in the potential harm caused by malicious browser extensions.

‍

How do I know if I’m using Dfns in a risky way or not?

We advise against delaying this matter any further. Please promptly reach out to security@dfns.co, and we will swiftly offer our support.