SecTor 2018: How to help developers write secure code

There are many people in this world who sometimes don’t like each other: Leaf and Canadiens’ fans, the Hatfields and the McCoys, the security team and developers.

”I’ve seen this at so many shops,” says Tanya Janca, an Ottawa-based senior cloud developer advocate at Microsoft Canada, “The two teams kind of grate on each other … The security team making rules and the developers plotting to get around them.”

It doesn’t have to be that way, she told infosec pros at this week’s SecTor conference in Toronto.

One of the biggest causes, she thinks, is that security team members can be unkind/rude/cutting to developers who hand in less than secure code.

Janca believes solving the root problem of why companies create insecure code really will be solved in two ways: If the dev and sec teams are both supported with processes, training and resources so they can confidently get the job done; and changing the company’s culture.

Related Articles

SecTor 2018: Security industry is ‘squandering opportunity’

The cyber security industry is squandering the opportunity to make computing safer in an era of an increasing number of...

October 4th, 2018 Howard Solomon @HowardITWC

SecTor 2018: Why the cloud means new ways of thinking about security

More organizations are moving to the cloud to host and deliver applications every year as the newness of Internet-based platforms...

October 4th, 2018 Howard Solomon @HowardITWC

Janca is now a member of a purple team, Ottawa chapter leader of the Open Web Application Security Project (OWSAP) and co-founder of Cyber Ladies Ottawa, who calls herself as an application security evangelist.

But early in her career she was a software developer who knows what it’s like to feel contempt from the security team. The first time a security team member ran an automated vulnerability assessment of her code, he handed here a got a long list of things “that could have been written in another language” and was told, ‘Your app’s crap, fix this stuff.” No explanation of how to read the report, other than being told, ‘You should know’ and, ‘If you were a good developer there shouldn’t have been anything to fix in the first place.’

“I learned to avoid the security team at all costs,” she recalled. (Eventually she realized the guy didn’t know how to read the report either.)

But it got her thinking about why people just don’t get along. Academic research, she found, suggests that most bad behaviour comes from a person feeling insecure, and then reacting in kind. Hence, developers ignore rules and roll their own crypto or don’t make time to do security testing, and the security team answers questions by sending a link to the NIST website.

“It’s not the only reason we end up with insecure software, but it’s one of the big reasons in my opinion.”

To solve this will mean changing the culture of both groups. She offered five ways:

1– No more blaming; have blameless postmortems;

2—Whenever possible help save face;

3– If possible co-locate the security team and developers. It doesn’t help if they’re on different floors/at opposite ends of the building/in a different building;

4– No more infosec conferences where keynote speakers moan about the state of security and say, ‘We’re screwed.’ We know there are problems, offer solutions;

5– Be a true leader. Don’t say negative things about people; they will be repeated. Instead say, “That’s not cool”, or ask what allowed this mistake to happen. Perhaps a staffer needs extra training.

Related Articles

Increased automation helps organizations succeed: new DevOps report

The highest performing organizations will have already automated the majority of their business, according to the results of a new...

July 10th, 2017 Mandy Kovacs @MandyVKovacs

Why security is the top issue for DevOps teams in 2017

Security, not speed, is shaping up to be the top issue for DevOps teams in 2017, a new survey suggests....

January 27th, 2017 Christine Wong @itworldca

As for deeper overhaul, she offered these tips:

Improve processes

–First, create an application security team/person. They know how to find security problems in code.

“If you don’t have a person — even if they’re on the development team –that specializes in security, this is the number one reason you don’t have secure software.”

–Start security earlier – like when the project begins, and it is followed through the entire development lifecycle;

–Break security activities into smaller pieces, particularly if you’re doing agile development and working fast. So, for example, do a sprint and only for cross-site scripting problems. The next sprint look for injection problems etc. “We need to adjust as developers change the way they do software.”

Training

–Train developers to write secure code, including understanding threat modeling;

–Tell developers there’s no shame in asking the security team for advice;

–Managers should offer security training for everyone who handles code;

–Encourage developers to join developer education groups, including OWASP. Make sure they’re familiar with the OWSAP top 10 vulnerabilities;

–Offer lunch and learns;

–Have developers join the infosec team on a security incident. “Incident response is like crack,” she maintained.

Resources

–First, create an understandable security standard for code that developers have to follow. (Such as every web site has to use https, do a vulnerability scan of all software before making it live);

–Give developers security scanning tools. Some are free, others don’t cost a lot;

–In a project called DevSlops, every Sunday at 1 p.m. Eastern Janca and a group live stream a broadcast with tips on Mixer, Twitch and YouTube.

She wound up her presentation by making the audience of infosec pros raise their right hands and swear, “I promise to enable developers to create secure software together”

Which is better than swearing at people.