CISA Secure by Design: A Pledge to Secure Our World

Episode Summary

In this episode, Jason Kikta discusses his experience at the RSA Conference 2024 and the importance of the CISA Secure by Design Pledge. He highlights the focus on data visibility and consolidating information into a single view at RSA, but emphasizes that there is more to security and IT than just a magic dashboard. He then explains the significance of the CISA pledge and the need for accountability in the security industry. Jason goes on to discuss the key principles of the pledge, including multi factor authentication, reducing vulnerabilities, security patches, vulnerability disclosure policies, and evidence of intrusions. He concludes by encouraging listeners to explore the pledge and implement its principles in their own security programs.

Episode Transcript

Hey, welcome everyone back to the CISO IT podcast from Automox. My name is Jason Kikta and I'm the CISO here at Automox. As always, we're going to be talking about the intersection of security and IT. And this week, I'm going to go a little bit off topic because I was at RSA last week. So I want to talk a little bit both about what I saw there and also something interesting that we here at Automox did.

So first off, I'll start with RSA, the RSA Conference 2024 out in San Francisco. So I unfortunately didn't get to see the whole thing due to some scheduling surprises. I was only there for the last couple of days. But as always, it was quite a whirlwind. And it was very interesting to see

the various vendor booths on the floor and there were some fun ones. I saw two, Whiz and I think JupiterOne had sort of a, you know, convenience store, grocery store style, and booth designs this year. So that was interesting. And then somebody had this clean room that looked visually amazing, but also slightly foreboding, and, you know, lots of, lots of companies with really neat themes. I saw some, some smaller ones who had, you know, like arcades and bars going as far as their booth themes. So, interesting stuff there, but on the product side, you know, it reminded me a lot of last year, which is a lot of products that are found and not enough products to fix. And really the thing that's shown through for me is that.

If I sent someone who was newer to security to RSA and asked them to sort of summarize it for me, I think they would tell me that, you know, we're just like one magic dashboard away from solving security because it seems like there was an inordinate amount of focus on data visibility and on consolidating disparate sources of information into a single unified view. And that is a good and worthy goal. Don't get me wrong. It's really something that can save your team a lot of time. But on the other hand, there is so much more to security and IT that we need to improve upon that one more magic dashboard isn't going to fix it. So I remain RSA skeptical or say conference skeptical because I think it's just, it's a little too much flash and not enough substance. But one thing that was substantial there and the reason, the main reason that I went this year is that CISA, the Cybersecurity Infrastructure Security Agency, which is always a mouthful out of DHS, they're the federal government agency that, you know, looks out.

They have the primary responsibility within the federal government civilian component to look out for cybersecurity and to advocate for it. And they took what started a year ago as a paper on secure by design and the secure by design principles of how we can build and design better and more secure software. And, you know, it went through all last year. They put out a revision of it in, I believe, October or November.

And now bring it forward. And the big announcement was that they had a pledge, with 68 companies, voluntarily agreeing to, to adhere to the pledge and, and make significant progress over the next year in implementing the secure by design principles. And I'm happy to say that Automox is one of those companies. and honestly, as soon as I saw

the text of the pledge, my immediate thought was we should just sign this. Like this is, there is so much in here that we are already doing that is baked into our security culture that, you know, we've either done for a long time, or we, we do it to a degree. And if we just make these one or two modifications to be compliant with the pledge, we'll be there. So that was about as close to

to a, to a no -brainer as it gets, when it comes to security, you know, if you're already doing a lot of it may as well get credit for it. And I think more importantly, it begins to introduce the idea of accountability that is so lacking from modern corporate security culture, because too many, vendors out there just try to avoid accountability and You know, keep the

prospect of accountability to a minimum. And if you sign this pledge, and you know, you're making a public promise that you're tying your reputation to that you're going to adhere to, and you're going to try and, you know, make significant investment to either achieve or maintain those goals. And that's something that we just haven't seen. And it's probably,

honestly, it's probably a precursor to some level of regulation or law. And you know, better to do it now and get focused in that area than to try to do it later when you don't have the option. So I want to talk a little bit about the pledge and what's involved in it and why I think that they're, they're really good things. So the first one is multifactor authentication. And that is again, somewhat obvious that using MFA is important, but it's shocking to me how many businesses and organizations do not have it in place. And I think we saw this recently play out in the news with Change Healthcare and UnitedHealth. 

The parent company went in front of Congress and said, hey, we bought them, you know, not all that long ago, I think it was like 15 months, 18 months, you know, we're still integrating the tech stacks. And they had, you know, single factor Citrix exposed to the internet and somebody, you know, did drive by and got the password. And that could have been through, you know, credential stuffing, if there was no rate limiting on the password guessing or could have been a reused password that was exposed in a different breach. I don't believe they know yet, but regardless, passwords are something that can get compromised, it's possible. And if you don't turn on MFA on all of your services, then you're, you're, you know, asking for trouble because there's nothing else to stop a bad actor from taking over that account on that service. 

And I think where it gets daunting is trying to think about “How do I enable MFA on every single service, and then enforce it” is where people get a little hung up. That's where a single sign -on really makes it feasible for any size company, right? That single sign-on mechanism that you can set up on all the services, that allows you to do it once and then have it everywhere.

As well as, you know, when you have to off board an employee for whatever reason, you know, being able to shut down those accounts and shut them down quickly or suspend them in the case of a security incident. It's just really critical to have. And I think part of the stumbling block here is less so implementation and more so that, you know, a lot of companies charge a premium. 

They treat these as magic enterprise features and one. you know, significantly increase the cost of a contract. And frankly, I think that's somewhat unethical. You know, it really ought to be just sort of included by default that you can turn on MFA and enable SSO because they're just, they're, they're such a cornerstone of modern security. Likewise with default passwords, default passwords have gotten many vendors, especially hardware, hardware vendors in trouble over the years. And, you know, there's an easy workaround at first, at initial setup, you force the person setting it up to set a secure password right then. And that's how you get around default passwords. And too often that just, that hasn't been done. And it's caused an inordinate amount of security incidents over the years relative to the extreme ease of the fix.

The next one is a little more complex and it's reducing entire classes of vulnerability. So that's really, that's where it gets very real for a lot of vendors is that, you know, that one you have to stay on top of, right? So consistently forcing use of parameterized queries to prevent SQL injection attacks, developing a memory safe roadmap, providing secure defaults for developers, adopting web template frameworks with built -in protection against cross -site scripting. You know, these are all in the CISA guide and the pledge and you know, making measurable progress against those takes a lot of work and it's, and if you're, you know, if unlike us, it's not already part of your engineering program, that can be pretty daunting, but making measurable progress

doesn't mean, you know, that you're going to arrive there instantly. And honestly, even if you are already there, it's, it's not a destination, right? You're not actually there. It's a continuous journey. It's a, it's a culture. It's a state of being that you have to constantly maintain, reinforce, check, recheck, and verify. So, you know, that one, that one's a little higher of a bar.

Security patches. Obviously I'm, I'm passionate about patching here at Automox. And, and I tell you the beauty of working at a company that builds an endpoint management solution where patching is a cornerstone is that I, unlike many of my counterparts, get to be really aggressive with patching. And I'm sure some of my users don't like it, but too bad. That's, that's the one liberty that I take for myself is, is being really aggressive with patching, but even if you're in a more constrained environment or you have limited ability to apply patches or you have to have longer or more meticulous maintenance windows, having a priority to your patching, ensuring that you're producing regular results, that the patches are getting applied, that you have proof that the patches were applied, that you're tracking your performance over time, seeing whether it's getting better or worse. You know, that is really the mark of a mature organization and you have to use different strategies with different parts of your network. For example, with your servers, if you're not meeting your patching goals, then you need to be able to demonstrate that. And then you need a lobby for longer maintenance windows. 

If you're not meeting it in user space, you need to, you know, do some user education and maybe get a little more aggressive with your patching, maybe set up a patching timeframe for them. Teach them good habits. Teach them good habits about rebooting their systems on a regular basis because while Modern OSs have lured us into not needing to reboot as often and the mindset that I never need to reboot, the reality is that systems perform better with regular reboot. You know, reboot once a week, at least once a week.

And you're going to get a lot better performance out of either Mac or Windows and Linux, honestly, for that matter, as well as give that OS an opportunity to apply all the patches that it can't while it's up and running. So the next one, again, ought to be sort of table stakes, but a vulnerability disclosure policy and making it things like a security .txt file.

You know, building one and making it easily discoverable by researchers, really important things. and you know, we run our own VDP in the house here and it's, it's always an adventure, but we've gotten some, you know, good finds from researchers and too often people de-prioritize it because you end up getting a lot of low value things or informational things and.

In my mind, that's okay, because you don't play it for the dozens and dozens of informational notifications you get, let alone the duplicates, you're playing it for the one or two, you know, that medium or higher, or even possibly a critical that somebody finds, and it has a mechanism to let you know, that's really important to have. And so, you know, while it's, it's not always a lot of fun, it can pay off rather, tremendously. So, you know, definitely a good thing to have, you know, and you should have your CVEs, out there they want. So CISA wants to have, you know, transparency in reporting that includes, you know, common weakness enumeration, CWE, common platform enumeration, CPE fields and every CVE record, and CVEs are common vulnerabilities and exposures.

But getting them into those common machine readable formats is important. And it just helps tooling to be able to find and identify it better and deal with it better so that your customers can stay protected. Evidence of intrusions, again, one that seems straightforward and is actually easy to implement from the raw mechanics of it. But

is a little bit harder from the emotional level of, you know, making it, giving customers the ability to gather evidence of any kind of cybersecurity intrusion that may have affected the products. This is probably a little more relevant in the on -prem hardware maker space, but, you know, there is an element of this for cloud providers and SaaS products, you know, being able to know,

provide logs, robust logs to your customers and retain them for a set timeframe at no additional charge. You know, those things are important. And that's why, you know, we have a policy here at Automox that we're never going to charge for access to logs. And, you know, it's one of those things that, that it's tempting to turn into a profit center, but in reality, you know, these

are things that customers need to have assurance when using your product. And so it's not really a fair request to ask them to pay for that. And, you know, you shouldn't, you know, I mean, obviously we're talking about long -term data retention. I think that's probably fair game, but, but access should never be a bargaining chip and, and customers should just be able to get that built in. So.

The bottom line I would say is I think the CISA Secure by Design Pledge is a very good thing. I think it's good that 68 vendors signed it. I think there's a heck of a lot more to go and I hope many more of them will join Automox in signing it over the next year. And you can find it by just searching for CISA Secure by Design Pledge or probably even Secure by Design Pledge. But please give it a look. I think it'll...

You know, even if you're not a software vendor, it'll probably give you some really good ideas for your own security program. And I think you'll enjoy it. Until next time, I'm Jason Kikta and thanks for listening to the CISO IT podcast. And on behalf of all of us at Automox, stay safe out there and happy patching. Thanks.