MIP39c2-SP24: Adding Immunefi Security Core Unit - IS-001

MIP39c2-SP24: Adding Immunefi Security Core Unit - IS-001

Preamble

MIP39c2-SP#: 24
Author(s): @travinimmunefi
Contributors: @psychonaut
Tags: core-unit, cu-is-001, mandate
Status: Accepted
Date Applied: 2021-10-06
Date Ratified: 2021-11-22

Sentence Summary

MIP39c2-SP24 adds Core Unit IS-001: Immunefi Security

Specification

Note: the information presented in this section, and more, will be available as permanent documentation at https://immunefi.makerdao.com as part of our transparency reporting. It will be kept up-to-date even after the publication and approval of this MIP.

Motivation

With the extensive growth of the DeFi ecosystem, as well as crypto as a whole, comes greater threats. Though a significant increase in both community sizes and funds within the ecosystem indicates a maturing environment, the glitter of success also attracts nefarious individuals and groups seeking to damage the ecosystem in exchange for their own personal gains.

While some aspects of cybersecurity within the space are well-known, primarily software audits, the shift in the ecosystem indicates a need for more proactive as well as reactive measures. With MakerDAO not only being one of the largest ecosystems in the space but also a pioneer in the push for decentralization, it is a prime target for these nefarious people. We wish to prevent, or, at the very least, minimize the negative effects of their intended actions.

Mission

Systematically improve security for builders, end users, and other stakeholders in the Maker Ecosystem by providing both reactive and proactive security services.

Vision

A Maker ecosystem with the right security measures, including regular self-evaluation for constant improvement, in order to allow the ecosystem builders and users to focus on innovation and adoption.

This is achieved through:

  1. Security Operations

    1. Identification of Critical Infrastructure - A comprehensive list of critical people and infrastructure for the Maker ecosystem and metrics that need to be tracked in order to identify the areas needing focus and have proper monitoring implemented.
    2. Bug Bounty Program - An industry-leading bug bounty program to adequately incentivize whitehat hackers to look for vulnerabilities in the Maker codebase as well as blackhat hackers to responsibly disclose vulnerabilities instead of exploiting them.
    3. Incident Response Facilitation - A refined set of “War Room” procedures and resources to minimize damages to the Maker ecosystem in the event of a successful attack.
  2. Community Support

    1. Core Unit Operational Audits - The creation, implementation, and regular evaluation of secure operational procedures for key Core Units to minimize attack opportunities.
    2. Education and Advisory - Create security resources available to all Core Units and the wider Maker community, as well as provide on-call security advisory services to foster a culture where security is taken more seriously

Core Unit ID

IS-001

Core Unit Name

Immunefi Security

Core Unit Mandate

The overall goal of the Immunefi Security CU is to secure the Maker ecosystem through multiple angles by leveraging its existing and growing security community and expertise. This involves dedicated services to the Maker ecosystem, effectively establishing a security partnership with the DAO. The CU will also aim to complement and collaborate with existing and future CUs instead of competing with them, leveraging existing processes, infrastructure, and information, among others, in order to deliver greater value to the Maker ecosystem.

As a pioneer in the DeFi space with billions in funds in the protocol, the Maker ecosystem is an attractive target for blackhat hackers who look to steal funds or disrupt the protocol. With millions lost regularly in the cryptocurrency space, it is likely that the Maker protocol, its key people, and its key infrastructure, are targeted on a regular basis.

Identification of Critical Infrastructure

To ensure that the right areas are covered by the services of the Immunefi Security CU, the CU will need to regularly identify the critical areas of the Maker ecosystem, including key people, infrastructure, and processes. The CU will create metrics that need to be tracked for each of them. It will then coordinate with other CUs to leverage existing monitoring tools, and coordinate the creation of new tools for uncovered areas that are deemed critical. Where deemed necessary, the CU will create backups as well as provide necessary support for the upkeep of these tools.

Throughout this time, the CU will ensure that the other CUs are aware of all dependencies that we have with them, and the reasons for their importance. The CU will also identify critical security dependencies across CUs throughout its investigation and surface these dependencies to the relevant CUs. The identification for need and establishment of secure communication channels will also be covered under this service.

Bug Bounty Program

The Immunefi Security CU will orient its growing community of security researchers on the Immunefi bug bounty platform towards the Maker ecosystem. Leveraging its expertise with bug bounty programs across the cryptocurrency space, especially the DeFi ecosystem, the Immunefi Security CU will create and propose a bug bounty program to economically incentivize further investigation of the code.

The program will attract whitehat hackers who find vulnerabilities and responsibly disclose them, so they are fixed before they can be exploited. Additionally, this provides an incentivized opportunity for disclosure of vulnerabilities instead of exploitation for blackhat hackers.

In order to achieve this, the Immunefi Security CU will:

  • Coordinate with various CUs in order to identify the scope of assets as well as impacts to ensure that bugs reported are those that are valuable to the ecosystem.
  • Maintain the program by incorporating additional content where needed, such as additional requirements for submissions, restrictions, and information, adding and removing scope as needed, and including various improvements from knowledge gained through the operation of the overall Immunefi platform. If necessary, the Immunefi Security CU will create separate bug bounty programs for different areas, for example smart contracts vs. cloud infrastructure.
  • Triage all vulnerability reports and escalate to the appropriate CU as needed.
  • Publicly report all critical vulnerabilities after all fixes have been implemented and verified in the format of a postmortem, and respond to inquiries from the community.

A subproposal will be created for the bug bounty program as well as a separate budget subproposal due to the unique process complexities for this.

Incident Response Facilitation

Even with an effective Bug Bounty Program and appropriate incentives in place, there are always those who don’t care about these incentives, or believe that they can get away cleanly with more funds than the bug bounty program reward.

This is why the Maker ecosystem should still be prepared to react appropriately in the event of a serious successful attack.

The Immunefi Security CU will collaborate with other CUs, such as the GovComm CU, to create a War Room of on-call members, both from within and outside the Maker ecosystem. This will provide the necessary support in order to minimize the impact of the attacks.

  • Technical experts to act on and validate successful attacks as well as assist in fixes as necessary.
  • PR specialists to take a proactive role in framing the perception of the exploit in a constructive manner, with the appropriate legal review of public statements.
  • Community coordinators to assist existing community organizers and managers in dealing with the immediate aftermath of the exploit.

Core Unit Operational Audits - Full Spectrum Security Service

In addition to software and public network security, operational security also needs to be considered due to the many other attack vectors that exist. This is why the Immunefi Security CU will provide operational audits to selected CUs in the form of a Full Spectrum Security Service.

The service first identifies the key areas that need focus, and what needs to be done to address them. Within three months, the Immunefi Security CU will then review the changes that were made by the audited CU, and make further recommendations where needed.

After this initial review, regular quarterly reviews will be conducted (1) to ensure that existing security practices are still being followed, and (2) to update the recommendations based on the most recent available information.

Throughout this process, Maker will be given access to the world class security expertise in our network to source the best solutions to its security problems.

In order to achieve this, the Immunefi Security CU will:

  • Connect with CUs that need the service and coordinate with each of them directly with appropriate prioritization, based on information acquired during the “Identification of Critical Infrastructure” section.
  • Assemble the team and support structure required to execute the service at the desired level.
  • Review changes implemented after three months to determine if the right modifications were done and if further modifications or actions are required.
  • Create a handbook that can be referenced by these CUs to incorporate into their emergency response operations as well as day-to-day safety procedures.

The audits include, but are not limited to:

  • Threat assessment
  • Private Key and multisig management
  • Securing the development pipeline and infrastructure
  • Physical security and key personnel security policies
  • Communications, operations, and information security
  • Incident response procedures relevant for the CU
  • Secure software and hardware recommendations

A subproposal will be created for the Core Unit Operational Audits - Full Spectrum Security Service as well as a separate budget subproposal.

Education and Advisory

As a last pillar of our strategy, the Immunefi Security CU will provide educational resources and on-call advisory, especially those for areas not covered by the Full Spectrum Security Service.

  • Provide content that is accessible to the wider community, including resources for end users, with prioritization determined after getting feedback from other CUs
  • Conduct live seminars and workshops for Maker ecosystem projects and CUs, with a focus on smart contract security, including bringing in experts from the wider ecosystem to provide up-to-date security information.
  • Be accessible to all Maker projects and CUs for advisory on security-related matters in the form of an open questions and answers channel as well as an office hours call twice a month.
  • Collaborate with CUs that need to provision security processes, such as the SES CU when new CUs are being onboarded.

Deputy Facilitator

In addition to a Facilitator, this Core Unit will be having a Deputy Facilitator who will engage in multiple areas of the Core Unit operations and will act as a representative. The responsibilities of the Deputy Facilitator will be growing over time as the Core Units operations gets established. A job description of the Deputy Facilitator role can be found here.

Roadmap

Below is a roadmap of the activities of the Core Unit of the first 5 months after the posting of this RFC

September - October 2021
  • Submit MIPs for Core Unit, Budget, MKR Budget, and Facilitator Onboarding
  • Onboard Deputy Facilitator
  • Begin identification of critical infrastructure for bug bounty program coverage
  • Begin draft of bug bounty program
  • Begin coordination for Incident Response
November 2021
  • Formal submission of Core Unit, Budget, MKR Budget, and Facilitator Onboarding MIPs
  • Begin content planning
  • Launch of social media channels
  • Finalize draft of bug bounty program and overall structure
December 2021
  • Anticipated Core Unit Launch
  • Post Bug Bounty Program Subproposal
  • Post Core Unit Operational Audits Subproposal
  • Set up weekly calls for office hours and general update calls
  • Launch community channels
January 2022
  • Formal Submission of Core Unit Operational Audits Subproposal
  • Formal Submission of Bug Bounty Program Subproposal
  • Finalize initial incident response procedures
  • Complete identification of metrics for nefarious activity
  • First regular content publication
February 2022
  • Organize the creation of backups for critical monitoring infrastructure
  • Commence first fire drill
  • Set up and launch bug bounty program
  • Begin Core Unit Operational Audits for two CUs

Related Documents

7 Likes

This is a super impressive and well thought out MIP39 submission – Thank you for not only the write-up, but also for putting together a nice explanation of what this CU will provide to MakerDAO.

With regards to short-term mitigation of a vulnerability–how many hours do you think it should take this CU to go from a white hacker report submitted, to announcing it to the the DAO members (pretty much a public announcement)? Or, do you think it should be announced to both the DAO members, and the general public via Twitter, Telegram, Discord, etc. simultaneously? And does the time to release such to the public depend on the severity? (I can imagine that it does)

Can the community expect White Hat attacks (fire drills) from this CU?

What is your plan of action for reporting vulnerabilities to other DeFi protocols that might get affected by a certain bug/possible exploit? As an example, imagine there’s a vulnerability in the DAI Arbitrum bridge that a new web 3 protocol is dependent of…

3 Likes

This is a super impressive and well thought out MIP39 submission – Thank you for not only the write-up, but also for putting together a nice explanation of what this CU will provide to MakerDAO.

Thank you!

With regards to short-term mitigation of a vulnerability–how many hours do you think it should take this CU to go from a white hacker report submitted, to announcing it to the the DAO members (pretty much a public announcement)? Or, do you think it should be announced to both the DAO members, and the general public via Twitter, Telegram, Discord, etc. simultaneously? And does the time to release such to the public depend on the severity? (I can imagine that it does)

The details of how the bug bounty program would work will be discussed in a separate MIP with the RFC planned to be posted in the next cycle. Thanks for asking these questions though, it helps me know what to highlight! I’ll also update this one to make this aspect clearer.

Can the community expect White Hat attacks (fire drills) from this CU?

They wouldn’t be white hat attacks per se, though the bug bounty program would encourage whitehats to look at the code. However, a fire drill will definitely be in place here with the first one set for February 2022.

What is your plan of action for reporting vulnerabilities to other DeFi protocols that might get affected by a certain bug/possible exploit? As an example, imagine there’s a vulnerability in the DAI Arbitrum bridge that a new web 3 protocol is dependent of…

This depends on the scope of the bug bounty program, which is still to be finalized. How the bug reports affecting other protocols will be handled will be addressed in the separate bug bounty MIP as well. And again, thanks for pointing this out - definitely will need to address this.

1 Like

Thanks for ping on this @psychonaut

My reaction here is this CU overlaps heavily with PE so I would like to at least have some comment from them regarding this CU addition.

Again when these CUs come on board that have functions heavily overlapping other CUs (almost being duplicated) I want to hear from the CUs where this overlap is strong about how this benefits them or whether they see issues etc.

@Derek feel free to comment here as I see Security as PE domain. I want to know if PE plans to offload security issues to this CU or whether this in fact will be a duplication of effort. When it comes to security I want not just 2 but potentially 3 teams looking at this given the importance. I do not want to get into a situation where we have a security event/issue and 2-3 CUs basically pointing at each other saying “it was their responsibility to catch this”.

When it comes to this kind of responsibility overlap I want a strong statement from CUs what is and what is not their responsibility. Because if all adding CUs is going to do is basically dilute responsibilities without giving Maker Quality Assurance and at least ‘some duplication’ of seriously important core functions I am going to start questioning the addition of these as beneficial to Maker in terms of what we get for what we are paying for.

I am going to abstain until I hear something from @Derek regarding what the addition of this CU means for PE security functions and where security responsibilities will lay with or without the addition of this CU.

Thank you in advance for responses.

2 Likes

One other question because I don’t see anything in this is whether this CU intends on addressing the long outstanding issue of:

dark issues and
dark fixes.

And whether there are clear secure communication channels, persons to handle these. In the past with an issue I found I spoke with the foundation and foundation PE. What I want to know is what are the plans for formalizing these communication channels and what the DAO will need to have secure, private and trusted activities to deal with issues in the protocol being reported to the DAO.

1 Like

Hi @MakerMan , thanks for calling me out on the above. Let me first refer to the vision of this proposal and assess where it does or does not overlap with the Protocol Engineering Core Unit from my perspective.

Regarding Security Operations, PECU:

  • (1) Does not manage an operational list of individuals/infra considered to be critical or any metrics/monitoring around this. (we do run keepers though, more on that below).
  • (2) Does not actively manage a bug bounty program - although we do review reports, perceived threats and write responses where needed.
  • (3) Does participate in war rooms and technical threat responses due to our unique knowledge of the protocol. We are a critical component in any of these meetings.

Regarding Community Support, PECU:

  • (1) Does not audit other Core Units in their operational security behaviour. As an independent CU, we manage and implement our own operational security practices and procedures only.
  • (2) Does and is working towards creating technical security resources and supporting smart contract documentation. I would argue that our role is more of a technical specialist focus as opposed to operational advisory.

Regarding critical infrastructure:

  • PECU, TechOps and others run keepers to ensure auctions get kicked off when required, that oracles are poked on time etc. Some of this is probably tribal knowledge, some of it on R/C, some in docs.makerdao etc - I don’t think I’ve seen a comprehensive list detailing all ancillary components (monitoring, keepers, circuit breakers etc) of the protocol. I consider PECU a critical part of that infrastructure, but I don’t see us as owners of this.

Regarding a bug bounty program:

  • Maker has always run a bug bounty program. I think it makes sense for this to continue as we scale to new non-standard collateral types and potentially new tokenomic designs.

Incident response facilitation:

  • I can see value from an operational perspective, but there is an overlap with PECU where PECU will likely remain the lead as the technical experts. This also intersects (at least in my understanding) with our relationship with industry auditors. I raise this question in the Core Unit Budget Thread

How is PECU different from the Immunefi Security CU:

In the context of security, the PECU focuses on:

  • Formal verification
  • Economic modelling of new financial mechanisms
  • Open source tooling development
  • Providing audit-like capabilities, reviews and assessments of a technical nature
  • …and much more, but consider that as a high level take

What does this proposal mean for PECU:

  • It will be essential to integrate existing and new technical experts into war rooms, pager duty, technical assessment activities. …keeping in mind the next point;

What am I cautious about - the bureaucratic (structural?) overhead that more teams introduce - however this is a natural evolution for all growing start-ups. Also, what is the overlap (or is it complementary) between proposed infrastructure groups like TechOps etc.

In conclusion, I do not see PECU offloading any of its existing security tasks because our focus and skill set is not so much operational as it is focused on research, tooling, modelling work, and technical risk assessments.

5 Likes

Agree with @Derek that there is practically no overlap with PECU. There could be some overlap with Techops. So this needs to be coordinated and these conversations are already going on to avoid double work.

2 Likes

You’re welcome @Derek and thank you for the detailed reply. forums are getting to the point I am missing stuff and only catch things now if I am actually pinged with a reference.

Showing what I don’t know about where the authority/responsibility CU structures going on. Making me think we need a kind of Maker CU authority/responsibility map so we can see the total area Maker is responsible for and then lay out the pieces so we can see where functions overlap and where there might be gaping holes.

Thank you for this comment Derek as it supports my general feeling as we get more CUs that we don’t have a decent functional structural diagram typically called an Org Chart in most companies that laid out departments, positions and organizational structure (who reported to whom and what the chain of command was).

Probably even more important to construct such a chart for Maker.

Thank you both Derek and wouter for responses. So my take away from your comments is that since this CU doesn’t have much overlap with other CU functions we probably need it and where it does overlap we do want some additional eyes.

Last time I looked around (when I found an issue in the system) it was not entirely clear who to contact to report the issue. So I contacted a couple foundation folks via rocketchat to report the issue.

Is there going to be a clear and 24/7365 available contact for Incident reporting, response, and then issue management?

1 Like

@Davidutro, can you comment on how you see the proposed Immunefi Security CU complement or overlap with GovComm’s emergency preparedness work?

@twblack88

2 Likes

Hey, one thing I forgot to ask–the bounty payouts–will that be in the next budget request? Like I see that StakeWise received $200K for the Rocketpool/Lido frontrunner bug–was that paid by Immunefi? What was the role of Immunefi in that scenario? Besides postmortem write-up. What would be your personal role @TravinImmunefi if such occurred within MakerDAO?

2 Likes

We met with @TravinImmunefi before their proposal was posted to talk about exactly this!

The short of it is that they most certainly compliment us rather than overlap our efforts.

3 Likes

Thanks @MakerMan for your questions and @Derek, @wouter, and @Davidutro for chiming in!

Few quick rundown points from my side:

  1. We definitely aim to collaborate instead of compete with these Core Units, as well as any other Core Units.
  2. Preventing finger-pointing of who should’ve been responsible is definitely one of our goals here - we want to clarify areas of responsibility for security, not complicate things.

Last time I looked around (when I found an issue in the system) it was not entirely clear who to contact to report the issue. So I contacted a couple foundation folks via rocketchat to report the issue.

We would be the one-stop shop here as we could direct you to the appropriate CU to speak with, depending on what the issue is. Since we’ll be doing the identification of critical infrastructure, we’ll be looking into which Core Units are managing what, so can easily perform redirects.

Is there going to be a clear and 24/7365 available contact for Incident reporting, response, and then issue management?

Making sure proper monitoring is around, and creating them when they’re not, is going to be one of the key roles of the Core Unit.

As David mentioned, we’ll be working as well with GovComm moving forward to further structure this.

One other question because I don’t see anything in this is whether this CU intends on addressing the long outstanding issue of:

dark issues and
dark fixes.

Thanks for bringing this up. This definitely seems like something useful, but I’ll probably need to address this in the bug bounty program, as it’ll be laid out in the procedures from bug reporting to bug fixing.

And whether there are clear secure communication channels, persons to handle these. In the past with an issue I found I spoke with the foundation and foundation PE. What I want to know is what are the plans for formalizing these communication channels and what the DAO will need to have secure, private and trusted activities to deal with issues in the protocol being reported to the DAO.

Yep, this’ll be something we’ll take care of. I’ll try to make this clearer as well here. Thank you!

Hey, one thing I forgot to ask–the bounty payouts–will that be in the next budget request? Like I see that StakeWise received $200K for the Rocketpool/Lido frontrunner bug–was that paid by Immunefi? What was the role of Immunefi in that scenario? Besides postmortem write-up. What would be your personal role @TravinImmunefi if such occurred within MakerDAO?

@ElProgreso Thanks for your added comments! It will be done separately as the bug bounty proposal will also be done separately. In terms of the reward, it wasn’t paid by Immunefi - it was paid by the project. Payments on Immunefi go from the project to the hacker directly, and not with us as an intermediary as we cannot hold funds to be paid out. On one hand, that’s made us attractive as no deposits are required, but on the other, it makes this a bit more complex thus the need to separate it.

In all bug reports on our platform, Immunefi provides the platform for disclosing the vulnerability, the same place where the projects also view the bug reports. This way, the bug report itself is contained and 3rd party risks are minimized. Additionally, we help coordinate the PR efforts around all of this. Unfortunately with regards to that specific case, I was not directly involved and thus have no deep insights. However, I can say that if there was a critical bug report on MakerDAO, I, personally would, depending on the stage of the CU and its growth:

  • Coordinate with the relevant CUs for the fixes
  • Ensure that the bug report flow (covering initial triaging, secondary triaging, and final reporting) is done correctly
  • Lead “War Room” coordination if necessary
  • Coordinate Post-mortem write-up
  • Coordinate payments to the hacker
2 Likes

@TravinImmunefi How is the relationship usually structured with other projects Immunifi works with? Is there a reason why you can’t just name a number you want and then we do/do not take Immunifi on as a CU (basically as a contractor)? It seems fairly straightforward in services provided? I do appreciate the effort of a breakdown at the budget, though.

Also, would you mind hooking myself or other DAO members up with some current customers that we could speak with about their experience using Immunifi?

Sorry I’m late to weigh in here. I’ve had a fairly full plate lately!

1 Like

There are a number of reasons why it’s preferred to have teams for business partnerships, even if they’re just small like the Immunefi CU, onboarded into the DAO. This is important so I want to call them out.

As a starting point, a couple of observations:

A/ MakerDAO’s Moats

MakerDAO has 3 long-term moats that protect the project from being forked gratuitously, i.e. copy/paste vampire attacks. They are

  1. vesting / locked up MKR which give participants a stake in the game and provide incentive alignment between the team and the protocol,

  2. deep integrations that require an investment to set up which is paid back over the longer term, and

  3. human capital in the form of community members who have invested so much of their time to understand Maker, the protocol, the DAO, and have a wealth of knowledge and experience that takes ages to rebuild from scratch. Going through this learning curve requires a lot of dedication and the resulting knowledge is invaluable.

If we can continue to grow these moats, so will the competitive advantage of the Maker project.

B/ Decentralized organizations

Delegation works differently in decentralized organizations. There is no command and control structure. DAOs can work only if the teams have a greater degree of ownership and autonomy compared to their centralized counterparts, and become independent engines that drive the ecosystem forward.

Even in centralized organizations, outsourcing IT services is not easy to get right. Many large corporations have effectively been gutted by attempts to buy external services to reduce costs, only to end up with a dysfunctional relationship where the supplier is basically holding the corporation hostage because it became entirely dependent on its services while the internal knowledge to provide an alternative is no longer available.

When outsourcing works, it’s because of a close working relationship between internal project managers and the external service provider. In a decentralized organization like Maker, who will take up the role of this internal project manager who represents the interest of MakerDAO?

C/ Success depends on specific insights

The next observation is that one size fits all solutions for a complex and unique organization as MakerDAO are unlikely to work. In order to be successful, it’s important to combine the expertise of the external service provider with expert knowledge about the complex machine that is the Maker Protocol.

There’s a minimum number of hours every week that a service provider has to spend to acquire the necessary knowledge to understand how their service applies to the Maker project, in which setup and configuration. And even if they have this insight… if the best setup deviates from the cookie cutter solution they’re offering, external service providers will rather offer poor service than going through the pain of customizing because that’s not interesting for them if they need to offer low prices.

Why business partnership core units are (often) a good idea

Bringing these elements together, it should be clear that a business partnership core unit, in many cases, will be a good setup that is a recipe for success:

  • A core unit with MKR retention bonus that invests a lot of time to integrate Maker with an external protocol or service expands all three of the MakerDAO moats. The core unit members have a sense of ownership, independence and loyalty to the Maker project.

  • Integrations and services are not easy and the details matter. A core unit with a Maker insider, specialist, combined with a specialist in the service provider area of expertise combines all the knowledge that is needed to get the integration right.

  • If needed, the core unit will be able to customize the service provider’s recipe to the unique needs of the Maker project. It does not have the conflict of interest to recommend a worse solution in favor of the service provider because its performance is in the first place assessed by MakerDAO.

  • With an internal team that adheres to MakerDAO transparency and knowledge sharing practices, the knowledge remains in the DAO and the service provider does not have the leverage that may otherwise tempt it to hold its client hostage for ever higher prices.

  • If the core unit doesn’t work out, it can always be defunded as long as transparency and knowledge sharing are guarded. If the core unit works out well, we have the perfect environment to make them truly shine.

My points are general and I do agree with the necessity to assert them in individual cases. Maybe @TravinImmunefi or @psychonaut can elaborate on how these points apply specifically to the Immunefi core unit.

6 Likes

Doesn’t this describe literally every single CU? This is what Maker is — a pot of money that outsources all functions. What’s the difference between a supplier who is a CU and a supplier that’s not a CU?

Perhaps I’ve also not spent enough time to understand the details. This is basically for 1) bug bounty program, and 2) a periodic risk assessment of Maker’s technical infrastructure. Is that correct?

What services are being offered that Immunifi doesn’t do for other clients? I’ve reached out to several and they all say their interaction with Immunifi is very low-effort and passive unless bounties are collected or vulnerabilities discovered. So… why does this require a CU and MKR vesting?

I feel like I’m overlooking something? Help me out.

2 Likes

Hey PaperImperium,

Thanks for your feedback! No worries about the delay. Sorry for mine as well. Been having some health and significant personal issues this month unfortunately that coincided with this RFC period.

How is the relationship usually structured with other projects Immunifi works with? Is there a reason why you can’t just name a number you want and then we do/do not take Immunifi on as a CU (basically as a contractor)? It seems fairly straightforward in services provided? I do appreciate the effort of a breakdown at the budget, though.

Also, would you mind hooking myself or other DAO members up with some current customers that we could speak with about their experience using Immunifi?

What services are being offered that Immunifi doesn’t do for other clients? I’ve reached out to several and they all say their interaction with Immunifi is very low-effort and passive unless bounties are collected or vulnerabilities discovered. So… why does this require a CU and MKR vesting?

Other projects don’t have the same service offering as what we are proposing here. They just have a bug bounty program on our website, so that’s the only overlap. Even the triaging service isn’t something that’s currently formally offered to our clients, except to the very few that got grandfathered in when we were still formally offering the service. For the operational audits, we’ve only done them with a few clients but have rejected all requests since then. With everything else, we haven’t offered them to any clients in the past but have been working on building it up.

On top of that, with their bug bounty program, as you correctly mentioned, we are mostly passive. They tell us what should be on there, and we generally accept, though point out some things every now and then, such as if a test/mocks folder was included in the link they sent to us. However, in this case we would be more proactive - it would be us interacting with the right departments (though in this case, core units) in order to draft up the bug bounty program itself as well as maintain it. With all other clients at this time, it’s expected of the client to inform us if there are any changes for maintenance. With this CU, we would be doing active maintenance and regular coordination with the appropriate CUs.

Perhaps I’ve also not spent enough time to understand the details. This is basically for 1) bug bounty program, and 2) a periodic risk assessment of Maker’s technical infrastructure. Is that correct?

I would call #2 more proactive risk assessment instead of periodic. We will be offering regular on-call security services as well and proactively see how often and to what extent we’ll need to provide security services. It won’t only be periodic checking.

Lastly, to further add to why we are doing a Core Unit, it’s operationally smoother given the decentralized nature of the Maker ecosystem. With all of our clients, we rely on a relatively central party to coordinate with our team in order to structure the bug bounty program. There’s also a central point of responsibility, among other things. As this doesn’t exist in Maker, though with smart contracts for now there’s the Protocol Engineering Core Unit primarily to coordinate with, it’s best to have a Core Unit so we can be proactive as well as deal with processes in a more efficient manner, given that we would set it up.

4 Likes

The other thing that I want to add is that the more that somebody knows about internal Maker security, the more important it is that these people be insiders, with total incentive alignment, and not contractors. Good operational security is notoriously difficult to pull off. If people that are a step removed from the Maker ecosystem are intimately familiar with how Maker secures itself against outside attackers then what have we really gained? With all due respect to our partners, outside contractors are probably going to be easier to bribe than insiders.

7 Likes

I’ve now updated the main post.

Here’s the changelog:

  • Used proper terminology to avoid misunderstandings (e.g “Subproposal” and “Formal Submission”)
  • Added Deputy Facilitator description
  • Emphasized approach to collaborate and complement rather than compete
  • Move bug bounty subproposal to December, formal submission to January, and launch to February
  • Added clarification on setting up of communication channels
3 Likes

Made some minor additional changes.

Changelog:

  • Fixed more terminology mistakes
1 Like

I think this is a key hitch for you but in the loosest sense the difference between interacting with an individual vs. a company probably is one expects better response handling. Honestly the real issue is what Maker gets for what we pay for. I can guarantee this will be one of the top 3 issues. The other one is going to be what the criterion is to replace any individual or CU facilitator. I don’t expect these to be pleasant or easy issue for the DAO to deal with. The real problem here is there is no way to optimize return for payment. And worse no clear way to hold CUs accountable unless what there is some obvious screw-up and even then human tendancies are to forgive and give people second or third chances…

The real question one has to ask is:

What CU currently is supposed to be doing any of these functions and if there isn’t anyone - why do we need them now and how much does this party expect to ask for to provide such services.

My real problem is every CU that gets its foot in the door instantly expands expense footprints. I want to start hearing from CUs not just their entry strategies but looking long term to what the maximum costs are expected to be - and I am not talking about contingency situations but more of the steady state expenses as they see their duties and responsibilities now.

I am less concerned about this CU being a service company, and more concerned about a justification for how this helps other CUs (offloading of responsibilities by which CUs currently).

Frankly when I hear from people like @wouter @Davidutro @Derek I am going to go with opinion here. I am back to wanting to hear form all my CU facilitators on this because I am more swayed by a larger group consensus of elected/appointed ‘experts’ in their areas than anyone else.

My lean here is to say yes to this with caution over budget ask and expense growth and a focus on good reports on what the DAO is getting for what it is spending.

1 Like