Loading summary
Transcript66 lines
- [00:04]
A
Hello everyone, this is Tom Uren. I'm here today with Matt Muller from Tynes for another Risky Business News sponsor interview. G'day, Matt.
- [00:12]
B
How are you doing? Wonderful, Tom. How about yourself?
- [00:15]
A
I'm good. So, Matt is the field size o of Tynes, and Tynes is a workflow, automation and AI platform for security teams. So, Matt, today you wanted to talk about Sys Secure by Design Pledge I've written about on my newsletter. I thought it was a really interesting pledge, so I'm looking forward to getting an industry perspective on it because you signed up for it. Now, just for background, what is the pledge?
- [00:47]
B
Yeah, the CISA Secure by Design pledge is effectively a set of seven principles around designing enterprise software. So this is really targeted at the vendors who sell software to other enterprises, who sell software to government, and the principles it includes. Well, I mean, look, I wasn't in the room when CISA put together these principles, but I sort of imagine that they took a look at the major set of ransomware intrusions and espionage intrusions and how those attacks occurred and sort of said like, look, if vendors do these seven things, it'll go a really long way towards eliminating some of these, some of these classes of attack.
- [01:24]
C
Right.
- [01:25]
B
So for example, one of the pledge commitments is to move to developing software in memory safe languages. Another one is to improve the inspectability of the software that you develop.
- [01:37]
C
Right.
- [01:37]
B
So that it's easier for cyber defense teams to determine if an intrusion has occurred. And so ultimately these are very much oriented around the software that people are delivering to other enterprises.
- [01:48]
A
Yeah. So it seemed like the whole Biden administration, at least their effort was to try and get vendors in particular to be more responsive to security concerns. And so this seemed to be on the carrot side, I guess. Here's something that we want you to do and would like you to do. It's not a carrot. It's kind of imploring, I guess. Now from an industry perspective, why would you sign up? What was like Tynes signed up, why did you do that?
- [02:18]
B
Yeah, I mean, for tines, this was something that very much aligns with the core principles that we've espoused since starting the company. Our founders were two security practitioners themselves, and so they've had to defend software that was developed for enterprise.
- [02:34]
C
Right.
- [02:35]
B
And we're actually very proud to be the first next gen automation and AI company to sign the pledge because ultimately what we believe is that secure software is security software. For example, we don't believe that companies should pay the SSO tax.
- [02:52]
C
Right.
- [02:52]
B
The idea that in order to get access to single sign on, you have to upgrade to an additional tier or pay more money to the vendor.
- [03:00]
C
Right.
- [03:00]
B
Every customer of Tynes gets SSO for free. And you know, this thing I think is just one example of the philosophy that we have around building secure products. And so ultimately for us, signing the pledge was something that really sort of symbolized that commitment. But look, I mean, I would actually love to see more of our competitors and more folks in the industry taking the leap and signing the pledge. Because in an ideal world, cybersecurity is not a competitive differentiator. Our customers really deserve a secure product that offers secure features. And I think that really should be table stakes. And so for us, it was very much a no brainer decision to go sign the pledge.
- [03:41]
A
Yeah. So it seems to me that if you're a newer company, how old is Tynes? Just a few years. Several.
- [03:47]
B
We've been around for about five years now.
- [03:49]
A
Yeah. Okay. So if you start with good security practitioners and you build secure code, you're like basically signing something that maybe just speculating that you're already doing anyway. And so it does seem like a no brainer because yeah, we're pretty happy with where we are. It actually I think is a good idea. I wonder if you could speculate about why a company that has been around for a long time has a lot of legacy code, maybe has some products that have had vulnerabilities. Why would someone like that sign, do you think?
- [04:25]
B
Yeah, I mean, I think to your point, it is a lot easier for a company built on a modern software stack that hasn't been through, you know, multiple acquisitions and pieces of other companies duct taped on together. It is a lot easier for us.
- [04:38]
C
Right.
- [04:39]
B
And there are certainly vendors out there who have a much tougher journey of it. But I think as you look at how the industry is evolving, the carrot here, I actually do think that the pledge is a bit of a carrot, is that you're able to signal that this is actually something that you're willing to invest in. I think no company is going to have perfect security, but it is important to symbolize again that investment that you're making.
- [05:03]
C
Right.
- [05:04]
B
That commitment to moving towards a more secure direction. And so to me, you know, a company that, that is signing on now, even if they recognize that they have maybe a legacy platform that they, that they have to overcome some, some pretty significant hurdles in over the next few years, I would expect to see and would hope to see that they would no longer be the subject of, I don't know, zero day exploit headlines every other week.
- [05:28]
C
Right.
- [05:28]
B
So, yeah, you know, there is, there, there, there is, and hopefully should be more incentive from the market as well to take the pledge and say, hey, you know, we, we actually do want to keep your business. Ripping out a firewall, for example, again, hypothetically, is, is not the easiest thing to do. But if that network edge device or what have you is just consistently getting exploited, eventually you're going to run out of customers that have, have patience for that.
- [05:53]
C
Right.
- [05:54]
B
And so the short term, you know, the pledge is, you know, saying, yes, we recognize that we all have to do better. Everyone has to consistently improve, whether you have a modern software stack or not. And having those clear areas of investment.
- [06:05]
C
Right.
- [06:06]
B
Engineering teams are pulled in a lot of different directions. These are the areas where, where they can make the most difference. And so that's, you know, if I was them, that's why I'd sign.
- [06:14]
A
So it's kind of like, here's a roadmap that they're giving you. And we, we actually do have to improve security as well. So that's why other companies should sign. Now, is it going to overnight fix? The problem is a security vendor is going to be out of business because the security by Design pledge is so successful.
- [06:35]
B
Of course. Of course. Right. Everyone signed and that's why. And that's why we no longer have cybersecurity issues. No, it's been really interesting to me because the pledge actually launched in May of last year, which is not a long time in the grand scheme of things.
- [06:49]
A
I was, I was surprised when you told me that earlier. I was, I was thinking you'd been around for. Well, I guess it is getting close to a year, but I was thinking a year or two.
- [06:58]
B
Yeah, I mean, it's close to a year.
- [07:00]
C
Right.
- [07:00]
B
And you, you could argue that, you know, maybe you'd expect to see more momentum from companies. But to me, the people that have maybe come out with a little bit of a naysayer view and said, well, we're still seeing exploits, we're still seeing this drumbeat of vulnerabilities. Therefore, the pledge has failed. I don't agree with that, with that lens.
- [07:18]
C
Right.
- [07:18]
B
Like, the pledge has not achieved its goal yet. I think we can all agree on that. The real question is what is the timeline over which we should expect to see success? And for that, months is not long enough to say that this has been a success or failure.
- [07:31]
A
Yeah, it seemed like a lot of the things were, I guess I'd call them inputs into Software design. And so it's not until you've had a whole product cycle that and probably multiple because until they're all bedded down. So you would expect it's you know, products released over the next year or two maybe would have some of those improvements baked into them.
- [07:51]
B
Right. You would hope to see that or you would hope to see that the market has started to respond to maybe a lack of progress.
- [07:58]
C
Right.
- [07:58]
B
Where you know, again I think CISA has very much provided a carrot and said, you know, look, if you make this non binding commitment that has unspecified targets for what you want to go achieve, we'll celebrate you, we'll you up on the signatories page. If that gets any teeth to it, it's going to be because customers have said your commitments don't match what you've been doing over the past few years. Ultimately this is where I think the stick is very much held in the hands of everybody who buys enterprise software and the decisions they make about what vendors they choose to invest those dollars with.
- [08:30]
A
So Matt, you're a field sizer.
- [08:33]
B
That's correct.
- [08:34]
A
Let's take away the Tynes part and just focus on the SISO part. If you're a siso for a company buying a soft, how much would you look at whether the vendor is trying to implement these secure by design pledges? Would you dive in and ask them about it, query their software design process?
- [08:57]
B
So we actually have been asked about whether or not we were secure by design pledge signers. I think security leaders are starting to ask these questions and I sort of look at how, at least here in the US if you wanted to sell enterprise software, 10 years ago a SOC2 report was a very good idea. And nowadays if you want to sell to enterprises, if you don't have a SOC 2 report, you're effectively dead in the water.
- [09:22]
C
Right.
- [09:22]
B
So over a 10 year timeframe customers demand for security standards has, has increased pretty significantly. And I hope that more customers start putting questions about secure by design and making the pledge into more of their questionnaires.
- [09:38]
C
Right.
- [09:39]
B
And start using that as a, a little bit of a pressure test to see not only does the company meet the minimum security bar, which is what a lot of these compliance frameworks are, but philosophically does they align with how I want to build out my cybersecurity stack. Right. And I think that's where you get to some of the questions of okay, if this company can consistently demonstrate that they're thinking about security by design and they're implementing it and they're Making progress. That's a vendor that is philosophically one that I want to align with.
- [10:08]
A
Right. Okay. One of the things I wrote about a little while ago was the UK's national cyber security Center. They came out with a. I guess it's kind of like a white paper talking about how you can quantify. And they called them unforgivable bugs. So in the risky business nomenclature, those are horror show bugs or comedy bugs, where, you know, it might be a null password, gets you root access or something like that. And those bugs are surprisingly common. There must be at least like, probably 20 shows a year that Adam and Patrick talk about those kinds of bugs. NCSC had a white paper that said if it would have been easy to mitigate, if it was practical to mitigate it, if it wouldn't have occurred, if you had had that mitigation, we'll call it an unforgivable bug. And the idea here is clearly to be punitive. You've described the design pledges a carrot. This would be a stick. Right. It doesn't look good if you're creating bugs that are unforgivable. So what's your thought about that approach? Do you like the carrot and stick idea?
- [11:16]
B
I would love if they were both. Honestly, I think it's certainly interesting. In the us, the regulatory environment is certainly very permissive when it comes to these types of things. And so maybe that in the us, the government doesn't quite feel like they have as much freedom to hold out a stick.
- [11:32]
C
Right.
- [11:33]
B
But I do think both. Both are necessary. Even thinking about making my purchase decisions, I too would love to be able to hold out a carrot and say, this is a partnership. We're doing security together. You're not just a piece of software that we install.
- [11:46]
C
Right.
- [11:46]
B
It's actually a relationship that we build. But if your vendor does dumb things time and time and time again, certainly shame can also be a valuable tool in that. In that regard as well. So it'll be interesting, honestly, to see over time which approach is more effective.
- [12:02]
A
Yeah, I can imagine that if you're a siso, if that was easily available and you would look at the product list and just count up, hopefully there would be some way to count up how many unforgivable bugs there'd been over time, that would be actually quite powerful. I could see how that would make a difference in your decision making.
- [12:19]
B
Absolutely. At a minimum, it reduces the subjectivity.
- [12:22]
C
Right.
- [12:23]
B
Because I can maybe feel that a vendor is better at security than a different vendor, even if they have the same certifications. But this gives me an independent benchmark to be able to say, you know, either wow, this person or this vendor is clearly thinking about cybersecurity in a much more sophisticated way.
- [12:41]
C
Right.
- [12:41]
B
By looking at the pledge. Or, you know, this vendor is just not getting it right because they're making all these unforgivable mistakes time and time and time again, not just once, but repeatedly over multiple years, even after this got published.
- [12:53]
C
Right.
- [12:53]
B
And, you know, there's no excuse at this point.
- [12:56]
A
So out of this conversation, what I'm taking home is that in some unspecified time in the future, things may be better because I'm an optimist. Matt Muller, field sizer of Tynes, Thanks a lot.
- [13:08]
B
Thanks so much.