Security isn’t something you implement once and leave alone. It’s a mindset, an operation, and an ongoing policy. Security frameworks like FedRAMP require a process called continuous monitoring in order to remain valid.

The world of information threats is constantly evolving. Technology grows, changes, and improves, but with those changes come new vectors for intrusion, new methods for unauthorized access, and new exploits. If your security is static, the evolving threat landscape will overtake you sooner or later. Continuous monitoring is a big part of how you maintain security over time through ongoing analysis and improvements.

What do you need to do to remain compliant with FedRAMP rules? Where does continuous monitoring come into play? And what is the concept of Zero Trust? Let’s talk about it.

Defining the Key Terms

Let’s start by defining the three biggest terms you need to know to understand the bulk of this post.

What is FedRAMP?

If you’re here, you probably already know what FedRAMP is, but in case you’re more familiar with alternative frameworks like CMMC, it’s still worth the introduction.

FedRAMP is the Federal Risk and Authorization Management Program. It’s a security framework that encompasses the entirety of the federal government (and many state governments implement their own versions as StateRAMP programs). It uses NIST security controls to set standards regarding the security requirements, risk assessment, authorization, and monitoring of service providers that wish to work with the federal government.

FedRAMP applies to federal agencies, who are required to use FedRAMP-authorized services for all cloud-based needs. It also applies to those cloud service providers, or CSPs, who have to be FedRAMP-authorized in order to win a federal government contract. Third-party assessment organizations (like us, the Ignyte Assurance Platform) must also be FedRAMP-authorized in order to provide C3PAO services in FedRAMP security assessments. Finally, any contractor, partner, or third-party entity that works on behalf of a federal agency and handles controlled information will also need to comply with FedRAMP.

Private party and non-governmental use do not need to comply with FedRAMP. A non-governmental entity can choose to use FedRAMP-authorized cloud service providers or not. Only if they handle federal information or are required by contract for other reasons do they need to adhere to FedRAMP rules.

What is Continuous Monitoring?

Also known as ConMon, continuous monitoring is the process by which an entity, such as a cloud service provider, watches and reviews its security posture.

It’s broadly defined as a six-step process:

1. Define the security requirements your entity needs to uphold, as per FedRAMP security level and NIST security controls.
2. Establish a framework for actively and passively monitoring your security posture across these controls.
3. Implement a monitoring system to collect, audit, and review data related to your security posture.
4. Analyze the information, reports, and logs produced by your monitoring system and report on the results.
5. Respond to anything unusual, whether it’s a minor lapse or a major intrusion. Responses happen across technical, managerial, and operational axes.
6. Review any reports and responses, and make updates and changes to your security as necessary to keep up with modern security requirements.

We have a more detailed guide to these steps, as well as other key details, in our guide to continuous monitoring for FedRAMP here.

What is Zero Trust?

Zero Trust is a concept in information security that has been growing more and more in popularity as the various threats in the infosec space grow more sophisticated. It’s also something that FedRAMP has been looking at since at least 2022.

Zero Trust has been in process or implemented in several ways across the federal government. These include the Department of Defense implementing Zero Trust Overlays for military departments and the CISA developing and iterating on the ZTMM, or Zero Trust Maturity Model, currently in 2.0. The White House also released a memo reauthorizing FedRAMP and kicking off further investment into Zero Trust in July 2024, though that memo has been deleted with the change in administration. This memo built on an also now-deleted executive order, 14028, which in 2021 introduced stricter requirements and spurred the advancement of FedRAMP standards, including a focus on zero trust.

But what is it, actually?

Exploring the Concept of Zero Trust in Information Security

The concept of Zero Trust as it relates to infosec is focused primarily on a zero trust architecture.

In a way, you can think of a traditional business infrastructure as a walled library. The walls are strong, and the gates are guarded, with each potential visitor being carefully evaluated. However, once a visitor has been vetted and allowed entry, they are free to explore the library and read the books, mingle with others in the space, and generally do whatever they want. They’ve been vetted and approved.

The problem with this concept is that the outer wall – a firewall, an authentication gate, a username and password login portal, or what have you – may not be as secure as it seems. More importantly, a set of compromised credentials could allow a malicious actor to enter under the guise of a trusted account. To then have free, unfettered access to the systems and information inside the library means the damage this malicious actor could do is immeasurable. They could copy or steal books, they could gather information from other patrons, or they could set fire to the whole thing.

Zero Trust puts up many barriers to this kind of intrusion by treating each system and module within the library as if it were just as exposed to the wider world as the library’s outer walls. It would do things like:

• Encrypt the contents of the books so that someone without true authorization wouldn’t be able to read them.
• Secure the books in place so they can’t be copied or removed from their locations without proper authorization.
• Add additional gates between shelves so that an intruder can’t move freely between areas without further authentication.

Or, to put it in less metaphorical terms, data at rest is encrypted, data in transit is encrypted, communications between modules are secured, and authentication needs to happen repeatedly. Just because someone was authenticated at the gate doesn’t mean you trust them implicitly.

The Core Principles of a Zero Trust Architecture

Zero Trust is increasingly built into the foundation of security architectures, including CMMC, FedRAMP, and others. Many of the principles of Zero Trust are already familiar to you or are built into existing rules in the NIST list of security controls.

All data sources and computing services are considered resources. This is important because each individual resource is meant to be defended and secured individually rather than collectively.

All communication is secured regardless of network location. Even internal messaging and communication need to be secure so that no matter what kind of intrusion happens, those communications can’t be monitored or leaked. NIST rules set forth baselines and minimums for encryption standards for the security of communications.

Additionally, this principle also includes access to those communications channels. Session authenticity verification, session termination and timeouts, termination on detection of anomalous use, and active monitoring are all part of this principle of Zero Trust.

Obviously, all external messaging also needs to be secured in relevant ways.

Access to individual enterprise resources is granted on a per-session basis. This one is relatively simple; you don’t authenticate someone once and then trust them for some period of time, the way an authentication cookie would work. Each individual access is limited to that session, and when the session is terminated, access needs to be re-authenticated.

This also incorporates a significant degree of the Principle of Least Privilege. This is the concept that every individual user account has the bare minimum amount of permissions and access necessary for them to do their job or complete their task. No one is given sysadmin rights simply because it’s more convenient.

Moreover, permissions and access need to be periodically reviewed, and excess permissions or access removed when they are no longer necessary. This might be related to the end of a project, a promotion, a change in role or department, the end of a contract, a change in the information being accessed, or an employee termination and subsequent restriction on their account.

Access to resources is determined by dynamic policy, including the observable state of client identity, application/service, and the requesting asset, and may include other behavioral and environmental attributes.

This is a long one, but it’s less complex than it sounds. NIST defines different kinds of cloud models (private, community, public, and hybrid) and determines different levels of security controls for each. Different authentication and different transactions have different levels of risk across different kinds of clouds and need to be evaluated individually rather than with a blanket policy.

It basically means that a good Zero Trust Architecture does not incorporate one-size-fits-all policies but rather a dynamic set of requirements based on different factors, such as the originating device, the account, and the type of transaction requested. Engineering this is one of the significant barriers to developing a full Zero Trust framework.

The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Activity and event logging, individual device security level evaluation, and asset security recording; basically, this principle is the implementation of the continuous monitoring we’ve already discussed above.

You can’t know whether or not you’re secure without being able to check. You can’t know if you’ve suffered an intrusion without having activity and access logs to audit. Make no assumptions, gather data and verify instead.

FedRAMP generally promotes the use of a centralized security information and event management tool, which itself will be FedRAMP-approved, to collate and manage this information.

All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Account management will define the kinds of accounts that can be used or prohibited within each individual system, and these rules can and will change as necessary. Multi-factor authentication is required. Identity verification is critical.

This is another wing of the concept of the principle of least permission, that authentication is dynamic, it’s mandatory, and it’s strict. There is no hand-waving, account-sharing, or temporary escalated permissions allowed.

The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications and uses it to improve its security posture.

This is, again, continuous monitoring and improvement. Monitor everything, validate everything, proactively identify threats, improve security, and have policies and tools in place to detect intrusions or anomalies and deal with them. In summation:

• Verify all details explicitly, not implicitly.
• Practice just in time, just enough access, and the principle of least permission.
• Always assume the worst and proactively implement disaster mitigation rather than assuming the best.
• Keep your network segmented, and don’t assume trust based on location or other attributes.
• Practice zero user trust and implement verification and authentication processes to build that trust each time it’s needed.
• Automate security policies to take the margin of error out of human hands.
• Practice continuous monitoring through threat intelligence and analytics.

With all of this in place, systems can be much more secure and much less vulnerable in the event of a breach.

What the Future Holds for FedRAMP and Zero Trust Architecture

With the incoming administration, a lot is up in the air, especially regarding information security. For now, many of the policies and goals are still in place, but you never know when a memo may be deleted, or a rule rescinded.

For the time being, progress is being made on the overall implementation of FedRAMP standards according to the latest iteration of FedRAMP, FedRAMP 5. This latest update includes many changes and incorporates a lot of progress being made toward a fully Zero Trust framework.

If you’re having trouble keeping track of all of the information you need for a FedRAMP implementation or even for the transition between existing FedRAMP 4 guidelines and FedRAMP 5 guidelines, we’re here to help. As a FedRAMP-recognized 3PAO, we know our way inside and out of these frameworks, and we’re deeply experienced in FedRAMP from all angles.

To that end, we have many ways we can help you achieve FedRAMP authorization, potentially in as little as half a year. Our platform can help you track and collect relevant information, and our expertise can guide you towards the solutions you need to implement. All you need to do is request a demo or reach out and contact us today.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/fedramp/fedramp-meets-zero-trust/