Chris and Robert: A Taste of Hi-5

0:00Chris RomeoAs the hosts of the Application Security Podcast, we get the opportunity from time to time to mix it up. This week, we gather a few security articles, share a summary, and offer our opinions, for what our opinions are worth. The source of the articles is High Five, a weekly newsletter containing 5 security articles that are worth your time. We scour the interwebs looking for the best articles on application and product security and share those with you. You can subscribe to High Five on the Security Journey website. Hit us up on Twitter and let us know if you like this format and if we should do more of this type of content. We hope you enjoy this episode with Chris and Robert. I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important important. The modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey, and I'm also joined by Robert. Hey, Robert.

2:01Robert HurlbutHey, Chris, good to be here. Robert Hurlbut, Threat Modeling Architect.

2:05Chris RomeoAll right, Robert. So today we're going to do something a little bit different from an episode perspective. We're going to talk about a couple of different articles that we've seen that are references or resources that we think people can use in our audience. And these articles are coming from another newsletter that I actually send out called High Five, which is 5 application security articles that are worth your time. And so, we thought we would go through and use a couple of these articles and then talk about them a little bit just to make folks aware of the type of stuff that's available out there.

2:39Robert HurlbutSounds good.

2:40Chris RomeoSo, the first one is called Interest in Secure Design Principles is Increasing, Leading to 2 Predictions. And so, this article is from a good friend of the show, Brooke Schonefeld. who is an Advisory Services Director at IOActive. And so, Robert, I'll summarize a little bit about what he— what Brooke is saying in this article, and then we can talk about it a little bit and see if we agree or disagree with the conclusions that Brooke's drawn here. And so, the first thing that he says is InfoSec doesn't understand modern DevOps development and the huge shift that it actually entails. And so, he's talking here about kind of DevOps and the fact that things are changing at a high rate of speed and security is not really able to keep up. I mean, what's your take on this, Robert?

3:28Robert HurlbutWell, I think that in general, security is trying to understand or keep up, if you will, sometimes with what software development is doing. I mean, ideally you want them to work together. And I think that's a— there's also a part of DevOps where everybody is working together much more than they probably did before. But in essence, I think that yes, security is still trying to play some catch-up and trying to understand a little bit about what's going on. And ideally, as I think Brooke mentions here, he wants them to make sure that they are working in sync.

4:06Chris RomeoYeah, and he also had an interesting point about automation here in that he says, common in DevOps is a myth that everything, including all security, can be automated. And this idea that you're taking out kind of the human element when you go to a full-on DevOps. And so, I think what he's arguing here is from a security perspective, there's always gonna be some amount of human interaction that's gonna have to be required to have a successful approach to security. And so, the second thing he says here is, this is gonna be a shocker now for anybody that knows Brooke, but secure design based on threat modeling. So, I don't know that he's gonna get a whole lot of argument from either of us about the fact that threat modeling is something that's gonna be hugely important from a secure design perspective. He does make a couple of interesting points though about the fact that threat modeling is something that really takes a number of years to cause a positive impact. I mean, it'll cause a positive impact in small amounts in the beginning when you're teaching folks about secure design and how to actually do threat modeling, but it's not something that's going to be first quarter that you start talking about threat modeling, everything is suddenly going to become super secure.

5:23Robert HurlbutRight. And in fact, I remember this one in particular, this article. I did post it as well on Twitter or pointed to it, and there is a quote that he makes here that I also spelled or kind of pointed out specifically. It says over the next 3 to 5 years, organizations that have instituted a secure design program based upon threat modeling should see their number of design issues decrease significantly. And I thought it was really interesting because first of all, over the next 3 to 5 years, we're seeing more organizations that will adopt it. And I've seen that already myself in the last number of years as well. More and more organizations are starting to pull in threat modeling. But in terms of overall when do you see the results? It does take some time. And but at the same time, you also see those results. You see more and more people thinking about secure design and issues that are related to that decreasing. So I agree with this completely, but I really just having him state that not just the obvious, but also what is really happening in the industry and various industries today. I think was, and the prediction of in the future, I think is spot on.

6:37Chris RomeoYeah, I'm not normally a fan of the future predictions of next year and whatnot because I don't think we ever are super good at determining and actually reporting on what's gonna happen next year. But I think this is 2 really good explanations for the future of application/product security. And so, I think Brooke's right on here with both of these conclusions that he's drawn.

7:05Robert HurlbutRight.

7:05Chris RomeoSo, the second article that we have is in regards to mentoring, and it's called Developers Mentoring Other Developers: Practices I've Seen Work Well by Jurjli Araz, as I believe the gentleman's name who wrote this. And I originally chose this and shared it in the High Five newsletter. It's not a security article at all. It's really about developer mentoring. And because that's such an important topic for us, I thought there's some really interesting things here that are being suggested about ways to approach mentoring that we can pull out and apply from the security perspective, but also from the developer perspective as well. He made this first point that code reviews are frequent examples of informal mentorship. Is that something you've seen, Robert?

7:53Robert HurlbutYes, actually. I was just thinking that in my own career as a developer, Over the years, whenever I've had opportunity to do a code review with another team member, whether it would be on one side where somebody was more advanced at the time or senior than me at the time, or the other way around years later, in either case, I was either learning from someone, so it became a mentorship, or I was helping someone else understand better techniques and ways of putting together code and so forth. And so absolutely, I agree with that. It definitely becomes a mentorship, and it can go both ways. I mean, I always learn from someone when I'm teaching. I also find that, you know, when somebody is teaching me, they're learning something. They've mentioned that before. So it goes both ways.

8:42Chris RomeoYeah, I really think of mentorship as something that should be happening all the time. When any interactions that we're able to have, we should all be looking for those opportunities to say, Hey, how can we help educate each other about things that we may not have as much perspective on? So, another part of this that really caught my attention was he had this list of things to think about from the introductory meeting perspective. And I've had folks that have kind of reached out to me and have said, hey, will you mentor me? And I can't say I'm as good as this list about kind of setting up that first meeting and setting expectations. And so, This really caught my attention to think about, hey, when we go to that first meeting, this is something that you can share with somebody who is a potential mentee to say, you know, here's some of the things that we should talk about. Background— where are we coming from? You know, what are the roles here? Kind of what are the expectations? What are some of the topics? How often should we follow up and discuss and have meetings and things? How are we going to communicate back and forth? What are some short-term wins? You know, how do we evaluate progress? What are some challenges? You know, just really some good things to be thinking about from the beginning because we're all real passionate about this, but we're busy people. And so, these are just some things that really caught my attention that can help us as we're planning that mentorship process.

10:04Robert HurlbutRight. So, it's not leaving it to chance. You know, oh, well, whenever we get to it, or if I have some free time, we'll catch up. You know, this is really good. It's setting a a plan in place as well as follow up and, and make it concrete. So, I like this as well. It's good, good, uh, I think recipe or menu, if you will, for, for how to put a mentorship partnership together.

10:26Chris RomeoYeah. And then, one of the other things that jumped out at me here is one of the statements is listen to what your mentee has to say. And I think that can be something that we get caught up in thinking, hey, well, I'm the mentor and I know lots about this topic and I mean, I know you and I both, Robert, agree in this perspective that we have a lot to learn, right? Like, we don't have— we have nowhere near to having everything figured out here, and we can learn a lot from everybody that we interact with. And so, the mentoring process is a— it's a back and forth, and you're both there to learn from each other.

11:02Robert HurlbutAbsolutely.

11:03Chris RomeoAnd then, one of the other things that I don't see in this, but it's probably in this article somewhere, that I've talked about before on the podcast when we talk about mentoring, and that is, I learned this from somebody else who has been mentoring me over the last couple of years, kind of more on the business side, but always give homework.

11:20Robert HurlbutMm-hmm.

11:22Chris RomeoAnd then, when do we have another conversation? We have another conversation when the homework has been completed. I had somebody do this to me and it really motivated me. I really wanted to have an opportunity to speak with this person on this topic. And so, It allowed me to know, hey, here's what I have to do. Here's what I have to complete to be able to go back and have that next conversation. And it also protects the mentor's time because if somebody's not serious about it and they're not willing to put the work in, then we don't just want to jump— we don't want to just jump on a phone call once a month and just talk back and forth, right? We want to have some action, some type of a plan. So, that's something that I've kind of taken away.

12:00Robert HurlbutYeah, and I remember you mentioning that in a previous podcast, and ever since you mentioned that, I thought about that. That, you know, that's— I think that's really, really good to again set context and help shape the mentorship towards a goal, if you will, and continue to grow.

12:17Chris RomeoAll right, well, enough about mentoring. Let's go to our final article that we have here, and this is by the good folks at Acunetix. Called 7 Web Application Security Best Practices by Tomasz Andrazejewski. I might be butchering his name. If that's the case, I'm really sorry, Tomasz. I chose this article to share because I'm always looking for things that are foundational. A lot of times we get caught up in diving deep into some technical point or some new technology or some new approach that we can roll out across an organization. And, you know, I sometimes jump past kind of the basic foundational things. And so I think it's good, it's a good reminder when we see articles like this to, hey, stop and think about the foundational things and they can help people that are trying to build programs. And so first of all on this list, Robert, is include everyone in security practices.

13:13Robert HurlbutYeah, so that means, I mean, essentially lots of different people, right? Different, obviously developers, architects, but project managers and many others involved in the practices.

13:26Chris RomeoYeah, I think we're both going to be thinking about, hey, this is an idea. This is something we want to do everywhere. Like, it's one of the things that I say all the time, and that is everyone's a security person.

13:39Robert HurlbutRight.

13:39Chris RomeoSo, this is just bringing that idea forward and saying, hey, we have to— let's just engage with that right from the beginning. This is one of the number one on the list of best practices that have been put together here. All right, the second one is adopt a cybersecurity framework. And so this one is gonna, I guess, gonna be the first one that I'm gonna kind of be scratching my head a little bit and going, hmm, really? And so when they're talking about a cybersecurity framework, the article says, hey, cybersecurity is complex. You need a well-organized approach. There's a series of frameworks, and they provide a link to some of the other kind of frameworks that they're talking about. And when they're talking about frameworks, they're talking about NIST framework. You know, this is gonna be Cybersecurity Framework, ISO 27001:800-53, ISO 27005, and even referencing things like PCI, COBIT, HIPAA. I don't know that this is the real place that I'm going to start when I'm thinking about web application security best practices.

14:38Robert HurlbutRight. I mean, what do you think instead? I mean, I've also thought about a secure software development lifecycle or something along those lines, but what are you thinking about that? Or is there something else completely, or you do drop this one?

14:52Chris RomeoNow, I think on day one, I'm going into a new company with the OWASP proactive controls as my first thing. If we can't get the OWASP proactive controls right, then there's no framework on earth that's going to save us from anything.

15:09Robert HurlbutThat's true. That's true.

15:10Chris RomeoI mean, I'm a fan of NIST CSF and some of these other frameworks. I've used them. I've built education based on NIST CSF to help those folks that are maybe more in a risk management world that are dealing with security controls and things. But I'm going to fall on the OWASP Proactive Controls and say that's my framework that I want to use at least for the first year, maybe a little bit more than the first year, to be successful with building a new program.

15:37Robert HurlbutHmm.

15:38Chris RomeoAnd ultimately, web app best practice. Third one on their list here is automate and integrate security tools. Coming back to automation and the importance of doing that in a kind of in this perspective of security. And so what are your thoughts on that?

15:55Robert HurlbutWell, yeah, definitely. I think there's a lot of things you can obviously automate or you should automate. And so whenever you can do that, I know there's also talk about, you know, some things you can't automate as well. And so just be aware of the difference, secure design tools and so forth versus automated testing tools, but wherever you can, do it.

16:18Chris RomeoYeah, it's kind of bringing us back to Brooke's statement in that first article we talked about, the fact that there is not automation for everything. And threat modeling is a great example. I mean, there's some great tools out there available to do threat modeling. You know, our friends at Aereus Risk have a solid solution to help you do threat modeling, but that's not really automatable. Right? It's not something we can put— I don't know, is that even a word? Did I just invent a word? Automatable?

16:46Robert HurlbutI might have invented a word. Maybe, but it makes sense though. But it makes sense.

16:50Chris RomeoEerie risk is not something that's sitting in the continuous integration pipeline. It's not something that's being run with every release of software. It's a design time activity that's sitting above the pipeline itself. So, I think we just got to keep that in perspective.

17:04Robert HurlbutAll right.

17:05Chris RomeoOkay, their 4th one was follow secure software development practices. Well, I got nothing on this one.

17:10Robert HurlbutNo, and I think this may have been what I was thinking about with number 2, you know, how certain practices that you, you make sure you put in place very early on, uh, to, to make sure you're following good secure development, um, methodologies and so forth. So that's what I think I was thinking about for number 2.

17:30Chris RomeoAll right, their 5th one is use diverse security measures. So they're talking about pen testing, vulnerability scanners, dynamic scanning, interactive application security testing inside the runtime environment, talking about static, WAFs, pretty much everything else under the sun. But their recommendation as a best practice here is use diverse security measures. What do you think about that?

17:54Robert HurlbutWell, yeah, I think that it makes sense, and mainly because a lot of these tools are complementary, but also the fact that A lot of these tools have very focused or very specific things they're looking for, and not all tools look for the same things. And so having that diverse perspective or approach, I think, will help make a more comprehensive, you know, review of your code, of your application, of the environment, and so forth to determine many, many different potential vulnerabilities that you need to fix or or other issues you didn't think about and so on. So, I think there's a lot of value in that.

18:36Chris RomeoYeah, I'll even go a step further and say using diverse security measures within a given category is a good thing. I've been interacting with some companies and they're like, oh yeah, we run 2 different DAST tools.

18:50Robert HurlbutRight.

18:51Chris RomeoLike, why are you using 2 different DAST tools? Well, they don't actually report exactly the same things. And so there's even a need for some diversity inside of a particular category here.

19:02Robert HurlbutWell, that reminds me of the network security. I remember years ago hearing different companies, if they can— I mean, not all will do this— but consider having 2 different firewall vendors for that same reason, that certain— one firewall has a particular set of vulnerabilities potentially, and another one has a different set, and if I have 2 of them in line, one will catch some things, the other will catch another thing, that sort of thing. Just that perspective of defense in depth, making sure you have multiple techniques, maybe as you said, even in the same category.

19:41Chris RomeoIsn't it funny now we've reached a point where we don't even really have firewalls anymore?

19:45Robert HurlbutRight.

19:46Chris RomeoPerspective of— okay, I understand protecting your corporate network, you still have firewalls, but You think about kind of the modern application deployment model, and the days of separate firewalls are really going away if they haven't left already. And so—

20:04Robert HurlbutRight.

20:05Chris RomeoAll right, the 6th one they had on this list is perform security exercises. So they're talking about mock attacks, red team versus blue team, doing maybe potentially tabletop or live exercises or experiments to Demonstrate having somebody trying to attack, having the defenders trying to respond in real time. I mean, this is— I certainly get where they're going here, and I don't know how practical this is in a modern kind of production environment to be able to do, you know, live security exercises. It might be something that has to happen kind of from a staging perspective, and I guess I just don't know how much this is actually done in the industry right now.

20:49Robert HurlbutNot enough. In fact, recently I saw this also as a recommendation. I was at a conference and someone talked about this, and there was a question, you know, how many of you in your organizations have a red team? Now, this is talking— in this article is talking about an external red team, but how many in your organizations have a red team? And only 1 or 2 people held up their hands. Now, there's maybe 30 or 40 people in the room. But that shows you it's still really new. And how many of you know what a red team is? And not many hands went up for that either. So it is still relatively new, but I think its value may prove itself over time. And the reason for this is it's a little bit different, as I understand it, than running all these other tools, these automated tools. It goes back to a person or a team who can think outside the box and try different things that an automated tool wouldn't be able to do, like phishing attacks or social engineering attacks or— and so on, to try to see, are there vulnerabilities or other ways to get into a system that we hadn't even thought about, or the tools certainly didn't try, and that we may be susceptible to and we didn't even realize?

22:05Chris RomeoYeah. Kind of brings some real-life experience to outside the scope of what the tools and things can be able to do. I guess my only concern with this, and it kind of is a little bit of a concern from number 5 as well, from kind of the penetration testing perspective, is one of the things that I'm really— is really bugging me, and it's really something I'm going to talk a lot about in 2020 and beyond.

22:33Robert HurlbutYeah.

22:33Chris RomeoAnd that's just the idea that you can't hack yourself secure.

22:36Robert HurlbutHmm.

22:37Chris RomeoAnd so, all of the— you think about like all of the efforts and all of the dollars and things that are being put into penetration testing and attack and offensive. Everything is offensive this, offensive that, right? You and I both know that if you took a 10th of the money that you spent from offensive and invested it in the front side of your security development lifecycle, Right. Right? You're going to get a much larger return on investment than you are by continuing. I mean, a penetration test has never fixed a vulnerability.

23:09Robert HurlbutThat's true.

23:10Chris RomeoAnd maybe this is a controversial thing to say. Maybe people are going to get mad. That's okay, right? Because penetration testing doesn't fix vulnerabilities. It does not result— it may identify vulnerabilities. Of course, that is the value that penetration testing provides and full-on red teaming. But at the end of the day, you can't hack yourself secure. You can spend all of your budget on offensive certifications for your team and offensive penetration testing style engagements and things. But if you don't have people there cleaning up and fixing the problems, then all of that's for nothing.

23:44Robert HurlbutAbsolutely correct.

23:46Chris RomeoAll right. The last one on this list that Ecunetix put out is number 7, maintain a bounty program. I feel like this is another loaded one for me here, Robert.

23:58Robert HurlbutRight. Well, and this is something I think we had mentioned before about where does a bounty program fit? When do you actually think about a bounty program? Do you think about it at the very beginning when you open the doors, or do you try to get some things in place first before you open everything to the world, if you will, and say, go ahead and try? and see what you can find. Yeah, which comes first, right? I think that's one thing that we need to think about.

24:28Chris RomeoYeah, I thought you were going to say which comes first, the chicken or the egg?

24:32Robert HurlbutWell, that was where I was leading to, but yes.

24:34Chris RomeoWhich comes first, the bug bounty program or the secure development lifecycle? Hopefully, the secure development lifecycle. And so, I mean, I don't have a problem with bug bounty programs. I mean, don't get me wrong here. What I have a problem with is organizations that are too immature and want to engage with a bug bounty program because they think it's— this is the cool thing that everybody else is doing. And then what ends up happening is they end up spending money to pay out on vulnerabilities that somebody found by running a scanner, right? So, my whole thing is get your house in order first. Bounty programs are a good thing, But you have to have that foundational program, that foundational set of diverse security tools, the expertise in your developers, the set of the frameworks such as proactive controls. It's something that you're actually engaging on and teaching your developers about and having them fix those types of problems. Once you've got those basic things figured out, then rock on. I mean, bounty programs are the way to go.

25:36Robert HurlbutAbsolutely. I think it also, what you just said, points to If you ran a bounty program before you even started all the other stuff that you need to start, and somebody found some extreme issues, what are you going to do then? How do you train the folks to fix those issues? You hope that all that stuff's in place, because now you got to pay the bounty as well as got to try to figure out how to fix it. So, try to do what you can yourselves first, and then when you're pretty solid with that, open it up, and then you'll be ready, more prepared. You can respond to the bounty findings and so forth, I believe.

26:17Chris RomeoYeah, I'm with you there. There's a time and place for bug bounty, and it's not going to be on day one in a new immature program. It's going to be a little further down the road. Well, hey, Robert, thanks for taking the time to go through this list of things, and for our audience, sake. We got these articles— this is based on a collection of things that we send out at Security Journey called High Five, which is 5 security articles that are worth your time. We pour through a bunch of different articles and things that we find on Twitter and lots of other places, and then we curate this into a list. And so that's— that was the source of these today. If you want to sign up and get this as a regular email newsletter, that's something you can do at the Security Journey website and hit us up on Twitter. Let us know what you think about this style of episode where we're looking at some other people's articles and, and kind of giving you our opinion. Let us know if you like this format and whether we should keep doing this more. Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast. or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.