Why should we do games and workshops rather than just telling developers what to do or teaching them ‘capture the flag’ skills?
To answer that, consider that for many years, software security has naturally been dominated by ‘security experts’, specialists whose job is to seek out vulnerabilities in software and encourage developers to fix them. Such experts will tend to regard developers as lazy, since they are the ‘cause’ of the security vulnerabilities. So security experts will look for ways to ‘motivate them’ to do better security.
Learn how to use Microsoft Word to create an image or table with a caption, that stays near the text that references it.
As an author, I usually need to put images and tables into my documents. And like millions of others, I use Microsoft Word as my editor of preference, so it's vital to know how to use it well.
I love being able to sleep at night. I like it that I can be pretty sure nobody is going to break in and attack me, that my children sleep safe and my possessions are likely to remain mine. In fact, I value my security very highly indeed, and I’m prepared to pay a lot to get it. I’m sure it’s the same for you.
In fact, security and privacy are valuable to almost everyone. So why have we traditionally presented software security as a negative thing, as a tax on the cost of software development?
There’s a lot of nonsense written about passwords. I recently encountered a post exhorting everyone to make an ‘uncrackable’ password by taking a phrase and putting random symbols before, in place of spaces, and afterwards. Uncrackable such a password might be, but unmemorable it certainly will be. Imagine having to remember a different such password for each website you use!
Recently I faced a problem: where should I publish my research? Previously my venues had been suggested to me by experts, the professors whose guru status in publication was not in doubt. But now it was my own decision.
So how had these experts made their decisions?
Last week I sat down to figure out what's really going on in secure software development: 'Developer-centered Security'. I used a technique by Simon Wardley, which is great for showing a whole industry at a glance.
Many developers expect their main software security problem to be attackers from North Korea using technical software weaknesses to gain access to files in the system such as lists of passwords. But Facebook's biggest security problem ever was a decision to quietly give innocent looking semi-public data to an academic researcher at a firm of analysts. Many other companies have equally found that their security problems are far from what they might have expected.
Recently I’ve been working on the Secure Development Handbook, the most important part of this website. So here I'll ask the author’s question. How do we improve it?
Many of us learn best from games, preferably games that are fun. This section introduces three games, each of which has been devised by security researchers and used in a variety of commercial situations.
All work with agile development techniques, and all three are free to download but need some preparation, so I recommend you take a look before inviting all your colleagues to a session.
This week I’ve been at the IEEE SecDev conference in Boston. It’s been a eye-opener; I had not realised before just how many aspects there are to secure software development: toolchain improvements; what can senior management do; resources available to developers; patterns for secure development; language design to prevent time-based oracles; using strong typing to enforce security; log analysis; automated threat modelling – we heard about research on all of these.
Here too, I had the privilege of organising a Birds of a Feather session. This time I asked the question raised by the paper I was presenting: given developer resources on security tend to be inadequate, how are developers to find out what they need to know?
The lovely thing about academic conferences is the number of great researchers you meet there! Yesterday I led a Birds of a Feather session at the ESEC/FSE 2017 Conference in Paderborn; we considered the question ‘How do we make software secure?’. I was delighted to have present a number of noted software security experts, including such luminaries as Laurie Williams, Arosha Bandara and Eric Bodden.
I was privileged to attend the Workshop on Security and Human Behaviour last month in Cambridge, UK. This fascinating two day workshop brought together around ninety leading researchers in Human-Centred Security, most working in software security. The delegate page alone is worth a look: most attendees linked their key papers so it makes a good introduction to the field.
A year ago I started researching software security. I started by interviewing a dozen very experienced experts, and analysing what they said.
In their answers I found something very different from what I’d seen in the literature.
Much of the writing about software security tells programmers to use checklists of possible errors; the implication is that if the checklist is satisfied, the software is secure. Alas, this isn’t true.
Last week I was discussing my research at Security Lancaster with a friend. She said, "You must think security is the most important thing in software.”
I hastened to deny it. You see, I don't think security is by any means the most important aspect to software creation.
I attended the Foundations of Software Engineering conference in Seattle a week or so back. The conference covers a wide range of research topics, and this year they’ve moved to having three streams in parallel much of the time. Three presentations really stood out.