Software security — process, operations and software — in that order

People or organisations often think about software security as only defined by the software itself. As long as the software has the right features I’m ok, right?

In my opinion, the security of some program or digital asset is firstly defined by the human processes around it. This is the crucial bit that many people or organisations miss.

The truth is, all software have bugs. You always need to work with that assumption in mind. It’s how you deal with bugs, vulnerabilities and attacks that will define how successful you are running that software.

The Ethereum community is a relatively new software community, and while it’s got a lot of things figured out in terms of security, there’s a few gaps that I’ve written about in the past. I ended up submitting my thoughts in EIP-679 over a year ago. Since then, I’ve had a few conversations with people involved with improving the security of Ethereum, its blockchain and all decentralised applications running on it.

Here are some random thoughts of my own, regarding software security in general.

Process, first

How are you updating your software and who does it? How do you know when the software needs updating? How do you keep track of patches and modifications to your software? What does your development peer-review process look like? What’s your disclosure policy when someone wants to report a security issue?

These are all procedural questions that you or your team needs to answer before even considering running software of any importance.

Operation, second

How you operate security will often be defined by your threat model. 

Who can access your various administrative accounts? Are all your communications encrypted? How do you store your encryption keys? Who’s got access to those keys? Will you be able to detect if someone breaches one of your systems?

These are operational questions that needs to be answered and then followed.

Software, last

Once you’ve got your process and operations sorted, then you can start to think about the software itself.

Does the software protected against common attack vectors such as OWASP Top Ten?  What other features do you need in the software that would make it more secure? What’s the security model of your networking layer? How much functional and unit testing do you have? Can you formally verify your software?