SE Radio 684: Dan Bergh Johnsson and Daniel Deogun on Secure By Design

Daniel Deogun and Dan Bergh Johnsson -- two of the co-authors of the book, Secure by Design -- discuss the intersection of good software design and security with host Sam Taggart. They describe how following certain software design principles can help developers create secure software without needing to become security experts. They talked about how this is the continuation of developers taking on more responsibilities: Agile asked developers to become responsible for testing their code. DevOps asked developers to work together with operations in deploying their code. Secure by Design asks developers to incorporate security into their designs.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Daniel Deogun and Dan Bergh Johnsson — two of the co-authors of the book, Secure by Design — discuss the intersection of good software design and security with host Sam Taggart. They describe how following certain software design principles can help developers create secure software without needing to become security experts. They talked about how this is the continuation of developers taking on more responsibilities: Agile asked developers to become responsible for testing their code. DevOps asked developers to work together with operations in deploying their code. Secure by Design asks developers to incorporate security into their designs.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Show Notes

Related Episodes

• SE Radio 584: Charles Weir on Ruthless Security for Busy Developers

• SE Radio 453: Aaron Rinehart on Security Chaos Engineering

• SE Radio 418: Functional Programming in Enterprise Applications

• SE Radio 405: Yevgeniy Brikman on Infrastructure-as-Code Best Practices

Transcript

Transcript brought to you by IEEE Software magazine.

This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Sam Taggart 00:00:19 This is Sam Taggart for SE Radio. I am here today with Dan Berg Johnsson and Daniel Deogun. Daniel Deogun is a frequent conference speaker on Cybersecurity. He’s worked on cybersecurity, a wide variety of domains and is currently the Chief Academy Officer for Omega Point in Sweden. Dan Berg Johnsson is a partner at Omega Point and also a frequent conference speaker. Along with another Dan, Dan Sawano. Dan and Daniel authored a book called Secure by Design. We’ve talked previously about security in many episodes such as 584, Charles Weir on Ruthless Security for Busy Developers. 453, Aaron Rinehart on Security Chaos Engineering. 418, Vladimir Khorikov on Functional Programming in Enterprise Applications and 405 Yevgeniy Brikman on Infrastructure as Code Best Practices. Welcome Dan and Daniel.

Dan Bergh Johnsson 00:01:06 Hey, thanks Sam. Thank you so much. Thanks for having us.

Sam Taggart 00:01:08 Thank you. Let’s start by talking about your book. My main takeaway from the book was that instead of training engineers to be security professionals, it’s easier to emphasize good design practices and that those good design practices just so happen to address a lot of security concerns as well. Is that the intended takeaway?

Daniel Deogun 00:01:26 Yeah, I would say the purpose when we wrote the book was that as engineers, as developers, you’re so focused on delivering new features, keeping the timelines. You have a tech lead or some sort of product lead that’s on your back all the time. So keeping your focus on security as well, that becomes a great burden or what do you say, Dan?

Dan Bergh Johnsson 00:01:47 I would say captures 95% of the intent on meaning. You get a lot of security from focusing on good design patterns, which as Daniel alluded to, is easier for developers to just keep at the back of their head all the time than explicitly thinking about security. Whereas there is a rest 5% that you really should be aware of security practices and special procedures as well. So you can’t ignore them. But definitely I think it kept 95% of the intent in that assessment.

Daniel Deogun 00:02:22 So in general as a developer, you would then start writing secure software simply by applying good design practices and get that security, I wouldn’t say for free, but for a lot cheaper than you would do otherwise.

Sam Taggart 00:02:37 So that brings me to a question. Is there some baseline level of generic security awareness training that you recommend for developers or is your recommendation more just to let developers focus on good design?

Dan Bergh Johnsson 00:02:49 I think there’s, to be able to have these kinds of ideas that secure by design is around that you should use design patterns in a deliberate way to get improvement in security. You need to have a basic awareness of what things you are addressing. For example, there’s a lot of practices to protect yourself against crosshead scripting or scur injection, stuff like that. But if you don’t know about scur injection at all, you don’t really know what good designs to look for. So familiarity with quite a breadth of security things, but you don’t need that kind of like specialized knowledge to get a lot out of benefit from that knowledge.

Sam Taggart 00:03:31 Can you describe the traditional purchase security and some of the problems with it?

Daniel Deogun 00:03:36 I would say one of the challenges with the traditional view is that you have to almost be an expert to understand what to do. And if you misconfigure something, it could be a framework, it could be a library or whatnot, you might miss something and if you make that mistake suddenly you’re vulnerable or you allow something. And that’s a big problem for many developers that they don’t feel educated enough on that topic in order to make those type of decisions.

Dan Bergh Johnsson 00:04:03 Yeah, we often see that there’s kind of like a gap traditionally between traditional development role and traditional security role, which is hurtful actually because it makes developers shy away from security and say that, oh, we haven’t met really senior architects that say, oh, I take responsibility for the uptime of the system. I take responsibility for the maintainability of the system, where I take responsibility for this and this and that. But when it comes to security, they go, oh security, no, I’m not a security. There are specialists that will take care of that with. That’s not really help at all.

Daniel Deogun 00:04:42 And the fact that you have that mindset points to an organization where you have us and them that security somebody else’s problem is not really your thing. But in reality, security is a concern. You need to design your software in a way that is secure in every aspect.

Dan Bergh Johnsson 00:05:01 And we have seen a similar play, play out before security. If we look at the early days of Agile with this gulf between developers, that is coders, programmers and testers where testing was a very separate activity and the collaboration between developers and testers were not always hard, but perhaps even like antagonistic and it didn’t help either camp. And throughout a few years we have learned to include coding and testing into the same cycle and I think we see the same kind of progress now that security has been a very separate field, but now security is embraced within coding and testing as a part of, as Daniel said, one of many concerns and a real important concern, but none that should be treated separately.

Daniel Deogun 00:05:56 Writing secure software today is more of a hygiene, I would say. It is an expectancy nowadays of almost any client you interact with. They expect this software to be secure. I mean if you design something that’s insecure is not going to pass as good software. So having the skill to apply the certain patterns have the mindset and so forth, that becomes something that everybody needs to do now and it’s so important because of that.

Sam Taggart 00:06:26 So your comment on Agile and developers and testers, before you came up with that, I was thinking of the DevOps idea of combining developers and operations, which is also very similar. So there seems to be a theme there.

[...]

Original source