Monthly Archives: September 2015

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

Interview with Facebook’s Peter O’Hearn

pete-1In this post, I interview Peter O’Hearn, programming languages professor, researcher, and evangelist. Peter now works at Facebook on the Infer static analyzer, which was publicly released back in June 2015. In this interview we take a brief tour of Peter’s background (including his favorite papers) and the path that led him and Infer to Facebook. We discuss how Infer is impacting mobile application development at Facebook, and what Peter hopes it can achieve next. Peter also shares some lessons he’s learned at Facebook regarding PL research and the sometimes surprising impact PL researchers can and are having on industrial software development.

Continue reading

2 Comments

Filed under Interviews, PL in practice, Program Analysis, Scientists

What is a bug?

Buggy software doesn’t work. According to wikipedia

A software bug is an error … in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program’s source code or its design ...

When something is wrong with a program, we rarely hear of it having one bug — we hear of it having many bugs. I’m wondering: Where does one bug end and the next bug begin?

To answer this question, we need an operational definition of a bug, not the indirect notion present in the Wikipedia quote. 1

This post starts to explore such a definition, but I’m not satisfied with it yet — I’m hoping you will provide your thoughts in the comments to move it forward.

Continue reading

Notes:

  1. Andreas Zeller, in his book Why Programs Fail, prefers the term defect to bug since the latter term is sometimes used to refer to erroneous behavior, rather than erroneous code. I stick with the term bug, in this post, and use it to mean the problematic code (only).

24 Comments

Filed under Semantics, Software engineering

PL conference papers to get a journal?

As I have written previously, academic computer science differs from other scientific disciplines in its heavy use of peer-reviewed conference publications.

Since other disciplines’ conferences typically do not employ peer review, results published at highly selective computer science conferences may not be given the credit they deserve, i.e., the same credit they would receive if published in a similarly selective journal.

The main remedy has simply been to explain the situation to the possibly confused party, be it a dean or provost or a colleague from another department. But this remedy is sometimes ineffective: At some institutions, scientists risk a poor evaluation if they publish too few journal articles, but they risk muting the influence of their work in their own community if they publish too few articles at top conferences.

The ACM publications board has recently put forth a proposal that takes this problem head on by formally recognizing conference publications as equal in quality to journal publications. How? By collecting them in a special journal series called the Proceedings of the ACM (PACM).

In this post I briefly summarize the motivation and substance of the ACM proposal and provide some thoughts about it. In the end, I support it, but with some caveats. You have the opportunity to voice your own opinion via survey. You can also read other opinions for (by Kathryn McKinley) and against (by David S. Rosenblum) the proposal (if you can get past the ACM paywall, but that’s a topic for another day…).

Update: PACM has been approved, as has a new journal series called PACM PL that will collect papers accepted by major SIGPLAN Conferences. It will debut during late 2017.

Continue reading

14 Comments

Filed under Process, Science