Recently, the Institute for Critical Infrastructure Technology – a cybersecurity focused think tank – brought together leaders from across the federal government and military to discuss the benefits and risk factors that new advancements in application development procedures and technologies are introducing to the development and deployment process.
More specifically, the assembled group of application development experts and agency leaders talked about the evolution of Infrastructure as Code (IaC) and APIs, and how their inclusion in the evolving software development lifecycle is not only enabling innovation, but creating new cybersecurity vectors or risks that agencies need to vigilantly guard against.-
The Webinar, appropriately titled, “The Newest Attack Vectors – Infrastructure as Code & API Security Virtual Briefing,” featured some of the most respected and experienced software minds from across our government and armed forces. This included:
• 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
• Elizabeth Schweinsberg- Digital Services Expert at U.S. Digital Service, HHS Team
• Chris Hughes – Principal Cyber Security Engineer at Rise8
• Nick Sinai – Senior Advisor, Insight Partners, Harvard Kennedy School, Obama White House (former U.S. Deputy CTO)
What was almost universal across all of their comments and programs was the belief that IaC can make software development faster and more secure – but only if agencies are careful. And APIs are essential for opening the door to advanced functionalities and new capabilities for constituents and warfighters, but only if steps are taken to ensure data is protected and third parties that utilize APIs are appropriately vetted.
Immense Capability Requires Increased Security
The panel discussion officially kicked off with the moderator, Nick Sinai, explaining the role of APIs in modern application development as, “what lets different things talk to each other, both internally and externally.” Nick then explained how APIs have gained in importance as application development has evolved, but cautioned that they can come with their own security risks.
Internally, APIs are being used a lot because we’re moving from these big monolithic apps that took years for developers to build, to microservices, where we’re actually breaking down applications into different pieces,” Sinai explained. “But we’ve got to secure them. And in that area, there have been some challenges.”
But the potential of APIs to increase access to data and the sharing of data is far too great to ignore. And two incredible examples of the potential of APIs were illustrated in the comments from Carrie Lee and Elizabeth Schweinsberg – who have both implemented aggressive and successful API programs on behalf of government agencies.
The Lighthouse program that Lee has helped to establish at the Department of Veterans Affairs (VA) holds amazing promise for improving the coordination and quality of care that America’s veterans receive. According to Lee, Lighthouse is the VA’s, “…award-winning API platform that is reinventing the way veterans and their families engage with the VA,” by giving developers, “the secure access to VA data that they need to build helpful tools and services for veterans.”
Utilizing the Lighthouse API platform, veterans can ensure collaboration between their VA healthcare providers and community healthcare providers. As Lee explained, the platform was developed with a simple, albeit important goal in mind, “We wanted veterans to have the data they needed to make decisions or to download their health records if they wanted to see a community healthcare provider.”
But Lighthouse isn’t just an internal API. Lee described how it also acts as, “…our front door to the VA’s data stores. It’s a singular platform that hosts APIs that are available externally and gives mobile applications access to our data.” But giving access to VA and veteran data to third parties creates risks, and the APIs that share that data between applications need to be secure in order to keep sensitive veteran data safe.
To protect sensitive VA and veteran data, the agency has implemented rigorous vetting of third parties, as Lee explained:
“We’re taking security very seriously. We want to keep our veterans’ data safe, but have it be accessible. So, in order to give organizations the ability to connect to our APIs…[they] have to request a key to get access to our sandbox where organizations can start developing…to connect to our production environment, they have to be vetted. They have to give us a demo, and we interview them about their security practices…”
But simply vetting third parties isn’t enough. The VA has also had to step up its security testing and evolve the way it developed applications and APIs to ensure that their internal APIs weren’t flying fast and loose with sensitive veteran data. “Within the development pipeline, we deploy DevSecOps,” Lee said. “We have our different security gates where we check our code for vulnerabilities and scan things before they’re released for production.”
Schweinsberg told a very similar story when discussing the Center for Medicare and Medicaid (CMS) API platform, Blue Button. Much like Lighthouse, the Blue Button API was developed to increase care coordination and medical history between community healthcare providers and VA doctors.
According to Schweinsberg, “Blue Button was created in cooperation with Veterans Affairs to help veterans download the medications that they’re taking because your typical veteran is getting services through the VA, but they also have a regular doctor. Being able to coordinate between the two is really important.”
Although their overarching mission is very similar, Blue Button faced a modernization and security challenge that didn’t impact Lighthouse. As Schweinsberg explained, “CMS contracts with a number of medical and administration contractors to actually be the interface for getting [healthcare providers] reimbursed for services that they’ve provided. It’s a lot of B2B type work and one of the bigger issues that we’ve been running into in trying to modernize payments systems is mainframes.”
To overcome their API security challenges, Schweinsberg and CMS began with baby steps, creating APIs for data that was low-risk or already publicly available. As they’ve moved towards creating internal and external APIs for more sensitive data, they’ve taken an approach similar to the VA – embracing DevSecOps principals and shifting security testing left in the development process.
“[We’ve been] moving teams from a waterfall development process to a more agile, testing-forward process,” Schweinsberg said. “The more tests you write up front – particularly if you’re writing both your unit test and integration test – the sooner you can spot issues.”
Both highlighted API platforms – Lighthouse and Blue Button – illustrate the incredible capability and functionality that APIs can deliver to government constituents and America’s veterans. But sharing sensitive data requires careful consideration and immense scrutiny of third parties, as well as careful testing of internal APIs and code to ensure that agencies aren’t putting constituent data at risk.
But what about the other new attack vector – IaC?
A Driver for Change or a Potential Disaster?
Moderator, Nick Sinai, defined IaC as, “…a way to automate the deployment of infrastructure that runs and houses software and applications in cloud environments.” He explained that IaC involves the creation of repeatable scripts that function to both provision and configure the infrastructure that will house and run applications.
On paper, the evolution of IaC is a game-changer – making it easy for an organization to make the provisioning and configuring of infrastructure incredibly fast and repeatable. However, by developing repeatable scripts that automate the provisioning process, government agencies could be opening a Pandora’s Box of security vulnerabilities and problems that could migrate from one organization or development team within an organization to the entire agency.
“…the challenge here is, that if you write a script that has security issues, then you can actually cause problems at real scale,” Sinai explained. “You can still provision and configure insecurely, and if you automate that process, you can actually make life even worse for yourself. Just because we’re doing things in the cloud and automating things doesn’t mean that it’s magically secure.”
This sentiment was shared by Chris Hughes who explained that IaC scripts, “can have misconfigurations or vulnerabilities in configuration [but still be deployed] across the organization.”
But what could be one of the largest faults or flaws of IaC could also be one of its greatest strengths if IaC is done correctly.
During his remarks, Nicolas Chaillan explained the concept behind Platform One and how it provides a common stack on which all organizations across the military can build applications. He also explained why this is so important, saying, “If you let every team build their own stack, you will have a lot of reinventing the wheel.”
IaC can eliminate that reinventing of the wheel by creating a single provisioning and configuration script that can be utilized across teams and organizations. And that can be a good thing if the script is secure, and the infrastructure that it is provisioning is free of vulnerabilities. As Lee illustrated, “IaC allows security people to put their controls into code and then it’s consistent across the board as developers deploy.”
But for that to be possible, IaC needs to be secure. Luckily, there are tools that can ensure that the infrastructure that IaC scripts are provisioning and configuring is vulnerability free. In fact, some of these tools – such as the Keep Infrastructure as Code Secure (KICS) solution from Checkmarx – are available free of charge for developers to ensure that they’re developing and deploying applications into secure environments.
With tools like KICS being utilized within the organization, security and operations teams can bake security into their IaC, and then roll that security out across their agency by sharing secure IaC scripts between teams – accelerating ATOs without sacrificing security.
The ICIT Webinar made it abundantly clear that APIs and IaC are essential advancements in the software delivery lifecycle that are introducing new functionality to applications, enabling the movement to microservices, accelerating ATOs, and opening the door to automation. However, they can both also become vectors for cyberattacks if development teams aren’t careful.
Vigilance in the vetting of third parties, embracing DevSecOps in the application process, implementing automated security testing early in the development process, and utilizing tools that can ensure the safety and security of infrastructure is essential if APIs and IaC are to be forces for good within government application development teams – and not exploitable vulnerabilities for malicious actors.
Click HERE to watch an on-demand replay of the ICIT Webinar, “The Newest Attack Vectors – Infrastructure as Code & API Security Virtual Briefing.”
