Security is often seen as a zero-sum game between “go fast” or “stay secure.” We would like to challenge this school of thought and introduce a framework to change that paradigm to a “win-win game,” so you can do both—“go fast” and “stay secure.”

Historically, application security tools have been implemented much like a gate at a parking lot. The parking lot has perimeter-based ingress and egress boom gates. The boom gates let one car through at a time, and vehicles often are backed up at the gates during busy hours. However, there are few controls once you get inside. You can access nearly any space on any level and easily move between levels.

When you apply this analogy to application development, AppSec tools are often implemented as “toll gates” within waterfall-native workflows. Developers are required to get in line, submit to a security scan, and wait to see the results. When the results are produced, developers spend significant time and energy investigating red flags raised by security. This process is slow and, not surprisingly, not very popular with developers. It’s why they often view traditional security programs as inhibitors to innovation.

Guardrails not gates

We suggest a workflow that’s less like a parking lot gate and more like a freeway with common-sense safety measures. Freeways have directive rules for all users. Speed limits, single direction of travel, and mandatory speed reduction zones when exiting contribute to freeway safety. Some freeways implement preventative measures based on these rules, such as physical walls dividing opposite flows of traffic and protective guardrails to reduce collisions and keep vehicles from veering off the road. While driving on a freeway comes with its own complications, there are no boom-style gates blocking your path.

Following the same directive rules, there are detective and responsive controls, such as speed detectors, cameras, signs reminding drivers which direction they are going, and how fast they are traveling. Some freeways have deployed rumble strips to remind a dozing driver to stay in their lane.

Applying lessons from freeways to application development and compliance in the cloud represents the perfect opportunity to build software more securely.

Modern application security tools should be fully automated, largely invisible to developers, and minimize friction within the DevOps pipeline. To do this, these security tools should work the way developers want to work. Security controls should integrate into the development lifecycle early and everywhere. These controls should live within the developer’s preferred tools and create rapid feedback loops so mistakes can be remediated as soon as possible.

A typical compliance cycle looks like this:

Here, we highlight the gap between the desired state and the actual state that becomes problematic when audit times come. This increases the overall cost of the audit and the time spent in generating the evidence of controls.

Instead, this is what we need.

We need the actual state to track the desired state continuously. We need continuous preventative controls to stop insecure resources from being introduced. We need detective controls to find non-compliant resources promptly and constantly. We need responsive controls to fix non-compliant resources automatically. In all, we need continuous compliance.

Infrastructure continuous compliance reference architecture

How do we get started with continuous compliance? Here is the reference architecture that enables you to develop this capability.

The architecture is centered on building a close-loop of directive, preventative, detective and responsive controls. It is also open and extensible. Although we reference Google Cloud architectures in this blog, you can use them for other cloud service platforms or even on-premise

The National Institute of Standards and Technology’s Open Security Controls Assessment Language (OSCAL) is a helpful resource to express your control library in a machine-readable format. OSCAL can allow organizations to define a set of security and privacy requirements, which are represented as controls, which then can be grouped together as a control catalog. Organizations can use these catalogs to establish security and privacy control baselines through a process that may aggregate and tailor controls from multiple source catalogs. Using the OSCAL profile model to express a baseline makes the mappings between the control catalog and the profile explicit and machine-readable.

Directive controls

The starting point of the close-loop is the directive and harmonized controls. Next, you should have control mappings rationalized to the technical controls against your compliance requirements. These requirements can come from various sources, such as the threat landscape of your industry, your internal security policies and standards, your external regulatory compliance, and industry best practice frameworks.

Control mappings will form a Technical Control Library. The library is a dataset mapping out harmonized controls to requirements written in different compliance frameworks. The control mapping justifies the security controls. It builds the linkage between security and compliance and helps you reduce your compliance audit cost. This dataset should be a living document.

An easy first step in building such as library is to begin with the CIS Google Cloud Platform Foundation Benchmark. The benchmark is lightweight and it constitutes foundational security any entity should get right on Google Cloud. In addition, Security Command Center Premium’s Security Health Analytics can help you to monitor your Google Cloud environment against these benchmarks on a continuous basis across all the projects within your organization.

The Technical Control Library will guide the rest of the closed-loop. For every directive control, you should have corresponding preventative control to stop non-compliant resources from being deployed. You should have the detective control to look over the entire environment seeking non-compliant resources. And you should have the responsive control remedying non-compliant resources automatically or kicking off responsive workflow with your Security Operations function. Finally, every policy evaluation point should have a feedback loop to the engineers. A prompt and meaningful feedback loop provides a better engineering experience and increases development velocity in the short run. These feedback loops will breed good behaviors to write better and more secure code in the long run.

Preventive controls

Almost every action on the Google Cloud is an API call, such as when creating, configuring, or deleting resources, so preventative controls are all about API call constraints. There are different wrappers for these API calls, including Infrastructure-as-Code (IaC) solutions such as Terraform or Google Cloud Deployment Manager, the Cloud Console interface, Cloud Shell SDK, Python, or GO SDK.

As with any other application code deployment, the IaC solutions should use a Continuous Integration (CI) solution. On the CI, you could orchestrate IaC constraints, similar to writing unit tests for application code. Since all IaC solutions come in or can be converted to JSON format, you can use Open Policy Agent (OPA) as the IaC constraint solution. OPA’s Rego policy language is declarative and flexible, which allows you to construct almost any policy in Rego.

For the input sources that are not IaC, you could fall back to the organization policies and IAM as these two controls have the closest proximity to Google Cloud. That said, it’s considered a best practice to restrict non-IaC inputs for higher environments such as production-like or production, so you could codify your infrastructure, apply controls and workflows in the source repository.

Detective and responsive controls

Even if you’ve nailed the preventive controls, and the cloud environment is sterile, we still need detective and responsive controls. Here’s why.

For one, not all the controls can be safely implemented as preventative controls in the real world. For instance, we may not fail all the Google Compute Engine deployments at the CI if these VMs have external IP addresses because external IP addresses may be required for a specific software or use cases. Another reason is that we want to produce time-stamped compliance status for audit purposes. Taking the CIS compliance as an example, we could have enforced all the CIS check on the CI and set IaC as the only deployment source for cloud infrastructure.

However, we will still need to demonstrate the runtime CIS compliance report using Security Command Center. Security responsive controls are not limited to remediation actions. They can also take the form of notifications via email, messaging tools, or integration with ITSM systems. If you use Terraform to deploy the infrastructure and use Cloud Function for auto-remediation, you need to pay attention to the Terraform state. Since auto-remediation actions performed by Cloud Function are not recorded in the Terraform state file, you will need to inform the engineers to update the source Terraform code.

The future

The fact that manual processes around security and compliance don’t scale points to automation as the next enabler. The economics of automation require a systemic discipline and holistic enterprise-wide approach to regulatory compliance and cloud risk management.

By defining a data model of the compliance process, the aforementioned OSCAL represents a game-changer for automation in risk management and regulatory compliance. While we realize that adopting “as code” practices is a long-term investment for most of our customers, Risk and Compliance as Code (RCaC) has a number of building blocks to get you started. By adopting the RCaC tenets you shift towards codified policies and infrastructure for a secure cloud transformation. Stay tuned as we introduce exciting new capabilities and features to Google Cloud Risk and Compliance as Code in the months to come.

Prior to joining Google Cloud, I spent 20 years in the public sector serving in various security roles, most recently as the head of the cybersecurity division at the newly established Cybersecurity and Infrastructure Security Agency (CISA). I was responsible for delivering services and capabilities to about 100 civilian agencies, as well as our critical infrastructure for state and local partners across the country.

Throughout my time serving in the U.S. government, I spent a great deal of energy working to keep bad actors out of our systems. What I eventually realized was that we were at a disadvantage. We didn’t just have legacy systems to deal with; we also had a legacy mindset. Our policies and capabilities were overly reliant on a perimeter-based approach to defense and introduced layers of friction with tools like VPNs, which inhibited productivity and increased frustration.

I spent the last few years of my time in the government doing my best to modernize this approach to security and supporting the many people who shared this vision. While most of them are still there, doing excellent work, repeated cybersecurity breaches of U.S. government systems have interrupted vital work and cost taxpayers billions of dollars. The SolarWinds breach in 2020, for example, may have cost governments and businesses more than $100 billion and the loss of vital national security information. Yet many government agencies continue to rely on the same legacy productivity software.

Today, a new survey conducted by Public Opinion Strategies and commissioned by Google Cloud shows that many government workers echo these concerns. The survey—which polled 2,600 working Americans, includes 600 workers from the D.C. metro area and 338 workers employed by federal, state, or local governments across the country—found that the majority of government employees surveyed reported being “very” concerned about cyberattacks striking their employers in the coming years. And nearly one-third of surveyed government employees in the D.C. metro area say they have experienced a disruption at work because of a cyberattack.

Results from the survey also showed a lack of satisfaction with legacy software, with more than 50% of government workers nationally responding that there are other products and services that could help them do their jobs better.

These new findings not only speak to the challenges our government employees face, but also outline an opportunity for improved innovation and security that can help government employees better achieve their missions.

Concerns about cybersecurity

The majority of respondents said they believed it was likely that the federal government would be the victim of a cyberattack in the next few years. This percentage was even higher in the D.C. metro area and among government employees, with 40% of government workers living in metro D.C. saying it was “very likely.”

Respondents in all groups—national, D.C. metro, and government employees—were more likely to be concerned about cyberattacks as the perceived threat moved closer to home. For example, 80% of those surveyed said that recent attacks have them concerned about their personal data and privacy, and that of their family members. And for those in the D.C. area or in government jobs, the numbers were consistently higher than the national average.

One likely reason for such broad concern about cyberattacks is that many respondents reported experiencing a cyberattack at work. And while more than one-in-ten workers nationally have experienced disruptions from a cyberattack, the number increased to nearly one-in-three for D.C.-based government employees—nearly three times higher than the national average.

The problem with IT ‘monoculture’

According to survey respondents, 84% of D.C. metro government employees primarily use Microsoft products at work, including Word, Outlook, Teams, and OneDrive. This is confirmed by another recent study by Omdia that found 85% of government employees use Microsoft productivity software, far and away the largest IT productivity vendor by market share.

This reliance on a single software suite might suggest that these products are safe and secure, but the Public Opinion Strategies survey found that more than half of all respondents said that the government’s reliance on these Microsoft products actually made the federal government more vulnerable to hacking or cyberattacks.

Given these vulnerabilities, why does government IT continue to rely on the same set of productivity tools in the workplace? The reason, according to survey respondents, has more to do with inertia than innovation. When asked why their employers used Microsoft services, around half said that the reason their employer continues to choose legacy, incumbent vendors was more about not wanting to change than wanting the most effective tool for the job.

Choice and shadow IT

Coupled with these concerns about vulnerabilities comes a noted sentiment among those surveyed that their current IT solutions are not best for their needs. About half of those surveyed who primarily use Microsoft at work said that they would prefer to have a choice to use products and services from other companies. And among those who use Microsoft at work, 43% believe there are other products and services that would allow them to do their job better.

This may be leading workers to adopt “shadow IT,” or using products and services that are not officially approved or endorsed by their IT departments. In fact, the Public Opinion Strategies survey found that 35% of D.C. metro government workers have used shadow IT to get their jobs done. And among workers aged 20 to 34, that number jumps to 41%.

Rethinking IT purchasing priorities

With so many survey respondents reporting that they are dissatisfied with their legacy IT solutions, it may be time for the government to rethink its approach to procurement. In a separate research survey from Omdia in December 2021, 250 people responsible for technology purchasing decisions in the U.S. federal, state, and local governments said that government technology and procurement practices often are more about making things easier for IT vs. choosing what employees feel would be the best solution. In fact, only 27% of officials surveyed in that research cited “user demand” as a factor affecting their purchasing decisions.

As governments work to meet the demands and preferences of their constituents—and their employees—it’s clear that there’s an overreliance on legacy solutions, despite a track record of cybersecurity vulnerabilities and poor user perception.

At Google Cloud, we believe it’s time for more diversity and choice in the tools available for our civil servants across the nation—70% of whom use Gmail outside of work, according to our survey. Government workers have the right to benefit from the same flexible, secure-by-design tools at the office that they use in their personal lives. You can learn more about Google Workspace for Government here.

Broadcom is a global technology leader that designs, develops, and supplies many semiconductor and infrastructure software solutions. Broadcom’s category-leading product portfolio serves critical markets including data center, networking, software, broadband, wireless, storage, and industrial sectors. 

Our customers, many of whom operate in the federal public sector, need ready-made SaaS solutions to secure their infrastructure while meeting compliance requirements. As head of platform engineering for Broadcom and its subsidiaries, my team is responsible for designing, testing, and building the common orchestration platform and services for our federal customers.

Since early 2021, we’ve partnered with Google Cloud to deliver best-in-class cloud solutions for  our multinational customers with speed, scale and efficiency, which earned us the Google Cloud Customer of the Year Award. When it came to creating plug-and-play security and compliance solutions for federal organizations in the United States, we turned to Assured Workloads.

Simplifying the path to compliance 

Assured Workloads provides out-of-the-box capabilities that allow us to easily create and maintain controlled environments that address security and compliance needs across different verticals and sectors. This includes enforcement of data residency, administrative and personnel controls, and managing encryption keys. 

For example, in the United States, federal government agencies need to use solutions that comply with FedRAMP, the government-wide standard for cloud computing security, while the Department of Defense (DoD) needs to comply with Impact Level (IL) standards. Assured Workloads helps us create solutions with built-in guardrails to ensure our customers automatically operate within whichever standard applies.  

Additionally, Assured Workloads guarantees that only personnel with the necessary clearance and permissions have access to information, and ​​it offers integrated cryptographic control over data, including customer-managed encryption keys based on the chosen compliance program. 

As a result of using Assured Workloads, our Symantec Security suite can provide a comprehensive set of security services that are being certified for FedRAMP. These include Web Security Service, Data Loss Prevention, Cloud Access Security Broker, and Symantec Endpoint Protection (SEP). 

We also offer our enterprise software products as services through Google Cloud. Rally Software, our enterprise agility tool, and Clarity PPM, our project and portfolio management tool, are already certified for FedRAMP. Additionally Clarity PPM is undergoing certification for IL4 compliance for our DoD clients. 

Sophisticated solutions for a secure future 

Given the intricate nature of securing the cloud environment and the business processes it handles, integrating Assured Workloads into our service offering has been simple and streamlined. Many of our services already run on Google Cloud, using Google Kubernetes Engine and Google Compute Engine, and since those Google Cloud services can be configured for all programs in an Assured Workloads environment, we were able to provide solutions to federal agencies without making significant changes to our deployment or configurations. This has helped save enormous engineering effort by avoiding a customized one-off effort to manage a Federal environment.

Google Kubernetes Engine (GKE) is one of the critical services in our environment, and Google Cloud releases many new GKE capabilities each year. Assured Workloads allows us to benefit from all the latest GKE innovations that come through automatic updates, maintaining parity with the commercial cloud without compromising on security and compliance requirements.

Compliance is a must-have for our federal clients, and our duty as providers of security and software services is to supply them with easy-to-use, efficient solutions they can trust. With the power of Assured Workloads streamlining our infrastructure software solutions hosted in Google Cloud, we can better support our regulated customers and further grow our software and security service businesses.