One of the reasons I started security-sleuth.com was to improve the level of awareness of Security that all people have. Most importantly I want to make security as accessible as possible for everybody no matter what their background is or where they come from. One of the people who in my opinion has done this extremely well is Prof. Michael Hicks from the University of Maryland. Mike has been instrumental with launching the Cybersecurity specialisation with the University of Maryland and Coursera which you can learn more at (https://www.coursera.org/specialization/cybersecurity/7?utm_medium=listingPage) the specialisation delves into areas like making security usable, hardware security, Cryptography and Mike’s class on software security. The classes are available to take for free and provide a high quality and in depth subject material on Cyber Security.
Initiatives like this are really what’s making Security accessible to more people out there and they are greatly advancing the knowledge gap between Security specialists and everybody else.
I was lucky enough to ask Mike some questions. Here is what we discussed.
1. Can you give us a brief overview of your bio and how you got involved in teaching secure coding?
I got my Ph.D. from the University of Pennsylvania in 2001. Part of the research I did as a graduate student involved using programming language-based techniques to ensure that software is secure. In particular, we developed new languages for networking programming that allowed network protocols to be extensible, but in a way that was safe (think "safe plugins" and/or mobile code).
After I graduated, I was a post-doctoral researcher at Cornell for one year, and during that time I got involved in the development of the Cyclone programming language (cf. http://cyclone.thelanguage.net), which is a systems programming language, based on C, which aims to provide good performance and control over resources, while also ensuring safety and security.
These experiences hooked me on the idea that programming languages, analysis tools, testing techniques, etc. have a significant role to play in building software that is secure. Much of the research and teaching I have done since then has explored this idea.
2. Is there a security event that has impacted you the most if so can you tell us how it impacted you?
In 2011, when I became Director of the Maryland Cybersecurity Center (MC2) here at the University of Maryland, I began to realize that securing software was becoming a critical need.
Many well-intentioned people take the view that software is like a force of nature: it is what it is, and there's nothing we can do to change it. With this point of view, the only solution to the software security problem is to try to work around software vulnerabilities that exist, using intrusion detection systems, anti-virus, firewalls, etc. But this approach is simply not working. There are too many ways to work around such defences, and the adversaries have the advantage in finding them.
Consequently, we need to go at the root of the problem, which is the vulnerable software. We need to build software right in the first place. Of course software will never be perfect, but it can be much better than it is, in which case we can make the adversary's job much harder. There has been a lot of progress in industry and research, and more people need to know about it, and take up the fight. I feel very strongly now that my responsibility is to help spread the word: build security in!
3. What were some of the reasons you decided to run a software security course online?
Having taught in a traditional setting for a long time, teaching a MOOC seemed an interesting challenge. It was also appealing to reach many more people than I could in my UMD classes. For example, between the two offerings of the software security class I have taught over the last year, about 2,400 people have completed (and passed) the class. That's more people than I have taught in my entire time as a Professor!
4. Outside of teaching secure coding are there any security projects you contribute to that you can tell us about?
My focus is on teaching and research. Some of my security-related research results in code artefacts that are available on-line. For example, I co-developed (with my fantastic students) systems for dynamically updating running software. Part of the motivation for this is to apply security patches quickly, since no reboot is required. You can read about the problem at my blog [http://www.pl-enthusiast.net/2015/04/14/dynamic-software-updating/], and that page has links to the software we developed. My homepage has links to other projects.
5. Can you name the best resources you have come across in the Security or programming space?
Gary McGraw's books, like "Software Security" and "Exploiting Software", are excellent. I used these in my courses.
6. What are 3 things you could change about how coding and security is taught?
First of all, I would show students how bugs can be turned into exploits, right from the start. That is, that a software bug is not just about software not working right, but also about making it work contrary to your security goals. Introductory courses on C programming should demonstrate stack smashing, use-after-free, etc.
Second, I would introduce the idea that you need to distinguish trusted from untrusted data, in your programs, and private from public data. Which inputs come from untrusted sources, which might exploit your programs? Which inputs do not? As you move your software from one setting to another, how does the trust situation change?
Third, I would introduce a culture of using testing and analysis tools with the aim of finding problems. For example, we can teach the use of fuzz testing (e.g., using AFL), and simple static analysis (like Coverity's). These are tools that ought to be in every programmer's toolchain.
7. What are some of the biggest challenges you see coming up in software security
I think the biggest challenge we will face is the one we are facing: Getting software that is secure. Adversaries are becoming more sophisticated, and they are more able to find the flaws left behind by developers. They have the advantage and the stakes are high. We really need to work hard to change the way we think about secure development.
8. Are there any security applications or tools you use regularly that you would recommend?
I would definitely recommend fuzz testing tools, particularly AFL, especially in combination with ASAN. Clang analyzer is also really handy. But, in general, a lot issues simply go away if you get away from programming in C and C++. In that sense, a great security tool is a type-safe programming language, like Java, OCaml, Haskell, Rust, Go, etc.
9. What are some of the things you do outside of teaching and researching?
I like to run middle distances, and I coach youth soccer and play pickup Ultimate Frisbee. I also occasionally play drums, though I haven't been in a band in a while.
10. Where’s the best place readers can follow what you’re up to?
They can check me out on Twitter @michael_w_hicks and at my blog, www.pl-enthusiast.net.
Please let me know if found this article useful or if you didn't, Don’t forget to like this post or leave a comment below to let me know another area you would be interested in reading about. As always thanks for your continued support!