RSA Conference 2023: Key Takeaways From Our Five Favorite Sessions

RSA 2023 is a wrap, but that doesn’t mean we are finished with the annual event. Sharing information, success stories, and lessons learned lies at the heart of RSA. And after a week of talking to attendees and pundits, giving demos, and gleaning knowledge from a slew of sessions, it’s going to take some time to sort through all the treasure from that trove of knowledge. For starters, here are a few of the more noteworthy sessions we saw at the show: 

Scaling Software Supply Chain Source Security in Large Enterprises

Rao Lakkakula, senior director of security engineering at JPMorgan Chase, gave a great overview of the extreme complexity involved in securing the software supply chain from the perspective of a large enterprise. The bottom line: while nobody can predict what’s going to happen, companies that proactively plan are better able to respond effectively to critical events. He outlined the following process: 

Understand the software process

Identify entry points into the enterprise where software is ingested, such as open source, purchased software, and third-party developed software.

Look out for shadow application development. It’s a pretty sure bet that people are using stuff you don’t know about.

Monitor integration processes

Validate the security of providers and dependencies of OSS and closed-source components. Use high-quality, valid versions of components from fewer reliable sources.

Why is this important? It’s not that easy to delete vulnerable software once it’s in the system. You risk breaking things if code is deleted or updated. The more you do at ingestion to minimize damage, the better off you are. 

Build comprehensive software bills of material (SBOMs). You need to have a realistic way for finding the next log4j, so build an asset inventory of both vendor software and OSS code, and where they deploy to. Also pay it forward by generating SBOMs for everything you ship to others.

Lakkakula gave a great analogy illustrating the complexity of SBOMs in the enterprise. He started with comparing an SBOM to a Dairy Milk candy bar list of ingredients. But SBOMs in the enterprise are more like a giant candy store that sells a ton of candy from all over the world, some of which is no longer in production. Enterprises are similar: they can bring in OSS software from all over the world, they don’t always know who wrote it, and some is probably no longer maintained.

Secure the internal CI/CD pipeline

Building a secure internal developer infrastructure starts by thinking of security integrity, build integrity, deployment integrity, and so on. This means that any components, dependencies and data are consistent, accurate, trustworthy, and protected from unauthorized modification. 

Automate vulnerability monitoring

Continuously monitor for new vulnerabilities to patch deployed software. Leverage the asset map and SBOM. Build and enforce policies based on your risk appetite.

Get involved

AppSec is a relatively new field and it’s a problem that’s complex enough that no one single company can do it alone. Government sector agencies and groups like OpenSSF, FS-ISAC, SLSA, and NIST often have working groups that are open to the public, so that’s a good place to start.

Telling Fairy Tales to the Board: Turn Attack Graphs into Business Stories

Andy Ellis and Oren Sade of Orca Security gave entertaining advice on how to translate an attack path that security understands into a business story that the board can understand. Key points:

• Drop all the technology phrases. “We have to assume that executives don’t understand these phrases. When they try to build a mental model based on keywords, those are the wrong words for them,” Ellis said.
• Focus. It’s very important to use the smallest argument to spur action.
• If there is a human responsible, don’t throw them under the bus. “Human error is an error in a system in need of redesign,” noted Ellis.
• Management needs to see the line from hazard to fix. If there are two things you have to do, you need to match a fix for each hazard.

Running in the Shadow: Perspectives on Securing the Software Supply Chain

Did you hear the one about a developer, a CISO, and a policymaker who walked into a conference session? This panel discussion featured three different — and important — perspectives on building a secure supply chain. Moderator Jessica Hardcastle of The Register led the panel, which included James Higgins, CISO, Snap, Inc.; Dan Lorenc, CEO and co-founder, Chainguard; and Camille Stewart Gloster, White House Office of the National Cyber Director. Key quotes:

Higgins: “From a CISO standpoint, the issue is easy to identify, just impossible to implement. If you can understand the landscape and where the code is coming from, you’ve solved 80% of the problem.”

Higgins: “Inventory is the most critical thing you can possibly do. What is your code? Where is it stored, and where is it coming from. If you can solve for that, you can solve the rest rather easily. It doesn’t mean I’m protected from something like Log4j, but I can tell the board we know where everything is, and it’s not a problem.”

Lorenc: “This is a developer problem. It’s a code quality and process problem. We have to change the way developers build software.”

Lorenc: “Open source is really complicated. When they grab a piece of code and run npm install it’s the equivalent of picking up a thumb drive in a parking lot and plugging it into your laptop. Nobody wants to talk about this but it is really scary.”

Stewart Gloster: “In open source software, the government should not lead, but we can be supportive: We can get our own house in order. We can invest in cleaning up code. And we could make sure that there is funding for supporting open source software investments.”

The Psychology of DevSecOps

Jennifer Czaplewski, senior director at Target and Kathryn Pimblett, senior cyber manager at A.P. Moller Maersk presented two different psychological approaches to building successful AppSec programs.

The DevSecOp team at AP Moller Maersk uses a three-pronged approach based on the theory of planned behavior to challenge the belief that AppSec is a blocker to efficient application delivery and to increase developer buy-in and collaboration.

The key: Reduce pain for developers and make it fun. “We really leveraged gamification for AppSec training,” Pimblett said. “As it stands, we have almost a third of developers actively engaging in the platform—and it’s all voluntary.”

At Target, DevSecOps uses organizational psychology — how people behave in the workplace — to build a security-minded developer culture. The main tool lies in using psychological contracts to establish standard product security values.

The three contracts: Meet developers where they work, offer end-to-end solutions, and the right way = the easiest way. “Whenever possible, we integrate right into the tools they are using so they don’t have to be interrupted,” Czaplewski said. 

The National Cyber Strategy as a Roadmap for a Secure Cyber Future

This panel of public-sector cyber strategists discussed two fundamental shifts outlined in the National Cybersecurity Strategy: rebalancing the cyberspace defense responsibility onto those most capable of bearing it, and realigning incentives to favor long-term investments over temporary fixes. One key question arose: How can organizations better support open-source software developers and infrastructure? Here’s what the panelists had to say:

Eric Goldstein, executive assistant director, Cybersecurity and Infrastructure Security Agency

“One piece is that we need a model of shared responsibility across the breadth of the OSS ecosystem. We need to make sure that the developers creating and maintaining libraries and packages have the support, resources, and information they need for that project to remain fit for purpose.

We need to know how to prioritize the libraries and packages that are heavily used in critical uses and establish a baseline for good security so it can raise the bar across the world. Because we know that there are many vulnerabilities out there. Example: A shockingly high percentage of Log4j still being downloaded are malicious.

We want to think more about what a package manager can do to create friction and speed bumps to filter and block malicious packages.“

Robert Knake, acting principal deputy national cyber director, Office of the National Cyber Director

“One of the issues is how we are talking about software liability. We want to shift responsibility in bad outcomes from end users to companies that develop that software.

But when it comes to an OSS development strategy, we don’t want to place that responsibility on open-source communities. It does no good if you hold responsible individuals doing this for free on a part-time basis. The question is, how do we create a situation where commercial software developers make better choices about what OSS to use?”

Liesyl Franz, deputy assistant secretary for international cyberspace security, Acting, US Dept of State | Cyberspace and Digital Policy Bureau 

“We can be a coalition builder for various aspects to the extent that we can help carry the message and demonstrate the activities and expertise of team CISA. “

Bryan Vorndran, assistant director at the FBI, noted that the agency is not involved in areas of regulatory action. But he did point out the value of early training on cybersecurity best practices. “We currently have no academic standards for best practices in this area across the US academic institutions. We need to up this farther upstream. “