Introduction:
Ross Anderson is Professor of Security Engineering at the Computer Laboratory at Cambridge University. In 1998, he helped to set up the Foundation for Information Policy Research, which is the UK’s top Internet policy think tank, and currently serves as the organization’s chair. His research studies a variety of issues such as API attacks and the strength of cryptographic protocols, along with the security of clinical information systems such as NHS databases. More recently, he conducted a study to better understand how the costs of cybercrime have varied over time.

1.  Please describe your specific field of study and what it is that sparked your interest. Could you describe particular moment(s) of you career that you cherish?

I studied mathematics at university, and became interested in number theory; I then got involved in cryptography, and worked for a number of banks on the security of payment networks, including ATMs and money transfers. After that I worked on applying payment technology to new problems; for example, I contributed to the STS standard for prepayment electricity meters, which is now used in some 400 million electricity by purchasing a 20-digit number, from an ATM or nowadays over the phone, which contains an encrypted command to their meter.

In my mid-30s I went back to university to do a PhD in security, liked it, and stayed on as a member of faculty. I then worked on protocols, on hardware security and on the economics of information security, for which I’ve become well known. Most big complex systems fail because the incentives are wrong; if Alice guards a system while Bob pays the cost of failure, you can expect trouble. An example in payment systems is that card fraud is best prevented by the merchant, and by the bank that acquires transactions from the merchant, while the cost of fraud falls on the cardholder and on the bank that issued the card. As a result, many frauds come down to failures of governance. The mathematician studying fraud has to use game theory as well as the mathematics of cipher systems!

What I do nowadays is best described as “Security Engineering” and I’ve devoted myself for the last 20 years to develop it as a discipline. Just as a doctor needs to know anatomy, physiology, pathology, pharmacy, psychology and a dozen other things, all informed by clinical practice, so a security engineer needs to know about cryptology, protocols, access control, hardware tamper-resistance, and a dozen other things, all informed by case studies of what goes wrong with real systems. So, among other things, I’ve written the standard textbook on this, which you can download from https://www.cl.cam.ac.uk/~rja14/book.html.

2. What roles do mathematics play in your line of work?

Mathematical tools pop up in many places. The most obvious might be in public-key cryptography, which uses concepts from number theory such as elliptic curves and discrete logarithms. However we also use probability theory in cryptanalysis, statistics when testing economic models of crime and abuse, and while the machine-learning systems that look for fraudulent transactions use optimisation and more statistics. Formal methods are used in the tools that analyze software for bugs. There are many more examples. To be a good security engineer you have to be literate in mathematics.

3. What events in your life have contributed to where you are today with your career? In particular, how would you describe your interaction with math during high school?

At high school I considered maths to be pretty boring; when we got a new book each term, I’d, for example, check that I could do the problems and forget about it. I’d actually planned to be a doctor since I’m from a medical family. However when I was 16 I found a book in the local library that got me hooked. It was Felix Klein’s Elementary Mathematics from an Advanced Standpoint and explained all sorts of things from projective geometry to how to use elliptic functions to model a spinning top. Suddenly I understood that maths was something I was good at, rather than something that was boring, because I had nontrivial material to work artifacts. I then found and read the Feynman lectures in physics. I already had electronics as a hobby. After that there was no stopping me, and I abandoned medicine, causing a great row with my father.

4. As someone who pursues a career in academia, how has your personality impacted your career?

Like many mathematicians I’m a bit introverted, and somewhere on the Aspergers’ spectrum. This wasn’t understood back in the 1970s when I was a student so I had to deal with it myself, and found that I thrived in technical jobs rather than in sales-oriented ones. I studied a bit of psychology so I could make up cognitively for the social reflexes that didn’t come so naturally, and with time I learned to cope. Nowadays there are many resources available for young people with Aspergers and young mathematicians should not hesitate to use them. If you are on the spectrum, this also gives you some real advantages, as you’re less likely to be carried away by the madness of crowds, and you’re more able to spot and call out bullshit. In a field like security engineering, that’s actually quite useful.

5. What advice would you offer to youth today looking into pursuing mathematics?

I can only echo what Godfrey Harold Hardy said in his A Mathematician’s Apology: that if you have a real talent you should develop it. Even if you end up only as one of the top few dozen computer scientists in Britain, that’s much better than being unhappy as a bureaucrat or unsuccessful as an entrepreneur. Find your strengths and play to them. But keep an open mind about where this will take you. In my case for example I originally wanted to be a pure maths professor, but nowadays number theory is becoming a branch of algebraic geometry and that’s really too abstract for me. I found I was much stronger at adversarial thinking – at coming up with novel attacks on crypto algorithms and protocols, and then applying such techniques at various levels in the stack, from hardware security right on up to spotting incentive failures in big concrete systems. I’m good at analysing concrete problems and finding ways to break real artefacts, and I thrive on real world cases. So don’t be afraid to get your hands dirty, and engage with the real world. Good research typically comes from real problems.