Army, SSA and USCIS cybersecurity chiefs on securing software through automation

https://www.youtube.com/watch?v=3bJP6_SjAbQ

This sounds like the beginning of a bad joke: who is lazier – software or security engineers?

While there is no punchline here, the fact is that both developers and engineers are finding ways to reduce work. But don’t call them lazy. Maybe “effective” is a better word.

For the Army Software Factory, the Social Security Administration and the U.S. Citizenship and Immigration Services, this efficiency means reducing the time it takes to bring new capabilities to production.

“I don’t know if it’s the developers that I would consider lazy or the security engineers that I would consider lazy in that sense. But personally I don’t want to go through the code line by line. I would rather just look at an automated dashboard throughout the process and then audit my automation,” said Angel Phaneuf, director of information security at the Army Software Factory, during a Federal News Network interview Cyber Leaders Exchange 2024.

“I’d rather go back and make sure my pipelines are working the way they’re supposed to and I’m getting the results I’m getting,” she added.

Shane Barney, USCIS CISO at the Department of Homeland Security, disagrees. When it comes to software security, the only solution is to let the machine do much of the heavy lifting, he said.

“We’ve really moved a lot of our security—what we call traditional security—to our development teams and have them do these kinds of tasks, whether it’s static code analysis or dynamic code analysis. My safety organization doesn’t really do that anymore,” Barney said. “Then we add breaks as needed in places that make sense. My focus remains on runtime and analysis. I want to know what the systems actually do and what they should do.”

Lack of heavy supervision of the development team

In many ways, USCIS software developers are in a better position to make their jobs easier by automating vulnerability scanning and patching.

Barney said his security team has found that software developers are good at analyzing and securing code.

“They would actually prefer to do this because they realized that if they incorporated it into their overall processes, it would make their job easier. They can actually predict when publication will occur,” he said. “They actually feel like they have more control, as opposed to when this strict watchdog organization comes in and says, ‘Oh no, you can’t get fired because you didn’t do it.’ It actually puts them more in the driver’s seat and allows me to be where I want to be.”

Meanwhile, at the Social Security Administration, developers are using a concept called code pooling to make security processes more efficient.

Tim Amerson, deputy CISO at SSA, said code batching is a twice-yearly exercise to ensure developers have the best skills needed to write secure code and ensure it stays that way.

“It’s a training model that takes them through best practices,” he said. “Open Worldwide Application Security Project, OWASP, Top 10 Findings (Details) of Coding Vulnerabilities. So if you think about the top 10 results, it’s all really about coding laziness,” Amerson said. “It’s not really about where the laziness lies. It’s really about focusing on where we can get the most bang for our buck and where adversaries are going to exploit those elements, as well as how to best defend and protect them. So if we fail to build these best practices from the beginning, we will all become lazy. Because if we are to become more effective, this is all we really care about: how effectively we secure the data of our agencies and citizens.”

Like USCIS and the Army Software Factory, SSA releases new capabilities every day. Security teams and developers work hand in hand to increase the effectiveness of each secure code release.

Shared responsibility for securing the code

None of the three agencies, nor any public or private sector organization, relies solely on homegrown software. As agencies adopt more software-as-a-service and deploy more commercial applications, security experts say they must ensure the security of every software they use.

One way to achieve this is through the use of software bills of material (SBOM) or similar approvals.

The Army said it would implement new policies by February to begin including SBOM in most new software contracts. Phaneuf said the software factory already uses them.

“We also create SBOM-like artifacts to track which packages are being used in our digital spaces and whether they are related to those that have been released and to vulnerabilities, allowing for quick identification and patches,” she said.

“You can’t fix what you don’t know you have. When we talk about open source and when we talk about third-party dependencies, it is very important for organizations to have a process in place to quickly introduce them. Otherwise the developer will just copy and paste and it won’t show up in your SBOM. You need to implement an SBOM solution. We have a pretty solid system and we know how to use it.

Improving the security of the government software supply chain is a key component of President Joe Biden’s May 2021 executive order on cybersecurity. The Federal Takeover Regulatory Board is also working on a long-awaited software security rule. Once finalized, it will require government software vendors to follow specific requirements for creating secure software.

Earlier this year, the Cybersecurity and Infrastructure Security Agency published a Secure Software Development Framework (SSDF) Attestation Form that requires company executives to sign an attestation that the company meets requirements based on the National Institute of Standards and Technology’s SSDF requirements.

Making sure your code remains consistently secure

Additionally, CISA says 220 companies have signed the Secure by Design Pledge to make good faith efforts to achieve the seven secure software goals.

SSA’s Amerson said the key to SBOM and any attestation effort is vendor transparency. He said another important aspect of this effort is that the process must be automated so that the agency can continually review it. The process cannot rely on a paper document that is out of date as soon as it is printed, Amerson said.

“I’m starting to look at it as CBOM, a code bill of materials, as it is common for software vendors to source parts of the code. So is there a way that you can base your understanding of this SBOM on where you see an anomaly in the code snippet to be able to better understand whether there’s a problem there as well?” he said. “I’m also starting to look at it from the CBOM level, not just focusing on the software, but actually on the code. Is this consistent throughout the life of the application?”

Leveraging tools like SBOM and CBOM is one step, but USCIS’s Barney said they may not work well for large cloud providers like Amazon Web Services, Google, Microsoft and others.

“I am very concerned about the risk of third parties. Whether you’re talking about Cisco products, whether you’re talking about a web app, whether you’re talking about a photo app. They are not directly related to coding or directly related to applications, but they are used in your environment,” Barney said.

“We just saw this with CrowdStrike. I’m not sure SBOM would solve this. That’s a completely different problem. But my point is that these apps work and may contain security vulnerabilities. We would have absolutely zero visibility into them because we deployed the (vendor’s) application. We do not code for them or use their code at any level. How does SBOM fit into this sphere? I think that’s a bigger concern for me.”

Discover more articles and videos now Federal News Network’s Cyber Leaders Exchange 2024 event page.