top band

Friday 10:50 a.m.–11:20 a.m.

Building secure systems

lvh

Audience level:
Novice
Category:
Security

Description

How do you build secure software? Why do we see bad security track records in projects that otherwise seem to tick all the right engineering boxes? Why is communicating about security issues so painful? More importantly: how can we do all of these things better?

Abstract

Virtually all software systems have security issues. They affect teams of every experience level and systems at every scale, and their effects can be anywhere from minute to disastrous. After all: we know that in most fields, striving for zero defects is simply unrealistic; if you accept that some of those defects affect security, striving for zero security issues is unrealistic as well. Like all other bugs, saying that they are unavoidable doesn't absolve us from responsibility. We still ought to limit them, both in number and in impact. While we have many tools for limiting generic defects, we don't have much in terms of a rigorous approach to handling security problems. This is partially because the tools we have don't necessarily apply. Additionally, as an industry, we have historically not given information security the attention it deserves. This is the case from many different angles, including engineering, business, and education. As more and more serious breaches of security become publicly visible, information security is increasingly on everyone's mind. Put together, this means that while we ought to be taking these problems seriously, we systematically don't -- and, even when we do, we're ill-equipped to do so. This talk deals with that problem.
bottom band background