November 17, 2020

SaaS is a great business to be in. 

But whether you’re a startup or a mature company… 

Your product is only as good as your security. 

Today’s guest, Ryan Buckley, has advised SaaS firms for a number of years. He joins me to discuss how to address SaaS security and keep your product — and reputation — secure. 

What we talked about:

  • Why code repositories are an issue
  • Why product security is as important as infrastructure security
  • Senior leadership’s role in security.

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.

Narrator: (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 Stimpy to my Ren, Jeremy Sporn. Hey, Jeremy.

Jeremy Sporn: (00:38)
I’ve been called a lot of not-so-pleasant names in my lifetime, but for some reason, Stimpy just stings a little more than most.

John Verry: (00:46)
Yeah, Stumpy would have been worse. But we’ll stick with Stimpy. But I just had a quick question for you before we get to the episode.

Jeremy Sporn: (00:52)

John Verry: (00:54)
You haven’t recorded before in a hat. Is that a conscious choice?

Jeremy Sporn: (01:01)
You couldn’t help yourself. Apparently, my hair was pointed up like Dan Aykroyd, and the only way to fix it in time for us to record this episode was to throw a hat on.

John Verry: (01:11)
Oh, that was fun. What’d you think about our conversation with Ryan?

Jeremy Sporn: (01:19)
Well, like this conversation, I really enjoyed the conversation we had with Ryan. It was cool to hear some of that strategic guidance for SaaS firms around start with the fundamentals and build from there, going through those fundamentals, why they’re important.

Jeremy Sporn: (01:37)
And then when you guys got into some of those, what I would call practical guidance or tactical guidance, from Ryan’s own findings, the struggle that many SaaS firms have to implement good controls around their code repositories or repose, as he calls it, that was a new one for me. I’m learning more and more each day as we work with more SaaS firms, we talk to more SaaS firms, listening to Ryan talk.

Jeremy Sporn: (01:59)
The relationship a SaaS firm has with security is just very unique.

John Verry: (02:04)
Yeah. No. I agree. And I think that’s one of the reasons we’re lucky to have Ryan on our team. He worked, prior to joining us, I don’t remember the exact title, but think of him, he was a chief applications security officer for a SaaS of note before he joined us.

John Verry: (02:18)
So it really puts him in a perspective and in a position to discuss SaaS security from a really nuanced and knowledge perspective, and I think that’s what you took from the call. Excuse me, from the meeting.

Jeremy Sporn: (02:30)
Absolutely. And whether you’re in that startup phase or you’re a little bit more well-established, security is a challenge in the SaaS world. Ryan, like you said, who has worked with SaaS firms, was in a SaaS firm, and now is responsible for assessing and helping them to implement security programs, he’s just a wealth of information security knowledge for any of these SaaS firms, whether, like I said, you’re in that real early growth stage or further down the line, and is great at helping them understand how to win that security game. That’s what it feels like sometimes. It’s a game you need to win.

John Verry: (03:02)
Mm-hmm (affirmative)-.

Jeremy Sporn: (03:04)
Anyone who works at a SaaS or is concerned at all about security within their SaaS will find this extremely valuable.

John Verry: (03:10)
Yeah, I agree. Yeah, that was definitely the idea of having him join the show. So with no further ado, let’s get right to it.

John Verry: (03:21)
Ryan, thank you for joining today. How are you, man?

Ryan Buckley: (03:24)
Hey, John. Good, man.

John Verry: (03:27)
This finds you up on the Cape?

Ryan Buckley: (03:29)
Yeah, yeah. Finally got some good weather. It’s been ridiculous lately, but the hot weather is finally moving through and it’s 75 and [crosstalk 00:03:37]. I’m anxious to get this meeting over with so I can go outside.

John Verry: (03:42)
Well, great way to start. I’m here, but I really don’t want to be here [crosstalk 00:03:47].

Ryan Buckley: (03:46)
No, I’m kidding. John, I’m kidding.

John Verry: (03:48)
So, all right. So let’s start easy. Tell us a little bit about who you are and what you do. And of course, I know that, but the folks listening don’t.

Ryan Buckley: (04:00)
Yeah. So I’m a long-time information security officer type. I’ve been in a few different industries, a lot of time in banking, a lot of time in healthcare. And in the last six or seven years, I’m working with software companies. I’m very, very adept at software development best practices and hosting best practices, and I’ve always enjoyed looking at the security aspects of how products are made. So that’s why I’ve gotten into it in the last six, seven years or so.

John Verry: (04:31)
Cool. And that’s a good introduction because that’s why you’re on today’s episode, because the concept of the episode was we thought about having some SaaS’s of ours, because we have a ton of SaaS clients on the show to talk about some of the things they don’t want to talk about, which unsurprisingly, they didn’t want to talk about.

John Verry: (04:49)
So we brought our man Ryan on, who had a lot of SaaS experience prior to that and then works with a lot of our SaaS clients now.

John Verry: (04:57)
So I always like to start with a fun question. What’s your drink of choice?

Ryan Buckley: (05:05)
Depends on the season and depends on who I’m with. In the summer, I love a tequila. Casamigos is hot right now. But in the winter, I’m a bit of a whiskey guy. And I actually prefer the cheap stuff. I’m a Johnny Red man.

John Verry: (05:21)
Johnny Red, is that more an Irish whiskey, or is that more … is it a rye? Is it a bourbon? Is it a [crosstalk 00:05:28]?

Ryan Buckley: (05:28)
It’s a scotch whiskey.

John Verry: (05:29)
It’s a scotch whiskey?

Ryan Buckley: (05:30)
Yeah [crosstalk 00:05:31].

John Verry: (05:30)
I think you did tell me that. You guys that drink the whiskey with the [inaudible 00:05:33] in it, that ruins a good whiskey. Go bourbon, my man. Go bourbon. Go winter weeded. [crosstalk 00:05:39].

Ryan Buckley: (05:38)
I’m chubby enough.

John Verry: (05:42)
All right. And I will ask one question, only because … So one of my favorite breweries in the world is up in your neck of the woods. Have you ever drank at Cisco Brewery or ever had any of their stuff?

Ryan Buckley: (05:54)
Cisco? Yeah. Down in Nantucket. Yes. I’ve sampled it. The Great Lady is my favorite.

John Verry: (06:01)
Yeah. They had a stout, an oyster shell stout, that was really, really good. We were on Nantucket a couple of years ago, and that is a blast of a place to go to. If anyone has a chance to go to the Cisco Brewery in Nantucket, it is an awesome place, because they got the distillery there and they got food trucks and they got music playing and there’s people with dogs. It’s just … It’s a great [crosstalk 00:06:25].

Ryan Buckley: (06:25)
Yeah, absolutely. Just go it easy so you can remember it.

John Verry: (06:29)
Yeah. At my age, I got to go easy. There’s no choice. All right. So talking about SaaS’s, where do we want to start this? Do we want to talk about some of the issues that they struggle with?

John Verry: (06:40)
All right. So let me ask it this way. So software companies, SaaS’s specifically, from your perspective, do you think most of them are doing a good job of protecting their dev and/or production environments?

Ryan Buckley: (06:53)
It’s an involved answer, and I think this is a great topic for a podcast, because you’re right. A lot of companies who are mature and have had software hosted in on-prem solutions out for some time are still not mature in certain aspects of how they make their software.

Ryan Buckley: (07:16)
And then we’ve experienced, in our role at Pivot Point, interfacing with younger companies who have very good security when it comes to their production environments and even the development environment from an infrastructure management perspective.

Ryan Buckley: (07:33)
But when it comes to the tools, the essential tools needed to make software, your actual development environments that people are coding in, your task management systems, I have found that there’s an alarming level of people who are not as effective as they should be in protecting those applications.

Ryan Buckley: (07:55)
So are companies doing a good job in securing their development and production environments? Yes, for the most part. I think so. But I limit that response to security of the infrastructure and network and not necessarily the applications they use to develop or plan their development. Some companies are very secure, but some just have a lot of room to mature.

John Verry: (08:24)
So let me ask a question. So one of the things that I see affected is funny, because I literally, an hour ago, was on a call with a two-person startup handling HR data that has already … They’re doing something really special, I guess, because they’ve got a couple Fortune 20 companies.

John Verry: (08:38)
And of course, now, they’re starting to get the security questioners. And it’s two guys, and their answer to me was, “I don’t know why they’re asking for this security stuff. We’re in AWS. That’s secure.”

John Verry: (08:49)
So let’s talk about that, right? Because I … Look, the good news these days is that I think parts of everything everyone is doing is secure for the most part, if they configure it properly, let’s say.

Ryan Buckley: (08:59)

John Verry: (08:59)
Because they’re in Azure or they’re in AWS. Agree with that statement?

Ryan Buckley: (09:03)
Yeah. Yeah. I think most of us who are proficient with these Cloud environments do realize that part of the reason people go with Azure, AWS, or IBM is that there are definitely inherent security benefits. Their BCPDR postures, for example, are exceptional on an inherent level and also in a level the customer can use with regioning and availability zones and all that.

Ryan Buckley: (09:38)
There’s also other defenses in place that protect Azure or AWS or other Cloud providers as a whole, like anti-DDoS. The perimeter networks that protect and our common to multiple customers are jack full of capable solutions that fend off a lot of those threats.

Ryan Buckley: (10:00)
But we also know that AWS and Azure and other Cloud platforms are, in fact, that. They are a platform. And there’s a whole range of responsibilities that you have as a user living in Azure or AWS they do need to execute on. Access control of your environment, network security, the realm of network security that is available for you to configure, from security groups to virtual web application firewalls to elastic load balancing et cetera, all of that’s in your hands.

Ryan Buckley: (10:40)
Amazon or Azure and Microsoft, they don’t control that stuff. That’s up to you to configure. And if you don’t do a good job effectively configuring and maintaining those components with correct configurations, there’s a whole lot of risk that can enter your hosted software package or your development environment, if you’re developing on prem software.

John Verry: (11:03)
Yeah. You’re talking about one of my favorite buzzwords right now, who I want to chat with these clients, this shared responsibility. And there’s that classic chart that Microsoft put out a few years ago where you got the nine domains and the top is user access. It’s users, and down at the bottom is more network infrastructure. And then depending upon whether it’s function as a service, server-less computing, platform as a service, software as a service, right, you own different percentages of the risk and the controls. Correct?

Ryan Buckley: (11:33)
Yeah. Yeah, absolutely. AWS did an amazing job of articulating it when that concept or principle or responsibility model issue first came on scene a number of years ago. And I think they very wisely … they did an effective job of promoting the fact that, if you as the customer don’t do your part, this whole thing fails.

Ryan Buckley: (12:02)
So that shared responsibility model is, I think, certainly one that most Cloud providers have adopted. And I think it does an effective job of helping the customer understand, “We, Microsoft, or we, Amazon, we’ve given you a whole collection of tools. And if you don’t use them, all the other work we did is for naught.”

John Verry: (12:25)
But so here’s a question. So I agree with you that they’ve communicated it. Has it been effective? When you see the number of S3 bucket issues that are floating around, the question is, “Has it truly been effective?”

John Verry: (12:39)
They’ve communicated the shared responsibility, but I got to be honest with you, when I chat with people, I’m not sure that a lot of our clients are fully getting it.

Ryan Buckley: (12:49)
Yeah. It’s a great point. I think all of the clients who operate environments in those Cloud platforms have heard about the responsibility model and they know it’s up to them to do … that they have a responsibility to do their part.

Ryan Buckley: (13:08)
But do they do it all the time? No, absolutely [crosstalk 00:13:12] not.

John Verry: (13:12)
And look, I don’t know about you, but every time that … I don’t spend much time in AWS’s tools. But even just going into Microsoft’s tools relating to Office 365, you go into these portals, and every time you go in there’s new tools, new capabilities, new functions. It becomes a … I don’t want to call it a full-time job. But if you are not committed to it, if you’re not investing in it, it’s really hard, I think, to know that you’re secure, because it takes a lot to ensure that you’re doing everything right.

Ryan Buckley: (13:43)
Yeah, we’re describing the advent of dev ops. There was a time when it was normal for a software development team to write code and create a software offering and deploy it to a Cloud environment and operate it.

Ryan Buckley: (14:01)
But as you’ve just described without using the words development operations or dev ops, there’s a whole career associated with the planning, implementation, maintenance of development and production software environments that is a true specialty.

John Verry: (14:22)
That’s interesting, and this is why I brought you on, because I would not have thought of that as being dev ops in the traditional sense. I think of dev ops as being more of that automation of the provisioning of this stuff as opposed to actually the securing of the stuff. So it’s interesting that somebody who’s in the business more so than me, right, you live both sides of the fence, that you actually consider that element to be part of that dev ops stack, if you will.

Ryan Buckley: (14:47)
Yeah. I’m reminded that security is an element in everything we do. And when I say we, I mean software developers. You can’t and you shouldn’t develop a product without thinking about security. As a dev ops person who runs, say, a development or a production environment, there’s no way you can do that without thinking about security.

Ryan Buckley: (15:10)
So when I said dev ops, I was thinking about not only the infrastructure management point of view, but also the security point of view that goes along with that securing of virtual infrastructure, making sure that the scripts that you use to expand your capacity when needed dynamically are written securely so that nobody could ever mess with it et cetera.

John Verry: (15:35)
Got you.

Ryan Buckley: (15:35)
So yeah, that whole dev ops world is very, very incomplete if you don’t think about security when you talk about it and plan it.

John Verry: (15:44)
Got you. So I only have a rough agenda that we talked about, but I also want to ask you questions to make even jiggering our … Because as we’re talking, I’m thinking about this idea. We use the term security, and security is an interesting word, because in a SaaS, right … Right now, we just talked about the security of call it the Cloud infrastructure, right, for a loose term.

John Verry: (16:05)
Then, you’ve got the security of the application that we can be talking about, right? Then, we’ve got the security of the dev processes that we can be talking about. And then we’ve got the security of the other business operations that are touching that same data and are integral to our … If your HR practices aren’t good, you might hire the wrong people, you might … your people might not be trained or vetted properly.

John Verry: (16:28)
Software lives in an environment, the data goes into that environment, but very often, that data is brought out for analysis or for troubleshooting or for processing or for consultative purposes.

John Verry: (16:37)
So when you answered the question, I asked you the questions, “Are companies doing a good job?,” were you talking about that from all of those perspectives? And if I asked you to talk about those different perspectives, would your answer have been different?

Ryan Buckley: (16:52)
Great point. It’s a very big world, isn’t it? Just within the security world and within a smaller company, it’s a very large landscape. And there are multiple categories within it, as you just recited, from your business applications that you use to run the company to your development tools to your back end infrastructure administration to the actual end user and account administration that the customers of your products use.

Ryan Buckley: (17:24)
When we talked about that a little bit earlier, I was zooming in on tools, the tools that software developers and software dev ops professionals use when operating and maintaining the development environment in which developers code and all the tools associated with that as well as deployment infrastructure that helps bring that code to life and launches it for customer use. That’s what [crosstalk 00:17:53].

John Verry: (17:54)
All right. So let’s drove down a little bit more on that then, right? And then maybe we’ll pivot to some of the other stuff.

John Verry: (17:59)
So when you think about that near that tool stack and I’ll call it the actual dev ops stack, dev ops world, right? So where are we seeing … So from a mason person’s perspective, mine, the buzzwords that I hear are move security left and, increasingly, I’m hearing this concept of, what do they call it, reg tech, where can we get the regulatory and security functions baked into our pipeline.

John Verry: (18:28)
Can you talk about those things?

Ryan Buckley: (18:30)
I think so. I think so. Let me expound upon what I was talking about earlier, and I’ll move in the direction of what you just talked about. And you can let me know if I hit the mark.

John Verry: (18:42)
I’m not smart enough to tell you if you did hit the mark, so just tell me you hit the mark and I’m going to believe you.

Ryan Buckley: (18:51)
All right. All right. Here’s the mark. So what I was talking about before is, when a lot of companies look to establish a sound information security program, they align themselves with one of the frameworks, SOC2 or ISO 27001. And usually, the efforts they put forth in securing their environments, one, to be secure and get compliant and be able to answer those questionnaires, too often, those efforts are focused solely on the infrastructure, meaning the company network, the company servers, whether they’re metal or virtual et cetera, and network access, active directory, security groups, things like that.

Ryan Buckley: (19:35)
I have seen in my time that too often, that that’s where those efforts stop. And it’s very intriguing because I think some companies … Look, it’s a ton of work and I recognize that. But the most important thing to a software company outside of its revenue is its code. That’s the jewelry box, right? Your intellectual property is the most important thing.

Ryan Buckley: (20:02)
And when developers develop and create that code, they … Many of us know, if you’re listening to this podcast, you’ll know that your code repos are vitally important. And whether it’s GitHub or Subversion or Perforce or whatever kind of repo you use, I’ve seen too often that the security of those code repositories is just not adequate. You got 17 people with admin access to those repos. You don’t have enough logging activated. So if somebody screws something up, either maliciously or by accident, you can’t find your way back and you get no breadcrumbs.

Ryan Buckley: (20:40)
So what I’m talking about is the prudent configuration and securing of the applications that the developers use and the code repositories being the immediate thing that comes to mind. A more mature model would be integrating one of those solutions with your active directory or your Google directory, whichever you use, so that you can take advantage of any standards you’ve implemented, access control standards, password complexity, multi-factor authentication, and all that.

Ryan Buckley: (21:11)
But my message here is it’s been startling to see how many companies, small and large, have slightly less secure posture with their code repositories as compared to their general network security. And I’m obviously referring to situations in which those code repos are not yet integrated into the company directory.

Ryan Buckley: (21:35)
So that’s one thing that’s alarming that all SaaS and software companies should look at and make sure that they pay very close attention to, because that’s the jewelry box, right?

John Verry: (21:46)
Mm-hmm (affirmative)-.

Ryan Buckley: (21:47)
The other thing [crosstalk 00:21:48].

John Verry: (21:48)
… question, too, is, if you don’t have good control over your code, that means you don’t have good control over what’s being pushed in the Cloud, which means, logically, you don’t have good security of your … You don’t have assurance that the application’s going to maintain a high level of security, which means it might be breached, which means now, not only do you have a code concern, but you might have a client data concern, which …

John Verry: (22:10)
So to your point, revenue and intellectual property are the two most important things. If you don’t protect the intellectual property, we’re not protecting the revenue logically, right?

Ryan Buckley: (22:19)
Sure. You’ll bleed. Right.

John Verry: (22:21)

Ryan Buckley: (22:21)
Somebody will grab a hold of that stuff and use a big chunk of your stuff in a different product and steal your dough.

John Verry: (22:28)
Or you got some … Or somebody pushed something into the environment that shouldn’t be there, causing a breach.

Ryan Buckley: (22:35)

John Verry: (22:35)
And now, we’ve got breach notification, we’ve got the loss of client revenue on top of that. That’s your reputation on top.

Ryan Buckley: (22:40)
Yeah. That’s even more nauseating, is the potential reputational impact.

John Verry: (22:45)

Ryan Buckley: (22:45)
You work for years to develop a product and a reputation, only to have it stolen from you so quickly.

John Verry: (22:51)
Got you. Where else in that development stack do you see [crosstalk 00:22:57] concerning points?

Ryan Buckley: (22:58)
A few spots. Separate from the code repo is the planning around it, whether you call it agile applications, planning applications, task management applications. What I’m talking about is the market sector that helps developers plan. And whether that’s Confluence and Jira or GitHub Tasks, often a replacement for that, or Azure DevOps, people do a lot of planning and management there.

Ryan Buckley: (23:30)
If the security of those environments is weakened and somebody, a contractor who is helping you out for a month, turns out to be … turns out to have a malicious bone or two in his body, has unnecessary access to what you’re planning, all your design work is leaked. So that’s another jewelry box of IP that you don’t want leaked. What you’re doing, what you’re building, how you’re going about it, the entire project plan on how you’re developing your products is right there.

Ryan Buckley: (24:03)
So your task management systems, your agile stack management systems, whatever you want to call it, it’s essential that those work platforms be secured as well. Get them integrated into your company directory, AD or Google or JumpCloud or OneLogin, whatever you want to use.

Ryan Buckley: (24:22)
But I’m seeing when those … If you’re a larger company and you want to leave those applications as standalone and leverage the local security for those ops, that’s fine, as long as somebody’s going to pay very close attention to it.

Ryan Buckley: (24:38)
But if you’re a smaller company and everybody’s wearing a lot of hats, try to get that stuff integrated into your central company directory, activate MFA. It’s usually right there to turn so that people’s phones get buzzed when they’re logging in. People will only complain for a couple of weeks. Then they’ll get over it.

John Verry: (24:57)
Interesting. So that’s another whole … And it is interesting. That’s another whole branch of this security question. And then so another branch that we wanted to talk about was product security, I’ll call it, for lack of a better term, because when we talk about information security, it is interesting that you’re increasingly … And I know you and I have been on a couple calls recently with clients where we’re using the term and clients are using the term product security to talk about their applications.

John Verry: (25:20)
So if I asked you the question, would you think that most SaaS companies are doing a good job with the security of their actual products, specifically whether hosted or on prem?

Ryan Buckley: (25:30)
Mm-hmm (affirmative)-. It’s all over the map, and that’s why it’s so important to do good upfront diligence when you’re a consumer of software, whether it’s on prem or in the Cloud. Kicking the tires of the vendor to understand how they develop is really, really important.

Ryan Buckley: (25:50)
It’s very important when you are a software company that, not only do you apply security fundamentals like vulnerability scanning and penetration testing to your operating environment, your infrastructure, your servers, et cetera, but you’ve got to apply that same rigor to the products you’re building.

Ryan Buckley: (26:13)
It is not cool to just create a software product that you think is terrific and is going to help people without examining and fixing the security issues along the way throughout the development process.

Ryan Buckley: (26:27)
So when I say product security, I can mean a number of different things. But in this context, having a game plan to do security scanning at the code level, and I’m talking about tools like Vericode or Fortify or IBM AppScan, you’re using those tools to assess your code. And then, even if it’s on prem software, stand up an instance of the stuff and do a vulnerability scan of it to see what you see without any network level security defenses there. It’s really … It’s easy to do. There’s really no reason software companies shouldn’t be doing that.

Ryan Buckley: (27:07)
So yeah, I have seen in an alarming, not trend, but a pattern, I guess, where a software company or a SaaS company will have very, very good infrastructure security. They’ll do their vulnerability scans and pen tests and remediation work. But they really do need to apply all of that rigor to their own products as well.

Ryan Buckley: (27:31)
When you scan something on your network and you find a vulnerability, usually your IT guys are patching that real quick. Say Microsoft patch Tuesday, everything’s getting patched, or a Cisco device has a vulnerability or upgrade in the OS. The same thing needs to be done for your software. You’ve got to routinely scan the products you’re selling. And as a customer, you need to be asking your software vendors, “What is the testing comprised of?”

Ryan Buckley: (28:03)
And when they find a vulnerability, what’s the model they use to prioritize delivery of fixes? If they find something real bad, how long is it going to be before they deliver a patch. Or as a customer, is the customer going to be asked to wait for the next major release? When’s that going to be? Sixty days? One hundred and twenty days?

John Verry: (28:24)

Ryan Buckley: (28:25)
So as a customer and as the SaaS company, it’s very, very important to think about the security of the actual product and applying the same level of vulnerability management energy and procedure and tooling to your products themselves.

John Verry: (28:43)
Got you.

Ryan Buckley: (28:44)
And I’m ranting, but it’s an important topic.

John Verry: (28:47)

Ryan Buckley: (28:47)
And as a customer, you’ve got to be on your toes and challenge even a software company you think is a real prominent one about the software quality and the security of it.

John Verry: (28:59)
Okay. So let me ask you a couple questions here. So let’s say Pivot Point’s about to go out and license a SaaS and we’re going to put what we call client confidential information up into there. If I came to you and I said, “Hey, we’re going to go … I’ve got company A and company B. They offer virtually identical product. This company says they have ISO 27001 certificate or a SOC2 Type 2 ServiceNow report, but I didn’t get a warm and fuzzy about what security test they do in the application.” And I said, “This client over here has an OWASP ASVS level two assessment done that looks fantastic, but they don’t have a SOC 2 report or an ISO certificate,” which way would you lean?

Ryan Buckley: (29:41)
Well, the clients with [crosstalk 00:29:42]. Yeah.

John Verry: (29:43)
But if I can’t get both.

Ryan Buckley: (29:47)
If you’re a smart customer, you want both. You want to see these SaaS companies in the possession of a SOC 2 Type 2 or an ISO 27001 certificate. But if you are not able to achieve a confidence level via that alone, you can ask these companies openly what software excellence communities or authorities do they follow.

Ryan Buckley: (30:15)
There’s the whole OWASP approach. And if you’re a development house and you follow OWASP, for anybody who’s not heard of it, it’s O-W-A-S-P. Just Google it and check it out. That’s become a mainstay in development security. There’s also BSIMM you can check out. I believe it’s B-S-I-M-M. The BSIMM community [crosstalk 00:30:43].

John Verry: (30:43)
… security into … Building Security in Maturity Model, I think it stands for.

Ryan Buckley: (30:46)
Yeah. So you don’t need to corner your software vendor or your SaaS provider into answering whether or not they are compliant with either of those, BSIMM or OWASP. But invite them to talk about what best practices they do follow. And if they’re a deer in the headlights and they don’t know what you’re talking about, just throw out BSIMM or OWASP and, “Do you guys use any of these schools of thought, these frameworks, to get your products more secure than they would be otherwise?”

John Verry: (31:17)
Mm-hmm (affirmative)-. Question for you. So when we use the term product security, we talked about Cloud security, right? Which I think is part of product security. But then is the rest of it largely the SDLC?

Ryan Buckley: (31:30)
Sure. Yeah. You’ve got to have established methodology in place. One of the unfortunate, but normal and natural aspects of a hot, young company is that the quality and security of the software depends on the talent of the people coding.

Ryan Buckley: (31:46)
And that’s great. It’s great that every company is young once and every company is without procedures and consistency. But at some point in your growth as a software company, you do need a software development life cycle, a secure software development life cycle, that establishes a methodology for the developers and dev ops people, if you have them, or maybe the same guy is wearing both of those hats, where there are rules established on how to quality check your code, when, at what stages do you need a peer review by another developer, at what stage do you need to run a code security scan, under what circumstances can you promote code up the tree or promote something to production.

Ryan Buckley: (32:37)
We don’t want single people doing any of those above average risk type maneuvers, writing a key piece of code and putting it in product without getting the approval of a peer and a supervisor.

Ryan Buckley: (32:52)
So what I’m talking about is having documented via company policy or team level procedures some rules of the road, a development methodology and establishing the bumpers on the bowling lane for the developers to stay within. And they need to understand the rights and wrongs of software development.

Ryan Buckley: (33:11)
It is not appropriate to write something that’s incredible and promote it because you know it’s incredible. You’ve got to take some time to look at it, stare at it, stand on your head, scan it, have somebody else look at it.

Ryan Buckley: (33:23)
And that’s what your SDLC is for. When you grow and you have some success, you don’t want to be training every single person that comes through the door over and over again. You want to make them read that SDLC as part of their orientation onto the team.

John Verry: (33:38)
Yeah. So while I’m … So it was interesting. I don’t know if you have a chance to listen to the podcast we did with Jim Monaco from Monaco Security. He’s the guy … a great trainer. He’s head of the OWASP … Which project? The … Not Top 10. That’s Andrew. Not …

John Verry: (33:56)
He’s a significant person on the OWASP ASVS project. And we chatted about this. And one of the things we talked about it was very good, that he talked about, and this is probably relevant to the people that are in management here, is that management has an obligation to govern the operation to software development. Just because you’re a product guy or just because you’re a business owner doesn’t mean it’s not your responsibility to make sure that your teams are doing the right thing.

John Verry: (34:20)
And you don’t have to be a guru to do that, right? Like you said, if you turn around and say to your team, “Guys, be aware of OWASP Top 10. Be aware of the OWASP guidance. We’d like to use OWASP ASVS as guidance,” and you give these people these tools and frameworks and say, “Please follow these,” right? That’s all management really needs to do to get the ship going in the right direction.

John Verry: (34:42)
Perhaps some training, right, for software security training? A little bit of training goes a long way, I think, with this stuff.

John Verry: (34:50)
And then the other thing, too, that I … And you mentioned this, and I’m a huge believer in, is if you can build some form of software code validation into your dev cycle and do functional unit testing of each individual branch of code and then when it comes together, I think you’re a long … you’ve made significant progress towards getting to where you need to get to, right?

Ryan Buckley: (35:14)
Right. Right. Exactly. Yeah. This is … It prompts the thought that we often talk about and think about in ISO 27001 context. It’s the tone of the top, right? It’s is the senior leadership living security?

Ryan Buckley: (35:32)
We all know that senior leadership is hellbent on innovation and business development, as they should be. That’s the health of the company, and without that, you got nothing, right?

Ryan Buckley: (35:42)
But they also need to think about security because it’s such a big threat. It’s a threat reputationally. It’s a threat to the trust of their customers.

Ryan Buckley: (35:51)
And you’re right. They need to be involved not just as a hood ornament, but as a real influencing factor over the program when it comes to resourcing. Senior leaders need to ask their people, “Are you doing okay? Are you too thin? Are you wearing too many hats? Should we invest in more people?” Those questions need to be asked by senior leadership.

Ryan Buckley: (36:14)
Funding, smaller companies, you got to run lean, maintain profitability. But sometimes, there’s a fork in the road. You’re either going to buy the right tool, do the right thing, or you’re not and you’re going to keep winging it. And there’s important decisions to be made along the way about those investments, and the leadership, in controlling the budgets, need to be involved in that.

Ryan Buckley: (36:39)
Risk management, even smaller companies, they need to strategize and implement a risk management program and very quickly think about senior leadership when it’s necessary to accept a risk or accept that you’re not going to fully mitigate a risk. Senior leadership needs to be informed. They need to understand what the risks are and weigh in from their perspective on whether or not it’s okay to accept a risk and live with it. You need to that leadership perspective.

Ryan Buckley: (37:10)
And you’re totally right about the training from a budgeting point of view, but also an evangelism point of view. Most companies will have a town hall meeting or an employee meeting every so often, and it should be evangelized in those meetings that everybody needs to take security training, general security awareness, and/or developer training. There are a lot of risks and threats to the company when it comes from being duped by a phishing email that results in the loss of money or reputational impact or something worse.

Ryan Buckley: (37:46)
The developer education piece is huge, and ongoing education is very, very important to the health of the program. And sometimes, that stuff is not going to happen unless senior leadership is involved, because even an engineering manager in charge of a development team will get hyper focused on innovation and go months thinking functionality without thinking security. And it’s the leadership that’s going to have the clarity of mind to intervene and make sure everybody’s heads are staying on straight.

John Verry: (38:18)
So one last question, and it just occurred to me as I was listening to you talk. Increasingly, we’ve been having conversations around product security. And I think that’s actually important, because I think it differentiates that information security as a whole for the organization and product security.

John Verry: (38:32)
But I think that one danger about product security, using that term, is that, at the end of the day, it’s about data security. Really, at the end of the day, the risk is associated with the information in that application. And I think what happens is that one of the risks that I see is that we’ve hyper focused on ensuring that the data, when it’s in our Cloud environment, is being secured appropriately and we build this really fantastic enclave of security. But we fail to recognize that that data, that enclave is being accessed through privileged developer networks on occasion, and what is the segregation there? What is the way that we’re doing access control?

John Verry: (39:12)
And then the second thing is that we see that data leak out of that environment, right? So it might leak from a Cloud to a dev or a staging or a QA environment, and/or we’ve got people who work for the organization that may be accessing that data to generate reports for clients, to do statistical analysis and things of that nature.

John Verry: (39:31)
A, thoughts, and, B, any best practices that you see there?

Ryan Buckley: (39:38)
Yeah. It boils back to fundamentals. The first thing I think of is robust access control, from a functionality perspective and a procedural perspective. The architects who develop and implement environments for customers, they have to … If it’s going to be a shared environment, your database architecture better be extremely well thought out and levels of isolation implemented if you’re not doing independent instances for separate customers.

Ryan Buckley: (40:07)
So your architectural planning at the database level is just absolutely vital. Separate from that, it’s fundamental access control, making sure that you have a good security group, layering oriented design on who’s got access to what, and make sure that you’ve got suspicious activity logging, logging of administrator activities. Administrators can make mistakes and change privileges on something, and who knows? Maybe it was late in the afternoon on a Thursday and they’re exhausted because the week was long for them and they made a mistake. Human beings make mistakes. That’s why you got to have robust logging in place that identifies unusual things that go on.

Ryan Buckley: (40:53)
So when I think about security of data, security of customer data, my mind immediately goes back to the fundamental ingredients: good architecture, good access management, and of course good logging and your encryption strategy. What are you encrypting and how are you encrypting it, and where are you decrypting it? Are you encrypting between multiple layers of an application architecture, server to server? Every way you can possibly encrypt, you should be, because it’s very easy these days. It’s just not that hard anymore.

Ryan Buckley: (41:26)

John Verry: (41:28)
So privileges are access control?

Ryan Buckley: (41:29)
Mm-hmm (affirmative)-.

John Verry: (41:30)
My opinion, that’s a big part of it. Yeah, and probably the other thing, too, that you didn’t mention that I would probably add on to that is education, awareness, making sure people understand what data’s important, why it’s important, what those risks are to it. And look, that data occasionally has to leave that environment or people occasionally have to go into that environment, but they need to understand that and know what the … I liked the lane … You used bumpers before. What are the bumpers, right? What are the rules of engagement with this data so that way you don’t have a situation?

John Verry: (42:01)
A client recently I was chatting with where someone had pulled some data for some reason, it was a licensed use, but they ended up sending it to the wrong entity. They sent one customer’s data to another customer. How do we make sure those types of things don’t happen? Because product security doesn’t solve that problem, right?

Ryan Buckley: (42:19)
Right. Right.

John Verry: (42:21)
Good stuff. All right. So think through what we chatted about, that we were going to chat about. It seems to me we hit the vast majority, if not all of it. Did I miss anything? Anything else that you think we should chat about?

Ryan Buckley: (42:32)
One more fundamental, when you bring up a modern, current topic, and when I think about how to reduce risk or secure something, my mind always goes back to fundamentals. And one of them that we didn’t cover is change management.

Ryan Buckley: (42:48)
And just a quick acknowledgement, some larger companies who have been around forever are still doing traditional change management with a change advisory board or a change management committee and meeting weekly to review changes. And just recognizing that we’re now born in the era of CICD, continuous integration, continue development, your traditional change management meetings have really gone by the wayside for the most part, at least for these technologically progressive companies, software companies, SaaS companies.

Ryan Buckley: (43:24)
But I would just say it’s vitally important to make sure that we manage the risk that we were trying to protect with traditional change management, and that risk is inadvertent changes, whether they’re malicious or accidental, through layered involvement on sensitive activities. If you’re not going to have change management meetings, make darn sure that you have itemized in your SDLC what kinds of activities are change worthy and require the approval or eyeballing of a superior or a peer.

Ryan Buckley: (44:00)
For compliance purposes and risk management purposes, make sure that you have a good task management system, a Jira or something like that, where you can workflow your activities from you up to your manager so that there are multiple sets of eyes on changes you’re about to make. It’s really important. We’ve seen too many companies with brilliant people, young and old, who are just cowboy developers developing functionality that is absolutely fantastic. The greatest software companies in the world started like this.

Ryan Buckley: (44:36)
But it’s important that they mature and introduce structure and method to how they develop, and change management is so vital to that. So make sure there’s multiple sets of eyes on your activities and your task management systems.

John Verry: (44:52)
Cool. Anything else we missed?

Ryan Buckley: (44:55)
Did I tell you how big the bottle of tequila is that I have in the kitchen waiting for me?

John Verry: (45:00)
No. Yeah, I think that’s a goodbye. I think you just said goodbye, isn’t that? All right. If [crosstalk 00:45:07].

Ryan Buckley: (45:07)
… you, John.

John Verry: (45:08)
I think Ryan basically just told me, “Shut the F up. I want to get off this call.” So with that, I’ll ask you our fun question, and I hope you prepared for it, because if you didn’t, you’re going to look foolish. And that is what fictional character or real person do you think would make an amazing or horrible CSO and why?

Ryan Buckley: (45:29)
I did not prepare [crosstalk 00:45:30] for this. A fictional character.

John Verry: (45:34)
You were doing pretty good up to this point. But man, this isn’t good.

Ryan Buckley: (45:38)
What fictional character would make a …

John Verry: (45:40)
Or it could be real. Real world. Sweat, Ryan. You know what? Here, hold on. Let me show you something. Come here. Look, look, look. Come here. See what I’m wearing?

Ryan Buckley: (45:54)
Oh my god.

John Verry: (45:55)
I did for you purposefully. So why don’t you say Bill Parcel … or not Bill Parcel. Bill Belichick. I [crosstalk 00:46:01].

Ryan Buckley: (46:01)
Well, yeah. I [crosstalk 00:46:03]. Well, as soon as I saw [crosstalk 00:46:05]. As soon as I saw your Jets T-shirt, my forehead started to sweat and I immediately thought of Bill.

John Verry: (46:13)
See? I helped you. Go ahead.

Ryan Buckley: (46:14)
Yeah. Well, yeah, you did. It’s do your job, right? That security is a part of every person’s job. Security’s not complete without you. I once made a poster once where the U is dropped out. A colleague of mine worked on that.

Ryan Buckley: (46:31)
But it is true. Everybody’s got to take a small role in the security effort, and you do have to do your job. And so I think Bill would make a great CSO.

John Verry: (46:41)
But you know how much I hate Bill Belichick, right? And you know how much I hate [crosstalk 00:46:46].

Ryan Buckley: (46:46)
I do. I do.

John Verry: (46:48)
But that being said, that being said, A, I completely agree with you. B, I’ve gone on record, you’ve heard probably me say this before, Bill Belichick was very helpful to me personally to go through COVID, right? Because his concept of … I think he might have said at the beginning of it, it’s one good day, win the day, and have a good day, string together good days [crosstalk 00:47:11].

Ryan Buckley: (47:11)

John Verry: (47:12)
And it’s a brilliantly simple idea, and it’s how I’ve gotten through the last five and a half, six months of this COVID shit.

Ryan Buckley: (47:19)

John Verry: (47:21)
And it’s win the day. It’s just worry about today. And it [crosstalk 00:47:25] so much sense to me as why he’s such a good coach, and I do recognize how great a coach he is. It’s because if you … That’s a season, right? And let’s have a good [crosstalk 00:47:34].

Ryan Buckley: (47:33)
I’ve been trying to teach my kids the importance of project management. Any time my 15 year-old son looks at a big chore that I ask him to do, he gets daunted. Power wash the deck, buddy. What do you say? “That will take all day and it won’t come out good.”

Ryan Buckley: (47:47)
All right. How about the railing? Just power wash the one railing today. And then he sees that it’s a smaller chunk, it’s achievable. Just focus on that and build on it. Same thing, man.

John Verry: (47:59)
Yeah, I agree. I agree. I [crosstalk 00:48:01].

Ryan Buckley: (48:01)
But he still hasn’t washed the damn deck, though.

John Verry: (48:06)
So basically, you’re saying that your project management skills aren’t where they need to be.

Ryan Buckley: (48:10)

John Verry: (48:12)
Yeah, I think so. All right, man. Anything else you want to say before we say farewell? If folks wanted to get in touch with you, easiest way is?

Ryan Buckley: (48:21)
[email protected].

John Verry: (48:26)
All right, man. Listen, thank you. Go get to that tequila. I have two more calls, and then I’ve got … So I’ll tell you one other really interesting summertime drink, if you’re a whiskey drinker. I’m a bourbon drinker.

John Verry: (48:38)
So first off, have you ever had a Fisher’s Island Lemonade?

Ryan Buckley: (48:41)
No. I don’t-

John Verry: (48:42)
Oh my god. They’re good. They’re delicious. It’s a can of lemonade and it’s got vodka and bourbon in it, or vodka and whiskey in it. But it’s delicious.

John Verry: (48:51)
Anyway, what I ended up doing … liked that so. My daughter was drinking when I grabbed one. But I like that so much is that now I’ll take a honey bourbon, a lot of lemon, and a little bit of green tea, cold, iced green tea.

Ryan Buckley: (49:04)

John Verry: (49:04)
And talk about a great summer refreshing drink.

Ryan Buckley: (49:07)

John Verry: (49:08)
So I’ll leave with that, so you can switch off the tequila on occasion.

Ryan Buckley: (49:13)
Yeah. Sometimes, I’ll need when I go running down the shirt with no shirt on unintentionally. I need to switch to something else.

John Verry: (49:22)
All right, man. Have a week [crosstalk 00:49:23].

Ryan Buckley: (49:23)
You and tequila make me crazy.

John Verry: (49:27)
Thanks for coming on.

Ryan Buckley: (49:28)
All right, man. I’ll talk to you later.

Narrator: (49:30)
You’ve been listening to the Virtual Ciso Podcast. As you probably figured out, we really enjoy information security. So if there’s a question we haven’t yet answered or you need to know, you can reach us at [email protected].

Narrator: (49:44)
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.