From ‘Penetrate and Patch’ to ‘Building Security In’

This year I was pleased to be named one of U. Maryland’s Distinguished Scholar-Teachers (DSTs). This recognition, awarded to a few UMD faculty each year, is given to those who have shown success both in teaching and research. I put a lot of energy into both of these activities, so it was a great feeling to be recognized as a DST.

hicks-dst-talkOne of the consequences of accepting the award is that you must give a lecture about your research/interests to a general audience. I gave my talk, titled From ‘Penetrate and Patch’ to ‘Building Security In’, on Monday.

My Department Chair, Samir Khuller, a DST himself, told me that I should aim the talk for an eighth grade level, i.e., an audience with only a cursory understanding of computer science. But of course it’s not quite that simple: only some people who attend will be at that level; many who attend will have a stronger background because they will be interested in the topic. So as I was preparing my talk last week I tried to make it so the generalists would not get lost, and the specialists would not get bored.

The point of my talk is that our cybersecurity woes are often (but not always) due to vulnerable software. While firewalls, anti-virus, and other security products stem the tide of attacks, these products are not addressing the root problem. Once software vulnerabilties are discovered they can be patched, but this “penetrate and patch” approach is not working: unpatched systems remain vulnerable, and even when they are the patched there are probably other latent vulnerabilities that remain. “Penetrate and patch” also doesn’t address the new vulnerabilities that are introduced as the software evolves.

So we need shift our mentality to building security in: We should aim to build software that is free of vulnerabilities (or far more likely to be free of them) right from the start.

640px-Building_bridges,_Fuling_Wujiang_Bridge

To get this idea across to a general audience I used bridge-building as a motivation: We use the best designs, methods, and tools to build bridges that stand up to heavy use and extreme conditions. Then I talked about what software is — basically how it works — and how some software bugs can be exploited to deleterious effect. I showed, at least at a high level, how a buffer overflow works. Then I showed how language design and other PL-style research products are analogous to the best tools and methods of bridge-building, and can therefore help us avoid buffer overflows and other problems. I also described how — through my coursera software security class and the build-it, break-it, fix-it contest 1 — I am trying to encourage this mentality of building secure software from the start, not just leaving security to the last.

I am pretty pleased with how it turned out. Because of having to account for a broad audience, I spent a lot of time on the talk — probably as much as I did on my tenure/promotion talk! My in-laws were in attendance and they told me they understood things pretty well, and that the talk put the trajectory of recent security breaches in perspective.

A link to a video of the talk and slides is here (the proper talk starts at about the 3-minute mark):

https://www.cs.umd.edu/event/2015/09/penetrate-and-patch-building-security

The audio isn’t great, and the slides are a little hard to see (but there’s a link to the PDF), but I think it’s watchable. I’d be very curious for your feedback. I hope you will share the link with friends, tech-savvy or not, who might wonder what this cybersecurity stuff is all about, and how PL research and methods can play a important role in addressing it.

Notes:

  1. The next iteration of the contest starts Thursday, October 1 — not too late to sign up!

6 Comments

Filed under Education, Software Security

6 Responses to From ‘Penetrate and Patch’ to ‘Building Security In’

  1. e

    Congratulations on your award ( although I am not least surprised that you won it)!

  2. Jan

    Great talk! The PL community needs to make these arguments more often.

  3. iam

    Congratulations Michael!

    I was wondering, don’t you think the bridge analogy works better when referring to software reliability than to software security?

    More precisely, as you mention in your slides, bridges are built to withstand certain scenarios which have been empirically classified as dangerous: earthquakes, heavy use, storms etc.

    If one were to apply this approach to software, because it is very hard to specify all the ways in which an application might be exploited, wouldn’t the outcome be exactly penetrate and patch?

    • Yes, that’s true. In fact, other parts of the talk point out that a malicious adversary is going to try to cause the software to fail; we assume when building bridges that nature and the users of the bridge are not actively trying to sabotage it.

      Nevertheless, I think that the analogy does get the point across that you need to build your software in anticipation of it being attacked, and you should develop mechanisms that effectively defend against that attack. The talk gave one example (type safety, basically) of defending against a whole class of attacks. There are other mechanisms, and methods, that also defend against whole classes of attack. These could be brought to bear, but often are not.

      So my point is not that we should never expect there to be security bugs that we should patch, but that there should be far fewer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.