Press Release
Your application is probably vulnerable.
“But how?! We hired a company to pen test our application.
They did a thorough test against the OWASP top 10!”
On this episode of the Virtual CISO podcast, we talk with Daniel Cuthbert. He’s one of the premier authors of the OWASP ASVS, and he says OWASP Top 10 is not enough.
We chat about:
- Why the ASVS is so important
- Why we shouldn’t be putting all our faith in the OWASP top 10 (only)
- How to incorporate threat modelling into your assessments and your ASVS test
To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.
If you don’t use Apple Podcasts, you can find all our episodes here.
Time-Stamped Transcript
This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.
Speaker 1 (00:06):
You’re listening to the Virtual CISO Podcast, a frank discussion providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no BS answers to your biggest security questions or simply want to stay informed and proactive, welcome to the show.
John Verry (00:25):
Hey there, and welcome to another episode of the Virtual CISO Podcast. As always, I’m your host John Verry, and with me as always, the Luigi to my Mario, Jeremy Sporn. Hey, Jeremy.
Jeremy Sporn (00:36):
Hey bro, hello everyone.
John Verry (00:40):
So what’d you think of the conversation I had with Daniel?
Jeremy Sporn (00:43):
I’m really very excited for people to listen to Daniel because he is the match of that insanely smart application security expert who can speak in a language that really anyone can understand. It is no secret, I am not the most technically knowledgeable person in information security, cue the duh. Yeah, there we go. But it was really easy for me to follow the conversation from start to finish. I believe a sign of brilliance is that ability to make complex things simple, and Daniel accomplished that quite well in the conversation.
John Verry (01:18):
Yeah, if you understand it, he must be brilliant.
John Verry (01:24):
Yeah, I guess you could say that he channeled one of my favorite historical figures, Leonardo da Vinci, who’s famous for saying, “Simplicity is the ultimate sophistication.” Anything else people should know before we get to the conversation?
Jeremy Sporn (01:36):
Yes, expect to walk away with a clear understanding of the OWASP, Application Security Verification Standard, that is the ASVS for short, and really how the writers intended on it being used, and why it’s such a valuable standard for everyone in the application life cycle. That starts from the developers through the business leaders, all the way to the consumers. Daniel is one of the key writers of the ASVS, he has amazing insights here.
John Verry (02:03):
All right. With no further ado, let’s get to our renaissance man, Mr. Cuthbert.
John Verry (02:12):
Daniel, how are you?
Daniel Cuthbert (02:14):
I’m good, thank you. Thanks for letting me be here.
John Verry (02:16):
Oh, thanks for coming on board. Really, I’m genuinely looking forward to this conversation. So we usually start super easy. Tell us a little bit about who you are and what is it that you do every day?
Daniel Cuthbert (02:27):
I guess I am a curious security researcher and I have been for two and a half decades now, and part of that means I get to look at people doing bad stuff, trying to stop people doing bad stuff, and generally use my years of experience breaking into stuff to build better stuff that stops people breaking into stuff. Does that make sense?
John Verry (02:54):
That’s an awful lot of stuff.
Daniel Cuthbert (02:54):
A lot of stuff going on, yeah.
John Verry (02:59):
And specifically, just touch on a little bit about your work with the Open Web Application Security Project, or OWASP as it’s more commonly called.
Daniel Cuthbert (03:06):
Yeah, so that came about, first .com, right at the start of the web app security industry, or the application security industry. The world wide web was being built, and when I say that it makes me sound so damn old, and the people were building [crosstalk 00:03:23].
John Verry (03:23):
Not to me, it doesn’t.
Daniel Cuthbert (03:24):
I know it’s weird, but no, there was nothing, there was no WWW. I was like, “Yeah, there was a time when there was no world wide web,” and people were building web applications and there was a lot of money about, and there was nothing that taught anybody building these applications how to make it secure. And then Mark Curphey sent out now the infamous start of the OWASP mail saying, “Listen, here’s the idea that we’ve got, we’d love you to join.”
Daniel Cuthbert (03:49):
And the first thing that him and I built was the OWASP testing guide, which was, I guess, the first web app hacking book. “Here’s the thing called a web application, here’s how you try and hack it.” And prior to that I’d been doing a lot of OS type stuff, as you did back then. [inaudible 00:04:05] 351, ’94, ’95, and along came these cool things called web apps where you didn’t need tools, you just had a browser. So that’s where the testing guide went, and we looked at it to decide how do you test applications, how do you make sure they’re secure? It just grew from there, from seven, eight people to God knows how big it is now, but OWASP was big.
John Verry (04:28):
Yeah, and to me OWASP is clearly the number one, to me, trusted open set of guidance on application security, and as you and I have talked about previously, I’m a huge fan of the work at OWASP, specifically the work you’ve done with what we’re going to be talking about today, the Application Security Verification Standard. But before we get totally down to business, we have this tradition to ask what’s your drink of choice?
Daniel Cuthbert (04:56):
I’m not a drinker, so that’s the hard… I like [crosstalk 00:04:59].
John Verry (04:59):
Water is drinking. Green tea?
Daniel Cuthbert (05:05):
I like aloe vera juice. Years of living in Asia, I’ve become addicted to aloe vera juice.
John Verry (05:09):
You know, it’s got kind of a funky flavor, though.
Daniel Cuthbert (05:11):
It’s weird with the bits as well. Generally the first time you drink aloe vera juice you think somebody’s done something in your juice, because you end up chewing your juice. Which is weird but it grows on you, and I have a bottle here and I love it.
John Verry (05:27):
I’m known in my family as being a little bit of a nut when I drink stuff, so yeah, I drink a lot of that stuff like kombucha, and I’ve drank aloe vera juice, and a lot of… shilajit, if you’ve ever heard of that, which is… you know what I’m saying?`
Daniel Cuthbert (05:39):
Mm-hmm (affirmative).
John Verry (05:39):
Because a lot of these things I think are really good for your GI tract and for intestinal permeability, and I think that’s the source of so many of the diseases we’re seeing. So an aloe vera, theoretically, right? If it is as good as it is for skin, and if you think about it the endothelial lining of your GI tract is skin, it should be awful good for your insides as well.
Daniel Cuthbert (06:01):
Yeah, look, I mean I drink the sugar free version, but I enjoy it. It’s a weird juice that, yeah, just works for me. So I guess that’s my poison.
John Verry (06:11):
Okay. Well I figured I’m talking to London, I thought I was going to get a pint down at the pub.
Daniel Cuthbert (06:17):
That world has changed now, there’s people giving me WhatsApp messages about Sinead O’Connor love songs for a pint. It’s a weird time to be alive.
John Verry (06:28):
And for anyone listening to this, Daniel and I are recording this on March 25th, in the height of the COVID-19 pandemic, I guess you would say. So as we said, we’re here to talk about one of the things that I am really excited about, the Application Security Verification Standard, or the ASVS. So for anyone listening, how would you define, or how would you communicate what the ASVS is?
Daniel Cuthbert (06:54):
Okay, here goes. You have a web application or an architecture, blobs and things, and you need to get them tested. So you go out to the big bad world and you say, “I need an application test,” and you’ll be inundated by lots of people who say they have the best hackers in the world and they can break everything. And you’re like, “Okay, how do I know you’re going to test all the stuff?” And they’ll say, “But we employ the best people and we know how to hack stuff.”
Daniel Cuthbert (07:23):
The ASVS gets rid of that ambiguity because what we found was not many people knew how to properly test applications, and both from a testing perspective and those who are getting tested, there was a lot of, “Have they looked at this? Do we know they’ve looked at this? Do they know they should look at it?” And so on, and that’s where the ASVS comes into play. It’s a standard for testing applications, but more importantly, it allows everybody in the circle to align their requirements and offerings.
Daniel Cuthbert (07:58):
So there’s three levels. So I need a ASVS level two application tested. So the testing house knows exactly what you want, and you on the other hand also know what you should be getting. In its simplest, that’s what the ASVS was.
John Verry (08:15):
Yeah, and I think it’s great because what it does is it sets an expectation with the client on what they can expect, and it also sets an expectation on the organization that might be doing the assessment of what it is that they need to do to provide that level of assurance and meet that expectation, correct?
Daniel Cuthbert (08:31):
Yeah. The pen testing industry is still very young, I like to think we’re above 22 now where we know that we need to make our own bed, and if you’ve peed on the toilet seat you need to wipe it or pull it down. But there’s a lot of people who still don’t live like that and the industry needs to mature, because it’s all well and good, hack the planet and all that crap, and we all did it, but applications are now so ingrained in our daily life.
Daniel Cuthbert (09:02):
To give you an example, the UK is in lockdown, right? We had our lovely Boris tell the world, “Don’t go out, order everything online.” I can guarantee you when he said that, excuse the French, every single supermarket who had a web application shat the bed because they were like, “We never designed for this.” And in true form, 48 hours of that happening, every single website has either crashed or been shut down because they couldn’t handle the volume. They couldn’t handle that many people clicking buttons, doing stupid stuff.
Daniel Cuthbert (09:35):
So I think that’s where applications are so deeply rooted in our normal daily life, we have to get serious about the security stuff now. It can’t be just, “Pen test my app,” and pray for the best.
John Verry (09:47):
Yeah, same thing happened with the jobless claims, the unemployment claims here. The unemployment claims websites were down yesterday because there was so many people trying to get onto them, so I agree completely. So, quick question for you there. I love the OWASP ASVS, so talk a little bit more about… you mentioned level one, level two, level three. Talk a little bit about how we use the levels, and then a little bit more about the construct of the framework in and of itself, right? How it breaks things down into domains and the controls, and how all the pieces fit together.
Daniel Cuthbert (10:24):
Sure. So we looked at doing three levels to make it easier. So level one is for low assurance. What we mean by that, it’s fully automateable, and myself and Andrew and Josh and Jim have been putting a lot of pressure on friends who own scanning companies and [inaudible 00:10:44] to say, “Guys, build this into your tool, please. It’s easy. We’ve picked it so it can be automated,” but effectively that’s the absolute minimum of what we expect an application to be on the web today.
Daniel Cuthbert (10:57):
Even if you are really bad and have no budget, it should be level one. We don’t want people using that as an assurance thing because that’s just the bar. The one that most people will look at will be level two, and that’s generally for applications that contain anything sensitive. So PII, any data that needs protecting, right? Because the internet’s a bad place and criminals love breaching stuff. We feel like level two is where everybody should strive for.
Daniel Cuthbert (11:27):
And then the third one, which is probably the 1%, will be level three. It’s for the most critical applications, sensitive medical data, stuff that helps countries run, like you just said, the jobless thing. That’s the kind of thing that would probably contain a lot of very sensitive information, and if it drops there’s a lot of people suffering. So we’d expect a lot of effort and insight going into that application or that application architecture, and that’s where level three comes in.
Daniel Cuthbert (11:59):
So those are the three levels, and we try to keep everything in the standard quite easy to understand. And I think that’s the biggest problem with a lot of standards that we found, was that they’re often hard to implement, they’re hard to use, we don’t understand, there’s a lot of ambiguity. We wanted to get rid of all of that, and when you look at how we broke the various sections down, we broke them down into how most applications are built.
Daniel Cuthbert (12:24):
So we start off with architecture, right? Which is V1, and that’s really important because we introduced threat modeling. Now, threat modeling has been around for a long time but it was just never seen as something sexy, which I’ve never understood because-
John Verry (12:38):
It still isn’t.
Daniel Cuthbert (12:42):
To give you an idea, if I was doing bug bounties, right? And I don’t do bug bounties. I would probably take the ASVS and I would take a threat modeling tool, and I would take the application I was supposed to be testing, and I would do a threat model. And I would apply that, we’re at the same ASVS level two, and then I’d look at all the areas where I know they’ve probably not done stuff. There are my bugs. I’ve never heard of anybody talking about this.
John Verry (13:09):
[crosstalk 00:13:09] That’s actually clever, I would agree. Let me ask you a question, just to define the term for the folks listening. Threat modeling, so A, how would you define threat modeling, and B, how would you differentiate threat modeling from what I would call risk assessment, which is probably a concept more people are a little more familiar with?
Daniel Cuthbert (13:27):
It’s a really good question. So I guess for me, risk assessments have always been very much like underwear. They’re incredibly personal, and not everybody wears the same one. Everybody’s risk is completely different. I don’t know what your risk is, you don’t know what my risk is, right? And it’s hard to apply risks to somebody’s product, and we did this when we were doing pen testing because we don’t know, we don’t understand. You might have completely different controls or regulatory requirements, or something else that says, “You need to do this because you feel that’s a risk.” We don’t know that.
Daniel Cuthbert (14:03):
But in a threat model it takes a step back and says, “Right, you have an application and that application needs a user to authenticate, and for the authentication you’ve decided to go legacy, a username and password. So therefore, based on those components and those functions, these are the threats that those components will face when put on the internet.”
Daniel Cuthbert (14:26):
Brute forcing, or as the kids call it today, credential stuffing. Injection based attacks, forgotten password attacks, anything, and that’s a threat model. And what I like about threat modeling is that even for people who don’t understand the mad and beautiful world of attackers and adversaries and Chinese threats, they can still use a lot of the tools. Now, threat modeling has drastically changed over the years. The first tools out there were awful.
John Verry (14:53):
Yeah, STRIDE, DREAD.
Daniel Cuthbert (14:55):
I’m looking at STRIDE, DREAD.
John Verry (14:57):
Exactly.
Daniel Cuthbert (14:57):
Adam Shostack is on the Blackout review board with me and [crosstalk 00:15:01].
John Verry (15:00):
Yeah, and Jim Manico, I’ve heard him rail against threat modeling.
Daniel Cuthbert (15:06):
Yeah, they were hard to use.
John Verry (15:10):
He’s not a huge fan of it, as you probably know.
Daniel Cuthbert (15:10):
No, but they were hard to use, you just couldn’t. There’s one tool out there called IriusRisk. It’s written by a friend of mine.
Daniel Cuthbert (15:18):
IriusRisk.
John Verry (15:19):
How do you spell-
Daniel Cuthbert (15:19):
I-R-I-U-S Risk, and it’s a phenomenal threat modeling tool because it doesn’t assume you know every single attack out there. It’s a drag and drop wizard-based tool that you build in your architecture. You say, “Right, my application is all hipster, and I’ve got a kubes cluster and I make use of all these cloud components, and blah, blah, blah, blah.” And it generates the threat and it says, “Right, these are the things you need to look for.”
John Verry (15:46):
Gotcha. If you think about it, the fundamentals… I mean, at the end of the day, to me, threat modeling is a form of risk assessment that’s just application specific. And to me at the end of the day, any risk is a threat acting on a VULN, right? And if you think about it, you could argue that the OWASP ASVS is a list of controls, and a weakness and a control is a VULN, so in a sense it’s VULNs.
John Verry (16:10):
So it’s really just a matter of understanding what threats might act on what VULNs in what context, correct? And I’m assuming this Irius tool has ostensibly the threat and VULN libraries built in, and then it allows you to connect them?
Daniel Cuthbert (16:22):
Yes.
John Verry (16:22):
Oh, that’s cool.
Daniel Cuthbert (16:23):
Yeah, it does that. It does NIST, it does ASVS, it does all of the ones, it does PCI. And it’s nice because you go through a story where you say, “Right, I’ve got this application, it’s this language, these frameworks, this cloud provider, this technology, these databases,” and you draw network maps and you draw data flow. Because if you’re building applications, the first thing a lot of people don’t do is actually map out data flow.
Daniel Cuthbert (16:45):
Now, the one thing GDPR has given us, and I never thought I’d honestly in my career praise such efforts such as government pushes like this, but GDPR made a lot of people finally realize that you have to understand where the data’s going, how it’s flowing, and where it’s being used. And we’ve been saying this for a very long time.
John Verry (17:05):
Yeah, [crosstalk 00:17:05].
Daniel Cuthbert (17:05):
Sorry?
John Verry (17:06):
Yeah, I couldn’t agree with you more actually, by the way, and I’m on record as saying that I think that GDPR and CCPA will fundamentally change information security over the next 10 to 20 years, because once you start doing data mapping of personal information, the logical next comment is, “Why am I not doing with this all of my sensitive data? Why wouldn’t I want to know what assets are processing, where the data’s being stored, who has access to it, what critical third parties are touching it?” It’s just logical, right? It’s information governance, right?
Daniel Cuthbert (17:35):
It is, and I think the biggest frustration that we outside of America have is why doesn’t America have GDPR? I know California does, and it genuinely has cleaned up a lot of issues. Because now if you’re a company operating in the EU and you’re found to be sloppy, you’re going to get a slap. I mean, British Airways got a lovely slap when they got nailed by Magecart, and it was a hundred and something million, I think. I need to be checked [inaudible 00:18:02].
John Verry (18:02):
Was it that much? Wow.
Daniel Cuthbert (18:03):
Yeah, let me just double check, but it was big. Let me just double check, 183 million.
John Verry (18:11):
Wow.
Daniel Cuthbert (18:12):
Nothing makes a board stand up to go, “Oh shit, we need to probably do something about this.”
John Verry (18:18):
So, let’s get back to where we were, and I am famous for derailing conversation, so I’ll try to keep it… Every time I derail you, I’ll try to get you back to where we were. So we were talking about Application Security Verification Standard, right? We were talking about three distinct levels based on the risk of the application, and you were starting to talk through the structure of it, right?
John Verry (18:39):
And one of the things where we got onto this concept of threat modeling is that at, let’s say, an ASVS level two, right? We begin to look at whether they’re doing threat modeling and the completeness of the way they do threat modeling, is that correct?
Daniel Cuthbert (18:52):
Yep. So how’s it being used? How’s it being mapped in? How are they looking at the other standards? So NIST 863, how’s their software development life cycle done? Because again, what we’re trying to bring is that level of maturity up for the industry. So if you look at the breakdown of each of the ASVS levels, V 1.1 is secure software development. And here we say, “Look, for level two, we expect you to have some kind of SDLC life cycle that addresses security, right? We expect you to be doing threat modeling. We expect you to do a definition and analysis of all the architecture and connected remote services so you understand where your pieces are.”
Daniel Cuthbert (19:34):
Because if you look at what attackers are doing, they’re going off to stuff that often gets forgotten. The dev environment that got spun up and they closed down the two VPCs, but they completely forgot about the database, which is still running, which means it wasn’t patched, and so on. So we want you to be a little bit more structured about how you go into designing stuff, and also have that written down in a format where you can always reference back to it.
Daniel Cuthbert (20:01):
So that sets the scene for the next set of levels, and that’s how we’ve broken down the ASVS is that you have these various levels that you could effectively say, “Right, if we go back to our application, we’ve got a HTML field and it’s username and password.” All right, so I will go to V2 authentication, and each of these sections we have the control objective, which is effectively what are we trying to do here? So for example, for authentication we say, “Right, authentication is the act of establishing or confirming someone as authentic and making sure that they’re allowed to access that stuff, right?”
Daniel Cuthbert (20:44):
We then say, “Right, what does that actually mean in the context of ASVS level two?” So for example, password requirements. This one was really controversial because the world of passwords have become a bit muddy, because 10, 15 years ago we were told that you need to do these random uppercase, lowercase, lots of rubbish that cause nothing but security friction, and it never actually stopped people doing attacks. So we say, “For a level two application, there are a number of controls that need to be valid or present in order for it to be deemed good.”
Daniel Cuthbert (21:27):
For example, verify that you can have more than 64 character passwords. Verify that your passwords contain spaces, because a lot of us don’t. Verify if you want to, you can have emoji or Kanji or whatever you want in the password, right? So it goes through each of these little steps that if followed, raise the bar when it comes to security.
John Verry (21:51):
Right, that’s aligned with NIST 863B, right?
Daniel Cuthbert (21:54):
Yeah.
John Verry (21:54):
That’s where you guys got that idea from.
Daniel Cuthbert (21:56):
We work closely with this because there’s no point in not, and NIST advice is phenomenal.
John Verry (22:00):
I agree.
Daniel Cuthbert (22:00):
I really, really like NIST, I think they are one of the unsung heroes of the American government because they’re just doing so much stuff. That and Cyber Command and what they’re doing, there’s some really good efforts coming out of that. But yeah, so we aligned with them and we wanted to do more practical stuff. So password strength meter, right? It’s really simple, but it’s a great idea.
Daniel Cuthbert (22:24):
Things that are the bane of everybody’s life, forcing password changes. Why? So we have it in there, 2.1.10, verify that there are no periodic credential rotation of password history requirements, which was very controversial and a lot of people didn’t like it, but it’s like, “We need to mature, we need to grow up.” So that’s how you use the ASVS, you go through each of these sections to say, “Right, I’m building this login function. Dear developers, during this next sprint we need to build this to conform to our own internal coding practices, but also we want it to be ASVS level two compliant.”
John Verry (23:02):
Gotcha.
Daniel Cuthbert (23:03):
So the developers can go away, they know exactly what we want because we’ve got the sprints, we’ve got the stories, and they now go, “Right, I’m building this. Okay, let’s look at level two. All right, I’ve got 14 things I need to make sure, cool. Each of those goes into Jira, let’s go ahead and do it.”
John Verry (23:20):
Gotcha. So real quick, so level one has roughly 131 controls, if I recall correctly, and these are broken down across 14 domains, right?
Daniel Cuthbert (23:30):
Yes.
John Verry (23:30):
So you mentioned authentication, there’s session management, there’s APIs, there’s application architecture, threat modeling. It’s broken down by sections, there’s 131 controls for level one. There’s, as I recall, 267 I think it is for a level two, and 292-ish or something like that for level three?
Daniel Cuthbert (23:50):
Yep, yep, there’s a lot.
John Verry (23:51):
Yeah, there is a lot. But the reality is that there’s a lot of ways that bad guys, or either intentionally or not intentionally can break applications. So there’s a good reason why you have a lot of good controls there to prevent that from happening.
Daniel Cuthbert (24:05):
Yeah, and not all apply. I think that’s what a lot of the feedback we’ve got is. “Oh God, it’s too much to put them all in.” I’m like, “But not every single application is going to have these.” Again, it goes back to the architecture stuff, right? How well do you know what you’re building? And a lot of people still to this day don’t do that, they don’t have solid foundations to which they’re building applications. And what we’re trying to say is if you do that at the start, you understand the data flow between components. All right, I don’t need half the ASVS, because I’m not doing that. Here’s the ones that I do need.
John Verry (24:36):
Right. Question for you. So yeah, you mentioned at the very onset the way that we use the ASVS as an application security verification team, right? We conduct assessments of applications, deep dives into those apps, and we use the tool to give people assurance that they’re aligning with an ASVS level two or level one set of criteria.
John Verry (24:56):
You also mentioned developers. Anyone else in terms of your audience? So what I like about it is that I like to say to our clients, “Look, it’s an open book test. Download the ASVS, we’re going to come in in one month, three months. Make sure your developers know what the target is so that way we can help you validate that they hit the target.”
Daniel Cuthbert (25:15):
Yeah, so in my experience, developers, we always had that thing a while ago, and it’s not something I’m proud of, where we used to belittle the development team saying, “You don’t know security.” But as especially me matured, I realized they don’t need to, that’s not generally their job. Their job is to build functions and features and get code out. Now sure, there are arguments where you say, “Well, you should know how to do it in a secure way.”
Daniel Cuthbert (25:42):
And I agree, but for example, I don’t go and buy a car and say, “Right, I need the most secure car.” I assume and I expect a lot of cars have been built with standards in mind. Now sure, there are some that are far better than others. I love Mercedes. Generally, if you’re going to buy a Mercedes or a Volvo, you’re going to live a long life in a car accident, versus a cheap homemade garage car which might change stuff. But you don’t go and buy stuff to say, “I want a secure toaster.” You want the toaster just to work to a standard, and I think that’s where the ASVS is going, where we’re saying to developers, “These are what we expect a function to do, go ahead and build it into your product,” type of thing.
John Verry (26:27):
Gotcha. Thank you, so your transition there was awesome, because what I was just about to ask is so OWASP puts out an inordinate amount of great guidance, ASVS being what we’re talking about specifically here, but the ASVS integrates, or bumps up if you will, interacts with a number of the other frameworks, and I was going to ask you about those.
John Verry (26:46):
So as an example, for years the standard application security test was an OWASP top 10. So, does the OWASP top 10 go away with ASVS? Is that still something that OWASP is supporting? How does somebody who’s listening to this say, “Hey, we’ve been doing OWASP top 10s, does that mean I shouldn’t do that anymore?”
Daniel Cuthbert (27:10):
This is where I might get controversial. The top 10 had a purpose, and it was to try and raise the bar a little. The problem is a lot of people use the top 10 as gospel and they said, “Well, we do OWASP top 10 testing.” I’m like, “I don’t know what that means,” right? Because it’s vague, it’s generic. That was the whole point of the top 10, and I think the message has been diluted quite heavily.
Daniel Cuthbert (27:35):
I know Andrew is doing a lot of work to try and get back to it, but for example, if you say, “I want an application test to OWASP top 10,” we’re back to the square one where we don’t know exactly what the testing is being done or what I should be expecting. So we want it to almost say, “Right, if you’re going to do a top 10…” Let’s say the top one, A-1 injection, right? Injection is still a massive problem. How do you know, or how do you test it, okay?
Daniel Cuthbert (28:03):
Well here’s what an ASVS level two says injections should not do, or an application should not do to be vulnerable to it. And then link to OWASP testing guide to say, “Right, if you’re a tester, here’s how you test for this.” So [crosstalk 00:28:19].
John Verry (28:18):
That would be perfect world.
Daniel Cuthbert (28:21):
That’s where the product’s going, it’s-
John Verry (28:21):
Yeah, that’d be the perfect world, that map.
Daniel Cuthbert (28:21):
Yeah.
John Verry (28:22):
That map from top 10 to input validation grouping within ASVS, back to testing guide, to how do we test input validation, correct?
Daniel Cuthbert (28:31):
Yep. So rather than them being siloed, which I think they were in the past, we’re now trying to say, “Right, we’re all linking up to everything.” It’s still a monumental amount of work, but what we were trying to do between ASVS and testing guide is link those over. So for example you have, “Okay, verify that input validation is enforced.” All right, okay. So then you link to the testing guys say, “Right, this is how you do it, this is the test that you’re going to use, here’s some of the tools, here’s what you should get back,” and so on and so forth.
John Verry (29:01):
So an OWASP top 10 test, in… So in application security where we have the concept of dynamic application security testing, which is more what most people would consider vulnerability assessment, penetration test. And then you’ve got static, which is code review, and then you’ve got architecture assessment, let’s say, or a technical audit, if you will, which is digging into the deeper stuff. So correct me if I’m wrong here. OWASP top 10, fully dynamic application security testable, correct?
Daniel Cuthbert (29:27):
Yes, yep.
John Verry (29:28):
Okay. Talk about level one, level two, level three, and which blend each one of those might be, right? So as an example, when you get to level two, are we getting to the point where we’re doing code review?
Daniel Cuthbert (29:42):
No, so I’m still a believer that level three are code reviews. Code reviews are very expensive, they’re time consuming, they’re hard to do because the person doing the code review does need a fair amount of skills. For me, a good code review person is the unicorn of the security world because one, they have to understand the languages, two, they’ve got to understand the architecture and how the components work, and three, they’ve got to understand how bugs happen and bugs are exploited, and that’s where the complexity comes in. That’s not a skill you can easily pick up. But that’s why we-
John Verry (30:18):
Right, plus they have to understand the business use case, right?
Daniel Cuthbert (30:19):
Exactly.
John Verry (30:19):
I mean, if you don’t understand what the app does at a fairly significant level, it’s also hard to… logic errors are not going to be obvious, right?
Daniel Cuthbert (30:28):
Yeah, I mean business logic errors are huge. I work in finance, believe me, that is very hard, and you have to understand how they’re used and how traders might use them, and how various formats work and so on. So I think that’s why we always thought code review was a level three type thing, because it’s not something that’s easily done, it’s expensive.
Daniel Cuthbert (30:46):
Look, the benefits are phenomenal, but unfortunately it’s still very hard to do. No matter what any vendor says, when they say they can do fully automated code reviews, they can’t. And I know people hate me for that, but they can’t.
John Verry (31:01):
Right. Yeah, no, it’s going to pick up some things, but it’s not going… It’s just the same way that we’ve always said for years. When you do a vulnerability assessment dynamic test, if you’re not doing it from a fully credentialed perspective and doing some manual testing, you’re likely to miss privilege escalation. Because really, the tools just are not capable of testing that, and same concept on the application security, right? They can pick up certain types of flaws, but other flaws which are more logic oriented are not going to be picked up by a code tool, correct?
Daniel Cuthbert (31:30):
Yep, agreed, 100%, 100%.
John Verry (31:32):
Cool. So we talked about how it interacts with the OWASP top 10, so it sounds like in the OWASP community there’s a little bit of a difference there, we’re still mediating out. But it seems like, and I would agree, that as applications become more and more business critical, higher and higher risk, that getting to at least an L1 is a good place to be.
Daniel Cuthbert (31:52):
Yeah, I’m going to give a perfect example, right? Ring. Ring came onto the scene, became incredibly popular because here we have a internet device where you can interact with people coming to your house and do security and so on. It’s a mix of technology, so with hardware, API, backend processing, and a mobile app and a front end app, web applications, and you could almost see what was coming.
Daniel Cuthbert (32:19):
If you’re not going to build something that is quite invasive when it comes to a privacy perspective, people will abuse it, and boy did people abuse it. And you’d almost think somebody didn’t do a threat model, because the fact that there was 2FA, the fact that it was easy to brute force the Ring authentication function, that would have been picked up in a threat model.
Daniel Cuthbert (32:45):
So I guess that’s where these applications and this new way of doing stuff, we need to get more serious about how we look at these applications. Because you then had the inevitable stories of people being spied upon by some other people around the world, where they were logging into the Ring cameras because they had a password reuse and they didn’t know any better. And people logged into the Ring account because Ring wasn’t doing any telemetry where they were saying, “It’s weird, Sally’s never logged in from Romania before. Maybe I should do a secondary… Oh, I can’t do a secondary push because I don’t have it.” So it’s little things like that that could have made a lot of difference, but it never happened.
John Verry (33:25):
Right. Quick question for you, so now you crossed into another area that I actually was curious to talk to you about. So increasingly we’re doing a lot of IOT testing, and IOT testing is very interesting in that there’s an awful lot to it, right? You’ve got the… call it the end points, the cloud solution, the APIs that sit up in the cloud. Maybe there’s a web gooey on top of that, so you’ve got potentially some testing there.
John Verry (33:51):
You’ve got testing of the mobile apps that are integral to many of these solutions, you’ve got testing of the actual end devices themselves, and OWASP has a really nice document, I’ll call it the OWASP IOT top 10, and you’ve also published a really cool document that’s got… you break down the potential inputs into these devices into 16 categories, and you give some good guidance on what needs to be tested.
John Verry (34:13):
How does the IOT top 10 currently interact with ASVS, and do you have plans to integrate them a little bit more? That same idea of this VULN means this too, in this way?
Daniel Cuthbert (34:27):
Yeah, so for version four we spent a lot of cycle on… you have the mobile ASVS and you have the IOT stuff, and there were initial calls about, “Well, let’s make it into one document,” and we didn’t feel that would be the most responsible way of doing it for two reasons. First up, I’m not a firm believer that a standard should be changing all the time. It’s the one thing where people need to embed it into their life cycles, which could be a yearly or two yearly type process, and if a standard’s constantly changing, which is good in a way for innovation, it’s bad because people are not going to want to stick to a specific release.
Daniel Cuthbert (35:06):
So what we thought was in, say, fast changing environments such as IOT and mobile ASVS, let’s reference it, because then that way we can say, “Look, for ASVS four, which is still going to be around for a while, if you’re doing an internet of things, you could still apply a lot of the same things.” Because like you said, if I look at modern internet of things, they’re a mix of a lot of technologies, hardware, firmware, data, mobile, traditional web app.
Daniel Cuthbert (35:38):
So if you were building a product and doing an assessment, you could reference ASVS level four for any of the ones where APIs or data storage or configuration management or so on, and then when you need to be more niche, you could say, “Well actually for the secure update thing, pulling down firmware blobs from a server, I need you to do X, Y, and Z.”
Daniel Cuthbert (36:00):
We didn’t want to cram it all into one standard because it’d be hard to manage and it would be quite hard to use. So eventually we want to see the linkup between all the projects, like we said earlier, like you just alluded to now.
John Verry (36:10):
Gotcha. Yeah, listen, I agree completely, and I can tell you even just from our perspective, there’s a huge amount of overhead every time a standard changes. So as an example, we had developed all of our reporting and all of our mechanisms and methodologies around ASVS 3.2. Four was a massive change and really had to start over, so I agree with not changing things too often. I think that’s where the successful frameworks like SOC 2 or ISO 27001, right? They change every three to four years just for that reason. So I agree with that thought process, that’s really cool.
Daniel Cuthbert (36:45):
Yeah, I mean, four was a massive change. It was almost like the coming of age for the standard, where-
John Verry (36:52):
Yeah, agreed.
Daniel Cuthbert (36:53):
For a number of reasons, before that we did it using Word, and I wanted to shoot myself every day because nobody should be using Office anymore, it’s awful. But two of the main fundamental things that we wanted to do with version four was we wanted it to be more transparent and open to the community, hence we’re using GitHub. So when we were writing stuff we were doing the commits, and people could comment and they could do pull requests, they could call us out on stuff, they could find flaws.
Daniel Cuthbert (37:22):
And the feedback that I got from that was just phenomenal, and that’s impacted a lot of what I do in my normal professional life. And two, we wanted to slow down the constant updates, so we wanted lots and lots of eyes on the standard so that when it became gold master, it’s gold master for a while, unless there’s some really serious issues.
Daniel Cuthbert (37:44):
But effectively, yeah, four will be stable and solid for the reason you just gave, because we know that a lot of tools are now building it in, and we don’t want to be those people that say, “Every six months it get updated,” because then people just won’t use it.
John Verry (37:55):
Gotcha. Now that was another question I had for you, with regards to tools. So a lot of our clients, we recommend that they use a tool, at least a tool like Burp Suite Pro or something of that nature, for themselves. When we do testing we’re using Burp Suite, we’re using Actionetics, we’re using AppSpider, tools of that nature. I know OWASP creates some tools. Are your tools going to become more ASVS four aligned, like a ZAP tool that you guys produce, and/or are the vendors that I’m just referring to, are they talking with you about building ASVS four hooks into their products?
Daniel Cuthbert (38:34):
I’m being very annoying with a lot of these toolmakers. So Simon for ZAP and [Dafford 00:38:39] for Burp. I love Burp, I really do.
John Verry (38:42):
It’s a great…
Daniel Cuthbert (38:43):
I think it’s probably one of the best [crosstalk 00:38:43].
John Verry (38:44):
It’s insane at the price point. How would you not have it as an application developer?
Daniel Cuthbert (38:48):
Exactly. If you’re doing this kind of stuff and you can’t afford that tool, then I don’t know what to say.
John Verry (38:56):
You shouldn’t be doing it. You shouldn’t be in business.
Daniel Cuthbert (38:58):
Exactly, it’s a great tool. It’s not an expensive tool and it’s phenomenal, it’s a powerful tool. So Daf and I have spoken a lot about getting level one scanning in there, same with Simon for ZAP. It’s slow, I know there’s complexities, but I will still hound them and push them a lot.
John Verry (39:15):
That’d be great. So what’s next for OWASP four? I like your idea of stabilizing it. Is it increasing integration with the testing guide and the IOT top 10 and OWASP top 10? Is that what’s on your, let’s say, one to two year horizon?
Daniel Cuthbert (39:35):
Yeah, I think for me personally, and I can’t speak for the other chaps, the standard’s got to be easy to use still. It has to be representative of where we’re at when it comes to the internet and applications and how applications are used, it can’t be an old standard. So that’s where we’re constantly looking at ways as how stuff is changing, and technology does change all the time. And I know it’s very cliche to say that, but it really does. So we need to make sure that when a new X comes out, does the standard still apply to that, or do we need to adapt it? And that’s stuff that we are looking at behind the scenes.
Daniel Cuthbert (40:12):
There’s also working with all the other standards, like we’ve concentrated on NIST because we love NIST, but it was also trying to get the other standards that generally haven’t been more open. PCI. PCI, unfortunately is a pay to play. If you want to add input to PCI, you pay the money and then you can talk about it. And I’ve been quite vocal about that, I don’t think that’s helpful in any way. And that’s their world. I mean, the PCI do have their own application security standard, which I find boggling, but anyway.
Daniel Cuthbert (40:43):
So we’re trying to be more open and work with everybody and make it easier for them to consume, and for us to consume their stuff. But other than that, we’re relying on a lot of the amazing contributors out there to tell us where it’s not working, because it’s the feedback that we need from people is phenomenal. One of the biggest problems I guess we had was we didn’t know how people were using ASVS. We didn’t even know were people using ASVS? And I think we put out a request to say, “Hey, can you just maybe drop us a private note, say how are you using it?” And we were overwhelmed because wow, there are a lot of people using it.
Daniel Cuthbert (41:18):
And some of the feedback that we got from people has made it into the 0.1 release where they were saying, “Hey, this doesn’t work because of X.” We’re like, “Oh my God, you’re right. We never thought of that.” So yeah.
John Verry (41:33):
So question for you.
John Verry (41:34):
Yeah, it makes total sense. So if somebody listening is either interested in more actively participating or in providing that feedback, right? Do you guys have a Slack channel, is it all on Git? How would somebody who either wants to provide that feedback and/or wants to participate, how would they get involved?
Daniel Cuthbert (41:55):
There is a Slack channel, I believe, yep. You can mail, but again, with it being in Git, everything that you see from the ASVS standard, we’ve made as transparent as possible. So if you see an issue, and currently I see 46 issues, you can go to GitHub and say, “Do you know what? This particular issue isn’t working.” So I’m going to literally go in now, 13 days ago a person called [Banker 00:42:22] opened up where they said, “Some of the wording regarding the 12.3, which is file execution requirements in V12.5, file download requirements isn’t exactly right. Here’s my suggestion.”
Daniel Cuthbert (42:37):
We would look at that. If it’s good, we’ll either say, “Hey, submit a pull request and we will merge your change,” or we will change it ourselves. But you will see the entire history of that person, we’re not trying to hide anything. What they’ve said, our response, how we’re going to fix it is all done there, and I think that’s the best way because then we can’t ever be… said that we’re building a closed standard. Everybody has the right to change and make the standard better. So I’d say use GitHub, because it works really well.
John Verry (43:08):
Yeah, I’ve always referred to OWASP as what I refer to as an open trusted framework, because to me it’s community based. I don’t see anybody trying to do something proprietary, I don’t see any overt vendor influence which is pointing things in a direction. It just seems like a bunch of guys that really want apps to be more secure that are trying to do the right thing.
Daniel Cuthbert (43:31):
Yeah, and it is, and as one of the old farts at OWASP, I wouldn’t want a vendor to have any form of sway. I think this is where we’ve been quite strong. The main power version four of the standard was, even though there’s myself, Andrew, Jim and Josh and a few others leading it, the contributors and the community helped shape it. We were overwhelmed for people doing QA and just picking apart and doing amazing suggestions. Genuinely people going, “Hey, you don’t have this.” I was like, “Cool, do a pull request, that’s an amazing.”
Daniel Cuthbert (44:05):
And they’d write it and we’d format it and make it good. It’s in the standard and we’re not going to act as the gatekeepers. We just make sure it’s massaged and it looks good and it reads well. If you’ve got a good suggestion, it’s going in.
John Verry (44:17):
So I think we’ve I think we’ve accomplished goal. What do you think? Anything else you want to float about ASVS before we start wrapping this up?
Daniel Cuthbert (44:25):
No, again, I’d love to know how people use it. It’s been a passion [crosstalk 00:44:30].
John Verry (44:30):
Well, I can tell you we use it, I think, in the way that you would hope that someone would use it. And what we actually do is we lay out our application security testing to align perfectly with one of the four things that OWASP does, top 10, level one, level two, level three. We encourage people to move to level one at least where they can, because we think that that’s getting to a point where you’re really assessing enough of the security of the application to have a fairly high degree of assurance that the application’s secure.
John Verry (45:02):
And then really what we’re doing is we’re using the actual criteria within ASVS and/or any additional guidance that you provide in the testing guide to execute those to what you’re suggesting, and then provide that feedback directly to the customers and allow them to process that accordingly, and where the feedback is relevant and germane, make the appropriate changes to align with what you guys are doing.
Daniel Cuthbert (45:25):
I can’t tell you how happy that makes me because that’s exactly what we want. I’ve become very disheartened with how much of my own private data has been leaked on the internet through badly written applications. I feel like we all need to do a little bit more, and I think that’s where the ASVS can help. It just brings that level up a bit more because it’s just too easy to hack today, it really is.
John Verry (45:51):
No, I agree. And listen, I think the work that you guys done is amazing, and I think that it’s going to… I see the message resonating with people when we talk about it. They get it, right? We’ve put together some good guidance to help them understand the different levels, and they can look at it and they can say, “Yeah, I get what we’re trying to do, why we’re trying to do it.” And now really, honestly, I think the biggest challenge we’re having now is getting people to a point where they’re budgeting the right amount.
John Verry (46:16):
Because as you might imagine, an ASVS level one test is going to be more expensive than a OWASP top 10 test because of the depth and breadth of the testing.
Daniel Cuthbert (46:25):
Yeah, agreed.
John Verry (46:25):
So I think there’s a learning curve. I think you’re going to see an adoption that ramps, but I think the adoption needs to ramp based on education and based on people budgeting, honestly.
Daniel Cuthbert (46:38):
And like I said, GDPR, if America can get that, nothing makes budget more fully available than [crosstalk 00:46:45] operating costs. I’m sorry, operating turnover. It’s amazing, the money just flows.
John Verry (46:50):
That’s a really an interesting point, and I hadn’t thought it through to that level. Have you guys looked at, and is there any guidance out there that, if you will, maps the concepts within GDPR and CCPA to this? Or is there something beyond just the app being secure enough that someone can’t hack it within the testing guide, do you think?
Daniel Cuthbert (47:16):
So it’s one of the-
John Verry (47:19):
Stuff that’s specific to GDPR or CCPA as well.
Daniel Cuthbert (47:22):
It’s on my list. One of the addendums I want to do is map out GDPR and the rules behind GDPR, all seven of them, to specific ASVS levels. That’s the key thing.
John Verry (47:32):
Oh, that would be cool as… cool. Are you familiar with ISO 27701?
Daniel Cuthbert (47:37):
Not that one specifically, no.
John Verry (47:38):
Okay. Yeah, so ISO 27701 is a certifiable extension to ISO 27001, and what it does is it converts the information security management system into an information security and privacy management system. The only reason I point that out is that what it does is it genericizes the ideas behind all of the privacy frameworks, GDPR, CCPA, APAC, Brazil, Mexico.
John Verry (48:02):
And it breaks it down into what you’d expect, policy consent, all the elements of servicing a data subject, access requests, right to forget, data mapping, privacy impact assessment. So it genericizes that a little bit, so that way if you’re doing that mapping it’s not a GDPR mapping, it’s a privacy mapping.
Daniel Cuthbert (48:19):
Okay, nice.
John Verry (48:21):
Listen, ping me. I would be curious as to maybe be involved in that or review what you do, because it’s a lot of work there.
Daniel Cuthbert (48:31):
Okay, yeah, [crosstalk 00:48:31]. That sounds quite cool. Yeah, it’s more giving people the ammunition they need, and I think that’s where I see GDPR. It’s the stick that people now can’t ignore, and we’re all better for it.
John Verry (48:44):
Yes, and you’re helping the product manager, or even the development people manage their own risk that I don’t think that they’re fully cognizant of, right? Because they’re in the technical side of the domain, they’re not necessarily aware of legal and compliance risk associated with PI, which is very often in a legal and compliance office. It gives them that understanding, it bridges the ford between those two different areas, if that makes sense.
Daniel Cuthbert (49:08):
Yeah, yeah, agreed, agreed.
John Verry (49:09):
Cool. So we always like to have a little fun before we leave. So considering all of your exposure, which is quite extensive, give me an idea, a fictional character, real person, anyone who you think would either make an amazing or horrible CISO, or if you want to make that an application security leak, go for it.
Daniel Cuthbert (49:28):
Indiana Jones.
John Verry (49:28):
Indiana Jones. Okay, why?
Daniel Cuthbert (49:32):
I-
John Verry (49:32):
And you didn’t say amazing or horrible.
Daniel Cuthbert (49:36):
No, no. Actually, I think the Indy character would make an amazing CISO because they are naturally curious and don’t mind taking risks, something CISOs traditionally have been afraid of doing, and also understand there’s a big world out there and you can go and explore, and sometimes it’s not bad. I think the CISO world is definitely changing. So yeah, I think an Indiana Jones style CISO would be quite interesting.
John Verry (50:02):
Now let me ask you a question, I think that’s a very intriguing answer, and I think most people would look at a CISO as being a risk management function, and I think most of the time when we think of risk management we think of mitigating or reducing risk.
Daniel Cuthbert (50:16):
Yep.
John Verry (50:16):
You almost implied that at points a CISOs should be willing to take risk. I’m just curious as to what your thoughts are.
Daniel Cuthbert (50:24):
Well, let’s look at the start of the CISO role, right? CISOs came about turn of the century when businesses knew that they had to have somebody in charge of information security, right? Because it was now what people were doing. Where did they look for those people? In risk management, because techies were stupid, they were in the corner basement dribbling, right? So a tech is not management.
Daniel Cuthbert (50:48):
There was always that thing when I started, you were either techie or you’re management. I’m a very technical cybersecurity director, so the roles have blended, but traditionally CISO as a voice come from a risk management thing, which means nervous Nellies, right? But if we look at modern businesses, unfortunately security is always the one saying no. Security is always the one that’s stopping business moving. And what I’ve learned is that that’s the worst thing you can do, because businesses will move past security because like you said, you’ve got to look at the bigger picture.
Daniel Cuthbert (51:22):
And I think that’s where the modern CISO for me is someone who still understands the risks, but can also understand that the business needs to grow, it needs to evolve. We are in the most amazing time right now. Yes, this virus is awful and it scares the crap out of me, but it’s doing one thing that I’ve tried to do for nearly two decades. We’re now seeing the fact that we built networks like old castles, where everything was on prem, as a pretty crap decision.
Daniel Cuthbert (51:51):
We’re now seeing that, “Hey, remote working with access to it in a secure way at times of global crisis has to happen.” And it’s taken this, where people are now going, “Okay, maybe yeah, we should actually allow people to do this.” And I think that’s where CISO will change in the future, where they’re going to go, “Do you know what? Yes, let’s do it, but let’s look at ways of making sure it’s secure.” Not, “No, we’re not doing it because the risks are too high.”
John Verry (52:14):
Right. So risk management is not about minimizing or… actually I shouldn’t say this, eliminating risk, because eliminating risk is impossible. We’re going to limit risk, it’s a matter of making intelligent decisions about that risk.
Daniel Cuthbert (52:25):
Yeah, yeah.
John Verry (52:26):
Yeah, makes sense. Last question, so you chat every day in the business world about application security and information security as a whole, privacy. Any ideas for future topics that you think would be interesting for another episode of the podcast?
Daniel Cuthbert (52:42):
Yeah, if I go back to what I just said, I think the remote working zero trust, how do we enable a workforce to continue making the business evolve where you have to do it from anywhere? I think we’ve been skirting with the idea for a while, but we never had a reason to think about it. And I think this last two, three weeks has made a lot of people realize, “Wow, there’s a lot that needs to happen,” because we still rely on VPNs, and they’re awful and they don’t work and they’re slow.
Daniel Cuthbert (53:14):
So it’d be interesting to see what comes out of this crisis to see how are we going to change the workforce, because I think our way of life has changed. I don’t think we’re going to go back to the old ways. So how has IT and IT security and technology going to change to make this a lot easier?
John Verry (53:31):
That’s an interesting perspective. So you think… Clearly this is going to have longterm ramifications in terms of the way people look at things, right? I think the concepts of business continuity need to be improved, I think the concepts of understanding supply chain risk need to be improved, and that’ll tie into of course third party or vendor risk management as well. But beyond the planning and preparing for those, you think it’s going to have more broad reaching implications than that?
Daniel Cuthbert (54:00):
I do. I think we always had this idea that in order for you to do a job, you’ve got to drive to an office, park up, do that kind of thing. My team for example, I don’t have office hours, people work when it best suits them. Some start work at 3:00 PM and they work until 2:00 AM, some start work really early and finish early to play with their kids, and I think that we were definitely the fringe, that we were unusual.
Daniel Cuthbert (54:25):
Why would you want to work from home? Because people are different. And I think what this is now proving is that we never built systems or applications or stuff that allowed for that in a secure way, and there’s a lot of eyes being opened at the moment going, “Wow, this can actually work.” We can maybe change stuff, and I think that will be the big spark of creativity and discussions with boards and IT managers and architecture saying, “How do we do it where if the office disappears tomorrow we can still work in a secure way?”
John Verry (54:55):
There’s a lot of real estate companies that are not happy to hear you talking this way, you realize that?
Daniel Cuthbert (54:58):
Oh yeah. I’m in London where it’s impossible, we’re constantly full. It’s impossible to get office space. Booking a meeting room is a three week thing. You’re like, “Come on.” Yeah, so there’s a lot of estate agents who are getting very angry, but sorry, you know…
John Verry (55:14):
Yeah, exactly. All right, well listen, before I say farewell, how can folks get in contact with you, or get in contact with OWASP if they’re interested?
Daniel Cuthbert (55:27):
OWASP is easy, hit the OWASP.org site, they are quite good. There is a Slack, massive Slack presence there now. I’m just trying to check where it is on the website. It is definitely on the website, the website’s just changed. Myself, probably the easiest thing is Twitter.
John Verry (55:39):
Mm-hmm (affirmative), what’s your handle?
Daniel Cuthbert (55:44):
@DCuthbert.
John Verry (55:44):
C-U-T-H-B-E-R-T?
Daniel Cuthbert (55:47):
That’s right.
John Verry (55:47):
All right, excellent. Well as always, thank you. I genuinely enjoyed the conversation, definitely appreciate it, and really, truly appreciate all the great work that you and the rest of folks are doing on ASVS. To me, it’s must use.
Daniel Cuthbert (56:01):
Thank you. I really [inaudible 00:56:03] thank you, and sorry for all the messing around.
John Verry (56:06):
Hey listen, like you said, it’s a brave new world, right?
Daniel Cuthbert (56:10):
Yeah, it is.
John Verry (56:11):
All right, thanks Daniel.
Daniel Cuthbert (56:11):
Have a good one, be safe.
Speaker 1 (56:13):
You’ve been listening to the virtual CISO podcast. As you’ve probably figured out, we really enjoy information security, so if there’s a question we haven’t yet answered or you need some help, you can reach us at [email protected]. And to ensure you never miss an episode, subscribe to the show in your favorite podcast player. Until next time, let’s be careful out there.
