In our new segment, Quantstamp is interviewing experts from the infosecurity field to learn about their career path, learn how the infosecurity space is developing and learn how the experts think their knowledge can be applied to the world of blockchain technology.

Enjoy,

Hi Zak! Tell us a little more about yourself.

My name’s Zak, and I’m a software engineer on the security team at Coinbase. I’ve spent the last five years or so working on security and infrastructure teams at medium-to-large-sized companies.

Where did you grow up?

I’m from a medium-sized town in Canada, but have spent my career here on the west coast. I’ve always felt that “growing up” was optional :).

How did you get started in the security industry?

When I was a kid, I’d spend my free time working my way through the science fiction section of my local library. I came across a book called “I, Robot” by Isaac Asimov, and it was life changing! Other media always portrayed computers as these alien- or Pinnochio-like entities, with complex civilizations or a desire to become more human, but this book presented ‘The Three Laws of Robotics’ — three simple rules for expressing programmatic behavior, and then went on to construct scenarios in which these rules came into conflict with each other, or didn’t apply to the situation.

It came from that book. I’ve always been fascinated by computer security, as it exploits the differences in what we think we’re writing, and what we’ve actually written. Computers will, more or less, do things in the exact manner in which they’re told, regardless of intent, and it’s fun to figure out what went wrong where.

What brought you to Coinbase?

Honestly, this is the first company I’ve ever worked at that takes security this seriously, and puts it first and foremost in their product and architecture decisions.

Not to mention that they have interesting problems to solve.

What is the hardest thing you had to overcome to get to where you are?

It was hard to get my foot in the door in the security space. When I was first heading off to college, the “security specialties” were mostly focused on things like knowing how to configure specific brands of networking hardware, or getting familiar with specific tooling, rather than *actual* computer security.

By the time I’d finished grad school, entire new security education industries had popped up doing everything from zero-day development and OWASP top-10 exploitation, to compliance and red team investigation. I’d studied privacy and cryptography, and it was tough to find the right fit at first.

Funnily enough, what’s helped get me comfortable with being in this space is meeting people here from all walks of life. I’ve met post-doc physicists, high-school dropouts, law students, mechanics, and so on. The biggest indicator I’ve seen of success in this field is not education, but curiosity.

What was the first security vulnerability you found?

When I was a teenager, I’d found what I’d later know as a TOCTOU vulnerability in a rewards-points system at a local theatre. You’d get, like, 100 points each time you watched a movie, and could redeem 1000 points for a free ticket or some snacks. Their system checked your balance when you swiped your card, but didn’t check it again when you redeemed your reward, so you could queue up a few purchases on a several of their kiosks, and then redeem them all at once.

This wasn’t a technically complicated bug, but a design failure. Their system worked as they’d built it, but not as it was intended to operate.

Where do you see vulnerability security in 5–10 years?

We’ve already started to see the commoditization and automation of the vulnerability discovery and exploitation process. More and more, we’re seeing automated code-scanner tools that evaluate commits or assess codebases, and companies that exist to outsource or specialize in vulnerability detection, evaluation, and triage.

I think the next five to ten years will see two things — more general developer education around security, and more languages for expressing safer code. We’ve seen the latter already with the migration to Go and Rust from C (for memory management related problems), or fully verified languages like Spark or Michelson (to help express problems better).

As for developer education, I’ve always felt like the role of a ‘security engineer’ is on its way out. We used to have ‘merge masters’ or ‘integration leads’ as a job titles, but now we have continuous integration systems, and developers are expected to know how to use git/svn/mercurial themselves, and write integration tests. Site Reliability Engineering is going the way of DevOps, in the codification of infrastructure and deployment pipelines. There’s a great article called Pets versus Cattle that explores this transition. Concepts that were once looked at as standalone, or task specific, we‘ve now come to realize as integral to the whole development process. You don’t write software, then have a ‘growth engineer’ come and make it scalable. Similarly, you can’t write code then have ‘security’ sprinkled on top. It’s part of all aspects of the design, and not something developers can overlook anymore.

That being said, there will always be room for specialists.

What’s your advice to companies going through the smart contract creation process?

There’s this disconnect between modern software engineering and contract development. In software, we have this iterative development approach that can’t be replicated in the contracts landscape.

Everyone who’s ever used a computer is probably familiar with the terms “patch”, “bug”, or “beta”, and has this dubious relationship with newly-released software, but that can’t happen in the contract space.

Contracts are immutable. You can’t push a patch to a smart contract. There are no betas here. It’s something you have to get right the first time, and that’s a far harder problem than people expect.

Why do you do what you do?

I like what I do, so I do it. I find the breadth and variety of the work to be utterly fascinating, and I have a hard time not taking it home with me in the evenings. Beyond the company, it really feels like we’re all working to a common goal.

Not to forget to mention, but blockchain tech is pretty cool, regardless of financial implications. I have a couple of side-projects where I’m using it for information attestation.

What’s your favourite thing to do when not securing the world’s digital money future?

I love jazz music, cooking, cocktails, and brunch. San Francisco is an incredible city for all of these things. I’m just hoping more places will accept cryptocurrencies in the future.

Any advice for new security experts entering the space?

It’s not possible to be a master of everything. Find your interests, and develop them. Never stop learning, but don’t stretch yourself too thin.

Why are you excited about Quantstamp?

They’re solving an interesting problem. Ethereum is popular, but Solidity has a lot of space to make mistakes. It echoes some of the previous answers I’ve given here, but ‘code intent’ is not something a lot of the tooling builds out.

What are the most common security mistakes that cryptocurrency enthusiasts engage in?

FOMO and hype. This is an exciting field, and there’s a lot of money to be made — both by creators and investors. If something sounds too good to be true, or too easy, it probably is. Be cautious.

What are the best way to avoid this mistake?

Educate yourself about the best practices of personal digital security. Don’t put all of your trust in things you don’t control. Manage your risks. Read the whitepapers, and read them skeptically. And then see how their implementation differs.

Thank you for the interview Zak!