Why Organizations Should Focus on AppSec this Cybersecurity Awareness Month and Beyond

The Cybersecurity and Infrastructure Security Agency (CISA) and the National Cyber Security Alliance (NCSA) sponsor Cybersecurity Awareness Month each October. This annual event is positioned as an opportunity to raise awareness about the importance of cybersecurity for citizens and organizations across the country.

While the month is typically dominated by conversations about network security, cyber hygiene, and cybersecurity training for employees so they learn to finally stop clicking on malicious links in emails, an equally, if not more, important topic that won’t overtake headlines quite as much revolves around the security of software and applications. And that’s a disservice to public sector organizations and federal agencies.

Software flaws remain some of the most exploited vulnerabilities by hackers and malicious actors. In fact, Forrester reports that vulnerable software and applications are the top cause of data breaches. And, the denial of a mission-critical application can be debilitating for government organizations that are becoming network and software-enabled in their operations.

To learn more about the role that insecure software plays in the government threat landscape, and how the evolution of the software development process can help generate more secure software, we sat down with Richard Wajsgras, Vice President of U.S Public Sector at Checkmarx. During our discussion, we talked about the threat landscape facing government agencies, the adoption of DevSecOps and how developers can take up the fight against cyberthreats by making more secure applications.

Here is what he had to say:

GovDevSecOpsHub (GDSOH): October is Cybersecurity Awareness Month. Can you tell us a little bit about the cyber threat landscape that faces public sector organizations? What types of threats are they facing and why are public sector organizations being targeted?

Richard Wajsgras: The general threat landscape facing public sector and government organizations is incredibly complex and constantly changing. Battling the threats they’re facing is complicated by the fact that they’re simultaneously tasked with moving digital transformation efforts forward that are already in process. So, they’re tasked with staying modern in operational techniques and technologies while having to combat a constantly evolving and incredibly sophisticated ecosystem of cyberthreats. It’s very challenging.

The specific threats they face can range depending on the organization – federal agencies often face off against nation-state attempts to hack their networks, as well as hacktivists, internal threats, and cybercriminals. For them to stay secure can be a challenge.

Part of the reason why they’re targeted is because of what is at stake. [Federal government agencies] store high-value data and information that has a major impact on society. That data has massive potential to disrupt our society or world. There is a very good reason why these threats are increasing – not just in sophistication – but also in frequency. Not a day goes by where we don’t hear about another cyberattack because a successful breach could be incredibly lucrative or disruptive.

GDSOH: In this increasingly large and sophisticated threat landscape, why is AppSec so important? How could poor AppSec be exploited by malicious actors against a public sector organization?

Richard Wajsgras: The code that comprises an application is the logic that provides an essential, mission-critical capability to the public sector. It’s the DNA of the application. Making sure that the code is secure – so that the decision making and the logic behind the capability is secure – is incredibly important. If that is exposed, or exploited, or flawed in a way that opens up a security vulnerability, the impact can be significant.

Having someone on your network that you don’t want is a major problem in itself. But having someone on the network who also has access to the logic that is protecting your capabilities and data is a major threat.

AppSec is something that should be fundamental and core to the organization and the broader security culture. Research shows that a significant number of breaches have started at the application layer. And most of those are due to flaws that exist in the code. With the impact of those breaches being so significant, it’s obvious that AppSec needs to be a government-wide priority.

GDSOH: In the past few years we’ve witnessed a massive change in how we make and develop software. Applications are designed, structured, and built differently. Applications are built and updated more quickly. And the development process – itself – has changed. Can you tell our readers a little bit about some of these changes? What impact to they have on AppSec? Have they made applications more or less secure?

Richard Wajsgras: Over the past several years, we’ve seen a fundamental shift in two things – how applications are developed and delivered and how applications are secured.

Software development has evolved from a monolithic waterfall approach to an interactive, iterative loop. With cloud native environments, microservices, and containers, the friction that existed before between developers and operations is dissolving.

That evolution has rapidly and exponentially accelerated the speed of play. What used to take months to execute on is now being spun up almost instantaneously – fully capable and defined for the application environment. And we’re seeing a lot of trailblazers within the DoD that are embracing this wholeheartedly and putting the organizational structure in place to adopt this at scale.

Do these fundamental changes make applications less secure? No. In fact, I would argue the opposite is true. Because – while it is true that the speed of operation is accelerating – it’s becoming accepted that security should be meshed into the development process. Bringing security into the process actually makes it more secure. Finding a way to introduce security into software development in a manner that enhances, not impedes, workflows, and makes developers’ lives easier is essential.

GDSOH: What happens when we shift security left in this process?

Richard Wajsgras: Honestly, there is a lot of talk about shifting left, but there really isn’t a “left” or a “right.” It’s more accurately an iterative process that is basically a loop.

And while adding security into that process can make applications more secure, it depends on HOW you make security part of the process. The key is seamlessly integrating security into the process of how developers deliver code – making it a natural part of their development process.

GDSOH: What organizational and cultural changes does the shift towards DevSecOps create within an organization? If security becomes part of the development process, do people like the application developers need to start thinking more like cybersecurity experts? What knowledge and training does this require?

Richard Wajsgras: At this point, everyone needs to be thinking like a cybersecurity expert, regardless of their role. This is especially true for developers, as they truly have become security gatekeepers and the first line of defense given that they’re working at the foundational level of all software and applications – coding.

Developers are creatures of habit that like to do things a certain way, so when you want to add something into that process, you’ll meet some resistance. But, if you can do it in such a way that it’s integrated into their natural behaviors and workflows, you’ll have success.

The goal of any developer training program is to ensure they’re developing secure code. You don’t want them delivering code with vulnerabilities, so you need to train them to avoid doing that. So, some cybersecurity training needs to be integrated into their professional development and education.

For example, Checkmarx has a solution, Codebashing, that identifies a vulnerability that they’ve written, and then can launch a real-time training program that shows them why what they did creates a vulnerability. This can fundamentally change their behavior and get them coding better, more secure software in real-time. Additionally, since it brings a gamified element, we’ve found that many developers end up asking for more training as it creates a sense of competition and fun.

Ultimately, security awareness and training is essential for individuals to operate more securely regardless of the role they’re in.

GDSOH: What new tools and technologies are available out there to help application and software developers ensure that their applications are more secure? What do these tools do? How do they make the job easier for developers? How do they increase security?

Richard Wajsgras: The AppSec space has matured tremendously over the past several years. Today, there are a number of application testing and vulnerability detection tools that are incredibly capable and mature. This includes several different tools and capabilities that can be injected into the application development process – scanning the code and conducting real-time testing – ranging from static application security testing (SAST) and software composition analysis (SCA).

Open source is also essential today. Understanding open source libraries and where they’re coming from – using software composition analysis and being able to remediate when you find a vulnerability is a big part of solving systems issues around vulnerabilities in software.

In order to make the lives of developers easier – and to increase security in general – it’s important to look for tools that automate security throughout the entire software development lifecycle and integrate into existing pipelines and workflows. This is the gold standard in software security.

To access best practices for implementing a comprehensive AppSec program and to learn why AppSec is more essential than ever before, click HERE to download the eBook, “5 Reasons to Prioritize Software Security.”