Rita Manachi contributed to this blog.
What do you think of when you hear the term “cybersecurity?” If you were to believe today’s media and entertainment, you might envision a room filled with people watching an elaborate command center on giant monitors, or a hacker in a dark room surrounded by the ominous light of computer displays. While cybersecurity might evoke many kinds of reactions within the technology sector – from dread to opportunity, in the federal government, there is a related term that induces fear and the dread of a long and painful process: authorization to operate (ATO).
For those of you who are familiar with ATO, this post is to say we see you! (And of course, we can help, but more on that later.) In the meantime, if you want to talk about it, reach out.
How Authorization to Operate (ATO) fits into your security strategy (even if you are not in the federal government)
Authorization to operate verifies that an authorizing official has confirmed that a piece of software, platform, laptop, or product meets an organization’s compliance requirements and can, therefore, be run on their systems. For a more descriptive definition, check out this Tech Insights page or watch the below video.
It’s reasonable to expect that ATO is well understood within the federal government, it should be familiar to security practitioners and leaders outside of government as a sort of extension of the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF). Per the NIST website,“The Risk Management Framework provides a process that integrates security, privacy, and cyber supply chain risk management activities into the system development lifecycle.”
Most highly regulated industries have their own version of NIST and the RMF, which can also benefit from, using a structured approach like ATO to govern and enforce policies. Imagine the ability to define, govern, and enforce policies like who can access which systems, how, for what, and for how long.
Security frameworks and authorization standards
There are countless frameworks and standards that guide, and in some cases prescribe, security policies and requirements, especially in highly regulated industries like healthcare, financial services, and the public sector. Examples of frameworks and standards include SOC (Security Operations Center), HIPAA (Health Insurance Portability and Accountability Act), ISO (International Organization for Standardization), PCI (Payment Card Industry), Supply Chain Levels for Software Artifacts (SLSA), General Data Protection Regulation (GDPR), and many more.
These frameworks are designed to include all aspects of a system—from infrastructure to stored data, application logic, as well as every aspect of how data is gathered, stored, and transmitted. In the case of software development and delivery, that includes the platforms and infrastructure on which they run. Here are different security considerations along the path to production, and, when we understand this, we can see how approaching security as a monolithic endeavor is not ideal and can even be misguided.
Watch this webinar where Forrester Principal Analyst, Sandy Carielli discusses redefining security enablement outcomes.
But there is good news! Many security approaches often have more overlaps than distinctions—in compliance circles this is expressed as “reciprocity.” When an organization applies modern development practices to its cybersecurity processes, such as code scanning tools integrated into automated deployments or automated identity management solutions, it is already meeting many of the criteria set by daunting compliance requirements.
As we’d expect, there can be, and are, different types and levels of authorization, including assess only, interim authorization to test (IATT), authorization to operate, type accreditation, and more. Some of these authorization processes require more than 2,000 different security checks to be performed on an environment or application, and many of these are required by other organizations. So, you can see here how ensuring reciprocity would go a long way toward streamlining this process.
Real-world application and results of ATO
Let’s consider the ATO scope itself in a typical cloud environment. In most public sector authorizations, a minimum of 1,700 individual questions must be answered. However, when a DoD-accredited cloud service provider is used, this number is immediately reduced by more than half. With most organizations, this still requires a heavy lift of more than 800 questions and includes incorporating vulnerability scans on the individual software components. Working with a compliance architect or similar, and embracing a DevSecOps model, can not only help discover overlapping requirements and redundancies, it can also help you automate more of the analysis while better articulating the manual compliance as part of a healthy SDLC.
Another real-world example is in the widely used Open World Application Security Project (OWASP) model. OWASP Top 10 vulnerabilities are one of the most often used evaluation resources for application developers. When a DoD team evaluates the security of applications being developed, they often use a checklist that includes 286 questions. But, when an organization applies the best practices that include automation to incorporate the OWASP Top 10, they are already answering 173 of the 286 questions without having to include any manual processes. When we approach the ATO in the same manner, we quickly see that there is a path to (compliant) production that can include layers of automation and inheritance to simplify the process. The bonus to this approach is that it also increases broader organizational enablement through more scalable reciprocity.
But, what about the remaining 113 questions? Can we automate them without your engineering and security teams performing any manual work? In the case of Tanzu, the inheritable controls provided show the relationship between Tanzu products, which effectively automates all of the compliance requirements for each of the Tanzu applications integrated into your infrastructure. In a real-world use case, a public sector Tanzu customer was able to reduce the assessment workload from 286 questions to 10. The remaining 10 only required validation to ensure compliance, which means that there was no additional engineering work needed by the customer. This success story demonstrates the value of working with a trusted partner that understands the complexities of the ATO, or any RMF, and is mindful of how to best enable you to achieve these critical authorization outcomes.
Automation accelerates ATO processes
Automation is an obvious accelerant for an ATO process and vice versa. But what about some less obvious practices, technologies, or patterns? Based on decades of work with a wide range of government agencies and highly regulated customers, Tanzu Labs’ Modern Compliance Architects identified some of the most successful patterns and tools that can help achieve ATO with fewer tears and less time:
-
Security is not treated like a single monolithic outcome but an inherent, innate characteristic of the software dev and delivery lifecycle.
-
Use of inheritable controls enabled by a compliant ecosystem, such as the one provided by Tanzu, enable a “secure by default” application development process.
-
A proper understanding of how your environment is compliant leads to better integration of your outcomes with additional frameworks, if needed.
-
Compliance without prescription can lead to a less secure environment, inconsistent policy enforcement, and can hinder your ability to scale and react to CVEs.
-
Along with policy, your compliance team must offer multiple ways to achieve authorization and suggest the ones that are best for your organization.
-
Prescription without empathy is dangerous—compliance must not operate in a vacuum, which means you should allow and encourage frequent connections with other teams to make sure compliance policies are keeping up with the current environment, latest innovations, and newest security risks and CVEs!
Explore how Tanzu enables continuous ATO and security
As an industry we continually strive to simplify an end user’s experience. But what may sound simple can be very complicated and will only continue to grow in complexity as users expectations evolve. We want to make it easier for IT leaders, security practitioners, developers, and managers to meet their organizations’ security requirements and industry guidelines.
Here are some resources that can help you expand your perspective about security and compliance:
Security Measures in VMware Tanzu Application Catalog (Whitepaper)
PCI best practices for containers and container orchestration (Whitepaper)
Tanzu Application Catalog: Mitigating Upstream CVE Risks without Compromising Quality (Blog)
Securing Cloud Applications (eBook)
