An industry perspective on CISA’s latest plan to get more software security assurances from vendors

Starting sometime next year, companies that want to sell software to the government will need to sign new attestations – certifying that they have taken certain steps to make sure their software is secure. Earlier this month, the Cybersecurity and Infrastructure Security Agency released its latest draft of the form companies will need to submit. One of the biggest changes is the attestations will have to be signed by a company’s CEO. But there are several other updates, too. For more about them and get an industry perspective, Federal News Network Deputy Editor Jared Serbu talked with Leopold Wildenauer, the Senior Manager for Public Sector Policy at the Information Technology Industry Council on the Federal Drive with Tom Temin.

Interview Transcript: 

Jared Serbu And Leopold, let me just ask you broadly, for starters, what’s your general take on this second draft from CISA? Do they appear to be headed in the right direction?   

Leopold Wildenauer So thank you for that question, Jared. And as you know, two years ago, the Biden administration came out with the executive order on improving the nation’s cyber security. And ever since then, agencies have been working tirelessly to deliver the assignments from that EO. Fast forward to about two weeks ago when CISA published this near-final draft of the new self attestation form. Industry has been paying close attention to this issue from the very beginning because there are a couple of outstanding questions that we have about how exactly this collection process will be implemented. I think some of the issues that we had flagged in previous comments were addressed by the updates, but there are a couple of outstanding items I’m happy to talk about today.   

        Join us May 6 at 1 p.m. EST for Federal News Network's Industry Exchange Data where we'll explore how you can employ data to modernize your agency. | Register today!

Jared Serbu Yeah, let’s take those in order. Talk first about what they did address to your satisfaction in this second draft and then what you think is still outstanding.   

Leopold Wildenauer So what we were pleased to see addressed in this update to form was the inclusion of a statement that the attestation is to the best of these signatories knowledge. That is something that we had called for in our comments that we have provided on the initial draft of the form, and we were very much pleased to see that there was an openness from CISA to take public feedback and really work with that and address stakeholder feedback in a meaningful manner.   

Jared Serbu And what do you think still needs to be addressed as the process continues to unfold?   

Leopold Wildenauer So one of the topics that I think still needs to be addressed is the issue of flexibility. If you look at the form, the self attestation is a product, the product of the cyber yield. So there are multiple type acts, two largest cyber security policy priorities as well. One obvious example here is the connection of the form. Back to the SSDF, the Secure Software Development framework. The SSDF was developed in partnership with industry stakeholders and outlines a number of security practices that can really help secure the software development process. So it does go to support this desired outcome of a more secure software development. The SSDF is designed in a flexible manner, which is a good thing because it gives developers the option to choose the right tool for their specific development contents. The self attestation at the end references specific implementation examples from the SSDF, which is concerning to industry because it removes some of the flexibility that is contained in the SSDF. We believe it would be better for the self at the station to actually reference the higher level processes instead of the discreet examples, because that would provide really that adaptability that is so critical to implementing the SSDF.   

Jared Serbu And one of the biggest changes in this draft specifically seems to be that this is going to require a sign off by the CEO. And previously I think the CEO was allowed to delegate that lower. It seems to be in line with what CISA has said before about how they think, you know, CEOs and boards need to take accountability for the security of their software. I wonder, you know, if you think this achieves that or are most CEOs already there?   

Leopold Wildenauer I think that’s exactly right, that the intention behind this is to raise cybersecurity to a board level issue and really bring it into the boardroom for consideration. I think that this will be very specific and depend on the discreet context in the discreet company that you’re looking at. So I think that generally speaking, we’re seeing a trend into cybersecurity discussions happening, more taking place in those boardrooms. But I think there’s still room to grow. And what we would like to see is to reinstate the designee option because especially for larger companies, it can be challenging to have signed off by the COO or the CEO for these self attestation forms, even if we understand where CISA is coming from.   

Jared Serbu Yeah, I mean, I think that gets back to the point that you made where the CEO is signing off to the best of their knowledge and there’s some good faith language in there too, which seems like a big loophole, which almost raises the question of what’s the point of raising it to that level if there is a workaround of that size or of that significance?   

Leopold Wildenauer I would disagree that it’s a loophole. I think it goes back to the question of how you’re thinking about liability. And there is a lot of attention that’s been paid to the software liability issue. And I think we will see this come up again when we look at the deliverable at the symposium from the National Cyber Security Strategy, that once it is put in together early next year, I think we will see some of those discussions there. And I would view this forum as one of the stepping stones towards this discussion. But I think there’s still a lot of discussion that needs to take place.   

        Read more: Cybersecurity

Jared Serbu How do you think about this in relationship to all the other things that companies need to do to be compliant with federal requirements when it comes to software security? I mean, is this an additional burden that companies have to think about or is it more in harmony with other things that may be coming down the pike like CMMC? In other words, if you’re if you’re compliant with the other things, are you already compliant with this form? And it’s not a huge thing to worry about.   

Leopold Wildenauer I think both the administration and industry are aligned in their thinking and in it their desire to reduce the burden and to streamline the process as much as possible here. One of the changes that we’ve seen with the form is that it does allow for Fed Ramp 3PAO assessments to be considered in lieu of this self attestation form. I think there’s another point to this, where agencies need to take certain steps to make sure that they are set up for success by the time that they actually need to start collecting these forms, which is this question of the centralized repository. I think that industry and the administration, again are aligned in their desire to streamline the collection process to the greatest extent possible. And that is why OMB had to task CISA and GSA to develop a centralized repository that will help facilitate the collection and the secure storage of these attestation forms. To this date, we’re not aware that this system is up and running just yet. So we would really like to see the prioritization of this effort to ensure that it doesn’t become this additional burden that you talked about, but really helps with the streamlining and the efforts that are currently happening to harmonize the regulatory landscape.   

Jared Serbu And I think the last specific thing I wanted to ask you about is there is some language in the form that that says that agencies can go beyond the specific requirements of the form and ask for SBOMs, other artifacts if they deem that necessary. I wonder how worrisome that is to you. I guess part of it depends on how many agencies accept that invitation from CISA to do that.   

Leopold Wildenauer I think here it is important to go back to the original memo and to look at what we are talking about here. This form came about because of the OMB memorandum 22-18. Which directs federal agency heads to leverage their FISMA authorities to request information from their contractors to ensure that they meet certain minimum security requirements. So this is a FISMA authority issue. And agencies already have these authorities to request additional information under FISMA. So having this form will actually standardize the process because it provides one common form for agencies to use. So in a way, it is actually preferable to have one form rather than every agency go about and issue their own form, which again, OMB has made clear is still an option, but it will need to pass through the Paperwork Reduction Act review. I think there’s one more issue that really stands out to us, and that’s the issue of the software inventory. So I think in order to set up all of the players for success and to ensure that the form collection will be ready by the time that the requirement kicks in. There’s still lack of understanding within industry of which products will be categorized as critical software versus all other software. And that is complicated by the fact that software producers don’t always have full visibility into who the final end users of their products are. So if you just think of commercial software that is being sold through a third party reseller or software that is embedded within a larger complex system, for example, like a car, these types of software are in scope for this attestation requirements if you really look into it. So agencies will need to come up with a comprehensive list of the software products that they do use to ensure that these attestations are available on time for all of the products and are being used by federal agencies. We would urge agencies to get in touch with software producers of those covered products so that they can do the legwork upfront. And agencies actually deliver on their testing that was outlined in 2018. 

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.