Application vulnerabilities are among the largest, most exploited vulnerabilities that hackers use to compromise and breach organizations. With applications becoming more prevalent and relied upon, the need to focus on application security becomes absolutely essential. But what many people don’t realize is that application security – or AppSec for short – is becoming more complex and complicated as a result of how we design, develop, and deploy software.
The processes, systems, and technologies being leveraged to develop modern software are creating new vulnerabilities that some organizations either don’t know about, or are unprepared to defend against.
On May 20, 2021, ICIT will be hosting a panel of experts to discuss two foundational components to modern software development and deployment – APIs and Infrastructure as Code (IaC) – respective security concerns with each, and best practices for implementing them in a secure manner.
Invited speakers include:
- Nicolas M. Chaillan – Chief Software Officer and Co-Lead for the DoD Enterprise DevSecOps Initiative, U.S. Air Force
- Carrie Lee – Senior Technical Advisor U.S. Department of Veterans Affairs (former Director of Digital Transformation Security)
- Elizabeth Schweinsberg- Digital Services Expert at US Digital Service, HHS Team (former Cybersecurity and Incident Response at Facebook and Google)
- Chris Hughes – Cloud Security Leader, Cybersecurity Professor, Board Advisor, DevSecOps Advocate, Principal Cyber Security Engineer Rise8
- Nick Sinai (Moderator) – Senior Advisor, Insight Partners, Harvard Kennedy School, Obama White House (former US Deputy CTO)
In advance of that Webinar, we sat down with Rusty Sides, Michael Deck, and Tom Corey of Checkmarx to get a better understanding of these new AppSec priorities and how they can leave government agencies and military organizations vulnerable to hackers and adversaries.
Here is what they told us:
GovDevSecOpsHub (GDSOH): For our readers that may not be aware, can you define what infrastructure as code is? How is it different from traditional infrastructure hardware? What drove the change from traditional infrastructure to IaC?
Tom Corey: IaC is essentially a way to automate the deployment of the infrastructure that runs and houses software and applications in cloud environments. Traditionally, this was done onsite with hardware – bare-metal devices that lived in on-premises data centers. However, with the rise of the cloud, this has shifted to code, which enables the streamlining of the infrastructure provisioning and configuring process.
Rusty Sides: That’s exactly right. Traditionally, setting up your own infrastructure and network meant physically interacting with devices on-premises. As the cloud became more popular, as developers began to develop their applications in the cloud, and as development teams have shifted their approach to DevOps, this changed.
Today, resources from the large cloud players – companies like AWS, Google, and Azure – and other hybrid cloud solutions are the preferred infrastructure for developing and deploying applications. And, to provision and configure these resources, developers and development teams utilize a repeatable script instead of physically interacting with hardware.
The tools and solutions that provision these resources, like the open source software provisioning, configuration management, and application-deployment tool, Ansible – function by reaching out and setting up the network and infrastructure. They configure everything, including which ports are being used and for what purpose. They really do automate the entire provisioning and configuration process, which can free up developers to do what they do best.
GDSOH: What unique security challenges are created by IaC? Would you say that it’s more or less secure than traditional hardware infrastructure?
Rusty Sides: Traditional infrastructure is just as insecure as IaC, but the difference is how we get there, and the automation involved. There is no way to automate the provisioning of physical data center infrastructure and hardware. And, because the operations team is often setting up the same network hardware and infrastructure over and over again, they’re learning what’s secure and how to configure everything to avoid vulnerabilities.
With IaC, it’s an entirely automated process done entirely via software. It’s also highly repeatable, so the development team is likely using the same provisioning and configuration script over and over again. If that provisioning and configuration script is configuring an infrastructure that is filled with vulnerabilities, not only is that infrastructure insecure, but there’s a chance that it’s being used repeatedly both within the team and across the organization.
GDSOH: Let’s transition and talk about the other new AppSec vulnerability that you’ve referenced – APIs. Can you define APIs? What are they and what role do they play in modern software and applications?
Rusty Sides: Monolithic applications – traditional applications that took years to create because developers were writing each and every line of code for an all-inclusive application – are mostly things of the past.
Today, we have cloud-native applications that are comprised of multiple, different microservices. Microservices are individual parts of an application that do a specific task or job that needs to be done as part of the larger application. For example, in an online retail environment, there may be an application that handles the credit card payment processing and another that checks inventory and begins the fulfillment process.
“…approximately 90 percent of respondents claimed to have experienced an API security incident in the previous year. They also found that 66 percent of respondents delayed the launch of an application due to an API security concern. That’s because APIs have a number of known vulnerabilities.” – Michael Deck
Application programming interfaces (APIs) are what allows these different applications to talk to each other. APIs enable these microservices to interact and complete the action.
GDSOH: What security challenges do APIs create for security teams and application developers?
Michael Deck: Because organizations are leveraging more and more APIs to connect these microservices to perform services, it’s creating a new security vector.
In the State of API Security annual report released by SALT, approximately 90 percent of respondents claimed to have experienced an API security incident in the previous year. They also found that 66 percent of respondents delayed the launch of an application due to an API security concern. That’s because APIs have a number of known vulnerabilities.
In fact, in 2019, Open Web Application Security Project (OWASP) released a top ten list of API vulnerabilities that could expose application logic and sensitive data. This project, which was spearheaded by Checkmarx’s Head of Security Research Erez Yalon, includes a number of known software attacks and vulnerabilities, including injection and authentication flaws. This is making APIs an increasingly popular target for malicious actors.
GDSOH: What can application development teams do about these kinds of new threats?
Tom Corey: These are new vulnerabilities and new attack vectors, so they need to be treated the same as we treat any other threat. Development teams need to establish workflows around these vulnerabilities, establish standard operating procedures to help mitigate and remediate them, and implement solutions that can help ensure their software and infrastructure are safe.
Rusty Sides: When it comes to IaC, one of the most important things that development teams can do is implement Static Code Analysis of IaC solutions. In fact, Checkmarx has released its own Open Source IaC Static Code Analysis solution that we call Keeping IaC Secure (KICS), which enables developers to quickly and easily find security vulnerabilities, compliance issues, and misconfigurations in IaC tools.
Michael Deck: When it comes to API security, there are two tools that development teams can implement to help them keep their APIs and applications safe. First, there are static analysis tools that analyze where the source code is talking to the API and compare that against known vulnerabilities.
Also important is Interactive Application Security Testing (IAST) which identifies vulnerabilities that arise as the application is running. IAST solutions can look at how that application is using APIs and understand how those microservices are communicating with each other to determine if they’re doing anything malicious or leaving data exposed as they communicate with each other.
“These are new vulnerabilities and new attack vectors, so they need to be treated the same as we treat any other threat. Development teams need to establish workflows around these vulnerabilities, establish standard operating procedures to help mitigate and remediate them, and implement solutions that can help ensure their software and infrastructure are safe.” – Tom Corey
GDSOH: Tell us bout this upcoming event with ICIT. What can attendees expect to learn, and why should they attend?
Tom Corey: This upcoming Webinar is really designed to raise awareness of these two new technologies and the associated security concerns. People are increasingly aware of the role that application vulnerabilities play in enabling cyberattacks and breaches, but they may not know about these two new vectors, in particular, or what to do about them.
We’re partnering with ICIT – which is the preeminent cybersecurity think tank in the nation – to raise awareness, show how IaC and APIs may be leaving organizations vulnerable and show them that there are tools and solutions that they can use to ensure that both their IaC and APIs are secure.
If you’d like to learn more about securing IaC and APIs in your organization’s applications and software delivery lifecycle, click HERE to register for the Webinar.