Extending the CCSS to include Smart Contract considerations

[Abstrct]

Since the CCSS was initially released, we've had some time watch how smart contracts have been utilized successfully, and how they have been picked apart with disastrous results. I believe that we now have seen enough to start to outline how we can improve the overall security of interacting, deploying and administrating contract-based system through additional CCSS aspects. It may also be that our current aspects already cover what is necessary, but better explanations on their application to smart contracts is needed.

This post is to be considered as a conversation starter and not the final solution to contract security. Please feel free to disagree with any elements below, suggest additional focuses, groupings, or configurations.

Personally, I don't believe our goal should be to re-create the great work done in the Consensys Smart Contract Best Practices For Development, instead we should develop a methodology about how actors interact with contracts (both those developed internally, or external contracts used by an entity). This continues our original methodology of creating a security standard that doesn't simply consider the organization being audited, but how all the actors relate and interact.

The following are my rough points to begin the conversation, which I will retool over time. I don't feel this is ready for a PR, but I'm happy to write one up once we get a bit more formal in our ideas.

Deployment Keys

• Should follow the same Key Creation requirements
• Destroyed post-deployment?
• Contract administration should be integrated into the contract rather than rely on the deployment key (see key holder grant/revoke)

Deployment Methodology?

• How do you ensure that the code developed is what is deployed
• What methods of upgrades if any are available in the contract

Development Methodology?

• How is code secured prior to the deployment process
• code signing locally by developers
• what code standards are followed

Trap doors

• Good or bad? Idk, potentially too application specific
• How does this change regarding other contracts and contracts developed by your own organization?

Interacting with contracts

• Same key/wallet requirements where possible?
• How do you ensure the contract is the correct one?

Contract Compromise Protocol

• Do the contract owners have a CCP in place in the event of a vulnerability discovery or active compromise

Keyholder Grant/Revoke in terms of Smart Contracts

• Contracts should not rely on the deployment key as the administrator
• Contracts should have a system built in for administrative interaction that allows for the administrators to change the code or state over time, or nothing at all.

Security Audits/ PentTests against smart contracts

• Contracts used in production should have code audits
• What about contract state monitoring for unusual activity?

Oracle interactions

• If external data is used in the form of an oracle, are there any additional oracle requirements to specify?

Tokens and the CCSS (out of scope for this Issue?)

Should we add anything for tokens in how assets are stored? At least from a privacy perspective, the Ethereum account system allows for very easy tracking. They are also generally difficult to hold in a multi-sig setup, so how to we require the same level of security?

External Input

Please share this GH Issue with anybody who you feel may have some insight into smart contract security. The CCSS is a community effort that excels most with the input of those deep in the trenches.

[maurelian]

Comments on the questions I have thoughts on:

Deployment Keys: Destroyed post-deployment?:

I'm in favor of deployment keys simply not continuing to have any control over the contract post deployment.

Deployment Methodology?: How do you ensure that the code developed is what is deployed

You can simply compare the bytecode generated during locally testing to what ends up on chain. We created a simple tool for this: https://github.com/ConsenSys/bytecode-verifier, it's not perfect. It's also good to check that the contract accounts storage variables are correct upon initiation deployment.

Trap doors

Is that like a honey pot?

Interacting with contracts:
Same key/wallet requirements where possible?

I'd say so.

Interacting with contracts:
How do you ensure the contract is the correct one?

Good question. In the case of a multisig contract for example, getting an account to sign and submit the right data seems to be a bit of a challenge.

Security Audits/ PentTests against smart contracts
What about contract state monitoring for unusual activity?

I think there's a lot of one-offs for this kind of stuff. But AFAIK there's not standard approach or leading product for monitoring.

Tokens: They are also generally difficult to hold in a multi-sig setup, so how to we require the same level of security?

Why are they more difficult?

[DineshCFA99]

Josh,
Thank you for this contribution. It is over my head as I am not a programmer but interested in how the CCSS is being implemented in practice. I would like to begin educating non-IT folks like myself on the CCSS and how accountants can audit for the standard at a basic non-technical level to see if they are being implemented by Blockchain focused companies.

I would be willing to volunteer with you or other C4 folks. I have connected with Michael online and in person and have contributed questions for the CBP along with suggestions.

I will be attending Pam and Andreas’ LTB event in Chicago next month.

Thank you