SBN

Synopsys CSO: Cybersecurity Awareness Month lessons need to be applied all year

Synopsys CSO Deirdre Hanford discusses what we learned from Cybersecurity Awareness Month, as well as how to create and mature a software security program.

Lessons learned from Cybersecurity Awareness Month

Deirdre Hanford, chief security officer at Synopsys, oversees the company’s internal security, which involves not just proprietary assets but also the security of associated third parties, from partners to customers to supply chain vendors. She also has an external role, to help customers design more secure products through the Synopsys portfolio of software security testing tools.

Hanford spoke at the beginning of National Cybersecurity Awareness Month about the theme of the month—Own IT. Secure IT. Protect IT.—and how to achieve those goals, as well as about emerging security trends in both hardware and software.

This week, she spoke about how both organizations and individuals can take the training and activities of the past month and use them to improve security throughout the year.

Lessons from National Cybersecurity Awareness Month

What are some takeaways for both individuals and organizations from the security lessons observed during National Cybersecurity Awareness Month?

Thank you very much. That’s a great question because this was a month where we spent a lot of time promoting the notion of cyber security awareness and engaging in a lot of conversations.

Do your due diligence

I have two things I would like to highlight. First is diligence. This month I was fortunate to attend the BSIMM conference. It is hosted by Synopsys, but it’s really driven by a community of software development leaders who are motivated to benchmark and continuously improve their secure software development life cycle practices.

I sat through a presentation by a software development leader of the BSIMM community. He shared a framework for software developers to use when they are evaluating open source software. It was simple, commonsense, and effective, and really demonstrated diligence to me.

He presented 11 practical questions to pose on open source software. Let’s imagine you’re a developer and you’re thinking about using some open source. How do you evaluate the goodness of it?

Some of his sample questions were: Does the open source software project have regular maintenance and patch cycles? Does the project conduct code reviews for code changes? Does the project use static code analysis? Those are all really good.

I liked the fact that it was straightforward and practical. We all hope that engineers who are building software modules are doing their due diligence when they are evaluating open source, because as we all know, open source can be a door to security vulnerabilities, and I thought diligence was really a great theme.

During Cybersecurity Awareness Month, we learned how important it is to respond to the evolving threat surface.

Respond to the evolving threat surface

Second is the evolving threat surface. Part of my homework during Cybersecurity Awareness Month was talking to other CISOs and getting their lay of the land—what are they seeing? You know, part of our job as security professionals is to be out there and keep our ears open for how the threat surface is evolving and changing.

I remember at Black Hat hearing a keynote really reinforcing that as security professionals, we are all in it together, and we owe it to one another to keep up to date and share information broadly.

I had a peer call with a CISO earlier this month, and he shared with me what his company is doing to evaluate and mitigate a new vulnerability. It’s not really new—it’s more than a year old—but it seems like it’s hitting hard right now. It’s called credential stuffing, which OWASP defines as the automatic injection of breached username and password pairs to fraudulently gain access to user accounts.

It’s a brute force attack. Large numbers of compromised credentials are automatically entered into websites until they hit a match, which gives attackers access, and then they can hijack for their own purposes.

So why did I like this one? First, this CISO was evaluating that emerging threat and then running through threat scenarios to see how resilient their environment was to it.

That was the enterprise side of it. But as a consumer, as an individual, how many of us are lazy about our log-ins and our passwords? If your log-in was breached on one website and you don’t have different passwords for others, then chances are your credentials are on a list that’s being used somewhere in a credential-stuffing attack. Hopefully you’ve protected yourself against that by changing your password.

Those are two key takeaways: Do your diligence and respond to the evolving threat surface.

How to create a software security program

What would you say are the foundational elements that organizations need to start a security program?

Understand the business driver

The first component is: Understand the business driver. Without a business driver, I don’t think you’re going to build a program.

Understand the business driver. Without a business driver, I don’t think you’re going to build a program.

Let’s break that down. Software security is a mandate because software is everywhere, in our business processes and in our products. There are so many connected consumer devices out there, like smart doorbells, and those devices may or may not be designed with security in mind.

At this month’s Arm TechCon conference, there was an emphasis on how to build smart and secure IoT devices. I was glad to see hundreds of engineers sitting in those sessions sharing best practices on design for security.

In the industrial and automotive sectors, security is a mandate. Are companies and consumers willing to pay a premium for a secure device? I expect so. More likely, they will expect security designed in as a baseline requirement.

Understand your business driver—is security a requirement for your product? Could it be a differentiator? A business driver is going to give you a lot of coverage as you build out a security program. So that is key.

Build a security blueprint

Then build a blueprint for security. Security is not just an event; it’s a continuous process. I don’t like this word because people overuse it, but security truly is a “journey” and you’re never really there. Think about incorporating steps like build, measure, verify, improve, and manage in your software security initiative.

Build up a software security group and cultivate champions on the development teams. Satellites of security champions exist in most successful security programs. It’s not just the security team owning it; it’s getting the message out and getting those champions across the enterprise.

One of my colleagues actually says all the time to me, “Deirdre, just don’t slow me down with your security initiatives.” You need to be equipped to explain that incorporating security into the process may actually cost you a bit more time upstream but those steps will save you considerable time downstream.

How to mature a software security program

What can organizations that already have a security program in place do to make it more mature?

I need to talk about BSIMM here, because as I mentioned previously, security is a journey, not a destination. BSIMM stands for Building Security In Maturity Model.

BSIMM is a framework that enables teams to essentially benchmark their software security practices. With that baseline they can identify areas for improvement, develop programs to improve in those areas, and then go ahead and execute.

BSIMM, which is now in its 10th iteration, is a maturity model that has four domains and 12 practices. For instance, Practice 8 is all about code review, and Practice 4 is about developing and evolving attack models to test code. Practice 10 is about pen testing. Believe it or not, each of the 12 practices has three levels: emerging, maturing, and optimizing.

So even if you think you’ve got a hotshot software security program, chances are if you benchmark against this maturity model, you’re going to identify areas where you can do even better. 122 companies have benchmarked their practices against BSIMM. I would challenge everyone out there in software security development: How are you measuring and improving your processes? Consider BSIMM as a pathway to ever mature your security posture.

Building Security In Maturity Model

I also like that you can benchmark yourself against others in your own industry.

That’s right. At the BSIMM conference, there were various industries represented. And the folks who are representing banks would have a certain key set of “care-abouts” that might be different from someone who is in retail. It was interesting to see how the maturity model has a different set of axes depending on the industry, so having the industry-specific benchmarking is really helpful.

Security is everyone’s responsibility

The theme “security is everyone’s responsibility” has been around for some time now. Do you think that is still true, and if so, what does it mean to you?

It is true, and we spent a lot of time during Cybersecurity Awareness Month talking about security in the context of our theme: Own IT. Secure IT. Protect IT. We had weekly communications that went out to all of Synopsys. Our Software Integrity Group even hosted Security Week, where they had a variety of activities to beat the drum around security. I consider that to be a best practice.

But I want to share a couple of examples where I thought people were really living security. I had a favorite, really simple moment when I was passing through one of our lobbies. A big group was coming back from lunch. Someone was holding the door for about 12 people, and one of our executives asked in a very loud voice, “May I see your badges please!”

She was literally walking the talk because of course that was a perfect opportunity for someone to tailgate and get access to our building. She was Owning IT, Securing IT, and Protecting IT.

The second example I thought was quite interesting. I had sent an email to the company at the onset of Cybersecurity Awareness Month, and some of the links that were inserted looked suspicious to some of our more security-minded employees. A couple of colleagues even wondered if my email was a phishing test.

I love the diligence of the colleagues—they thought, “This security email looks too suspicious, so I’m not going to click on any of the links.” That made me smile because it demonstrated that folks are diligent and they are really looking to protect the company.

The landscape really continues to evolve, which can be daunting. I do believe that these basic premises remain: Be diligent, take ownership for security. Own IT. Secure IT. Protect IT.

Get the BSIMM


*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Taylor Armerding. Read the original post at: https://www.synopsys.com/blogs/software-security/lessons-learned-cyber-security-awareness-month/

Secure Guardrails