Introduction to secure programming

Introduction to secure programming
Sven Anders Robbestad
17 December 2019

Do you know what scares people away from security topics?

Security experts.

They are snarky, often right off the bat, and they are purveyors of fear, uncertainty and doubt ("FUD").

Many years ago, programmers were a tribe of their own. They were wizards. You came to them with requests, and they would create the software you wanted, as long as you were respectful.

Programming has long since been commoditized, and software developers aren't given that kind of respect anymore (this is probably a good thing). However, you can still get a whiff of the old times when dealing with "security experts".

Whenever they are called in to do a review, developers are relegated to stop, listen and then bend the knee. What makes things worse, is that having a meaningful conversation with a security expert is often hard, and more often than not, you leave one feeling less enlightened than before the discussion. And you contemplate taking up another line of work, like gardening. At least then you'll be able to see the sun every now and then.

Security experts will use difficult words and concepts. They will elevate potential threats, making them seem more dangerous than they are. And they often take no small delight in making software developer's jobs harder.

Developers like to build things, security people...not so much.

Okay, this was a bit of a rant, and I may have ran into more obnoxious security people than most, which may have skewed my perception. But, the last sentence holds a kernel of truth, so let me elaborate.

In aviation, the objective is build "safe transportation". Not prevent accidents. If the latter was the ultimate goal, the simple answer would be to ground all planes.

By the same token, the goal of security should not be to block attacks, but to build safe features.

Let's start with a baseline:

• Use a threat library to guard against XSS
• Use SSL everywhere
• Provide security training for all developers and testers

Why? We all know about these things. We should focus on the features we are developing, and do just enough security work on that, the same way we do "just enough design".

How do we do that?

Make security part of your user story, feature, epic, agile definition of done, or however you segment your piece of work.

Make security into functional requirements. In other words, qualify what security means in the context of what you are developing, and make sure it's part of the development story.

Create security tests. Say, if you have a parameter in your URL that is used for search or pagination, make sure you have tests that shows it's impossible to abuse that parameter to do SQL injection or perform cross-site scripting attacks.

Create "Abuser stories" in addition to "User stories". For instance, "As an attacker, I want to modify the query parameter so I can obtain information about other users from the database".

Finally, stop worring about attacks per se, but lost value. Yes, XSS is bad, SQL injection is bad, but that's just the technical aspect. SQL injection is bad because it leads to loss of information, and that hurts credibility in the market, can lead to financial loss, and can even lead to lawsuites. So, that's what you put in your user story: "As a customer, I want to sign up for a new bank account without my personal information being stolen".