NIST SP 800-207 - What does it mean for SaaS security

NIST SP 800-207 and Zero Trust

The National Institute of Standards and Technology (NIST) and Cybersecurity and Infrastructure Security Agency (CISA) in August 2020 published NIST Special Publication 800-207. This special publication follows the focused interest in zero-trust initiatives, which almost every organization has adopted to some extent since 2022. With more reliance on cloud-based and SaaS offerings coupled with the evolving state of remote work, this SP 800-207 offers sound design advice, implementation considerations, use case examples, and technology gaps for modern zero-trust architectures (ZTAs).

It is widely recognized that NIST has become the de facto standard not only for federal agencies, but also for private sector companies to strengthen the security of their information systems. It's also generally accepted that zero-trust has become the new set of principles that CISO's use to align their security programs. So for organizations looking to make zero-trust a practical reality, NIST SP 800-207 offers a great way to get started or use as a strong reference point.

Most organizations have made the necessary adjustments to remove all implicit trust from their users and systems and continuously monitor how users interact with data. However, security pros should look at zero-trust more as a vision - something organizations strive to achieve but never fully accomplish. Similarly, as with security programs in the general sense, most zero-trust initiatives are ongoing, with continual improvements and adjustments required to mitigate advanced threats.

A focus on resource protection

According to NIST, "zero-trust focuses on protecting resources (assets, services, workflows, network accounts), not network segments, as the network location is no longer seen as the prime component of the security posture of the resource."

Organizations no longer depend on the network as the backbone to security posture. Identity has become the new perimeter and it's critical to wrap security around all users’ various identities – especially the ones that are more privileged. The lines of what organizations consider “privileged" have truly become commingled. Under certain circumstances, a standard user can gain privileged access. However, it's not enough to secure the identity. It is critical to provide granular access controls to the actual resources so the organization can mitigate the risk of a company's crown jewels becoming compromised.

The data access control engine and policy elements covered in detail in this publication must be considered - it's not just NIST's zero-trust reference architecture; the same considerations exist within Google's BeyondCorp Enterprise. BeyondCorp Enterprise and NIST ZTA are the two most leveraged references for building a zero-trust security model. These logical components are foundational to these architectures, as they dictate which identities can access which resources.

Data access engines and policies, as defined by NIST, are what many would expect. The security team defines the access policy, and the engine enforces whatever corresponding (secure) workflow that has been set. But the policies are just a starting point in authorizing the appropriate access to resources, which need to be established with the principle of least privilege in mind. In the same vein, data access should be segmented in terms of "who should be able to access what, and when it should be accessed." It's necessary to consider the downstream implications of "what would happen if 'xyz' identity is compromised?" As with network segmentation, segmenting the access to data will minimize the blast radius in the event of a breach.

The policy engine becomes responsible for enabling the appropriate access to the identity or user. Security teams need context-based and dynamic data access policies and fully-automated engines to support these types of workflows. The team needs to connect self-service tools for data access monitoring, control, and remediation to the policy engine to enable IT and security teams to intervene manually and take immediate action if necessary. The engine essentially acts as the gatekeeper by granting, denying, or revoking access to the organization's resources, and the team needs a nimble approach to support flexible and dynamic workflows. Inputs from external sources, as well as observable information about users, attributes and roles, metadata sources, and historical and deterministic behavioral patterns should help power the policy engine.

NIST SP-800-207 necessitates a dynamic system

Today’s workflows are constantly changing and evolving, and that means that the levels of permissions available to specific users should also be dynamic, rather than static. 

Your access policy should be centered around the question of whether a particular identity should have access to a specific resource at this moment in time. 

Even if the user in question needed access yesterday, the situation may have changed overnight. It’s critical to implement a system that constantly reevaluates sharing, in order to ensure that users who have been granted permissions aren’t able to access assets once it’s no longer necessary.

To roll out this approach, your policy engine will need to take a number of factors into account, namely:

User identity

Elements of user identity that should impact access and permissions include their:

• Role
• Attributes
• Group
• HR status (e.g. just hired, departing)
• Risk level of user (based on past behavior)
• Is this user identity human or non-human? 

A Finance team member, for example, won’t need the same permissions for the same assets as a member of your DevOps team or HR department. 

Essentially, you need to critically evaluate the necessity of granting access to a user for a specific asset, based on what that user’s actual needs are at this moment in time. A user may have once needed access to a spreadsheet with payroll data for a specific project. That doesn’t mean that they should be granted viewing permissions for that sensitive data forever.

This is especially crucial when it comes to users with a history of suspicious behavior. For example, a user who has frequently copied, viewed, saved, or edited documents for no discernible work-related reason should not be granted excess permissions, and their existing access should be revoked in a timely manner.

Asset

Numerous elements of your asset should also be guiding factors regarding permissions.

You should take into the account the asset’s:

• Data sensitivity
• Recency
• Context (e.g., does it make sense that this asset would be accessed by this user, based on benchmarks for role, group and attribute? 

Staying on top of exactly what sensitive data are contained within your assets is key. Obviously, the sensitivity of the information in your resources is a major factor as to whether or not you want to share them with a larger number of users. 

This is also true for the recency of the resource: an older document with outdated data should still be protected, but it’s less critical than a newly updated asset with current numbers or information.

As mentioned previously, you need a policy that takes into account whether or not an individual asset is relevant for a specific user. As a rule, users should only be able to access and view resources that are necessary for their workflows, rather than being granted blanket permissions for company assets. 

Nature of interaction with resource

The way a user is trying to interact with an asset is also important for determining the best path forward. You should consider which behaviors or actions a user is attempting to perform within a resource, then make a decision regarding how to move forward.

Which of these behaviors is the user attempting?

• View
• Download
• Share
• Modify
• Delete

Some of these behaviors, such as simply viewing an asset, are inherently less risky than others (specifically, deleting or sharing an asset.) An action such as deletion should automatically trigger a red flag regarding that user’s permissions, as well as a look into whether or not they should be enjoying a level of permissions which allows them to perform that action.

Environmental factors

There are two main environmental factors that should also impact your decision-making:

• Network traffic
• Active security risks

If there is an excessive amount of network traffic that’s far above your baseline levels, or active security risks of which you’ve been informed, it’s clear that your access policies should adjust accordingly. Staying vigilant and responsive to evolving threats is critical for your SaaS security and keeping sensitive data safe.

What SP 800-207 mean for software-as-a-service security

Today, organizations of all sizes and types are universally adopting SaaS applications. Analysts that cover this area continually highlight the soaring adoption rates and predicted market spend in SaaS. SaaS applications now address almost every aspect of doing business, and they all let organizations become nimbler and more productive at a much faster rate. However, organizations can't make SaaS security an afterthought. Companies need to enable the business in a secure manner, and they need to do it in a consistent and centrally- enforced way.

Today, most SaaS applications and platforms are open by design via APIs for collaboration. Securing them can be a challenge for both CISOs and practitioners. Organizations need to ensure they have a consistent security strategy across all the critical SaaS applications being used to maintain business continuity.

If this ZTA publication elevates the importance of resource protection, then organizations should prioritize both a strong data access engine and policies. Within SaaS applications are some of an organization's most critical data and files. Per NIST, the agency defines zero-trust as "an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources." Let's quickly review these three areas of focus for context:

• Users: Today, most organizations have identity solutions to manage and secure access at the user level by establishing the appropriate levels of access for all the relevant identities for each user. Least privilege has become paramount here. "Never assume trust" demands authentication and authorization for each identity, and it needs to enforce it in a dynamic and strict manner before granting access.

• Assets: To connect users to the assets they need to do their jobs, organizations can bring zero-trust network access (ZTNA) into the fold. ZTNA solutions are a category of VPN-less technologies that deliver secure access to users wherever they are located, which is pretty much exclusive to remote or hybrid in today's environment. Security teams need to broker a secure connection for the user trying to access target systems and applications.

• Resources: Once security teams get past these two foundational components of identity security and ZTNA, users can now access, manipulate and share sensitive company data and files. Controlling "who has access to what" has become paramount in the world of zero-trust. Most organizations have introduced some of the tools and technologies to address identity, device, and network levels – but to protect critical resources, the security team needs to go beyond these three layers and into the SaaS application data layer.

Defense-in-depth with security wrapped around every identity and around every asset – each time they connect to business-critical applications takes a zero-trust strategy to the next level. A combination of preventative controls and detective mechanisms can help get companies closer to zero trust. It's not just about controls either. Organizations need to find the right balance between technology, people, and process. Adopt an "assume breach" mentality to the organization's security programs. In the context of zero trust, it's not a matter of “if" but "when," which demands that the company focuses on breach recovery and not just breach prevention. Ensure the success of the organization's IT and security teams. Start enabling the business in a secure way by extending zero-trust to the SaaS application data layer.

Secure your business SaaS Applications with Docontrol's SSPM.

FAQs

What is the NIST SP 800 207?

The NIST SP 800-207 is a document created by the National Institute of Standards and Technology, titled A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. This text provides an overview of how companies can create and implement Zero Trust Architecture within their cloud-based businesses.

NIST SP 800-207 specifically focuses on these elements as being critical for an ultra-secure cloud environment:

• Identity and Access Management (IAM)
• Network Segmentation
• Microsegmentation
• Continuous Monitoring
• Automation and Orchestration
• Risk Assessment and Adaptive Security:

What is Zero-Trust Architecture?

Zero-Trust is an approach to cybersecurity that’s predicated on the philosophy that a business’ assets and environments should be protected by the strictest possible settings. According to Zero-Trust, just because a user is part of your business environment does not mean they are inherently trustworthy. The guiding force behind Zero-Trust is the phrase “ never trust, always verify,” and companies following a Zero-Trust approach will use numerous strategies to abide by that principle. Typically, companies that have embraced Zero-Trust will leverage strong authentication methods (including multi-factor authentication), and policies that provide the least level of trust and access possible to users.

Is zero trust part of NIST?

NIST has long promoted Zero Trust Architecture as the standard for cloud-based companies to protect their assets. The NIST SP 800-207 sets out clear and specific protocols regarding rolling out Zero-Trust as a cybersecurity policy, along with general guidelines and policies for doing so. A Zero-Trust approach towards cybersecurity is a quintessential element of NIST’s best practices for businesses.

How is Zero-Trust different from my current cybersecurity strategy?

Traditional cybersecurity strategies make the faulty assumption that all users within a business environment are secure. They don’t take into account the option that a user could be compromised, for example by a phishing attack, and the “trusted” member of the team may actually be a threat actor. Zero-Trust works to avoid these pitfalls by requiring constant verification of user identities, as well as policies within cloud environments that ensure sensitive information is shared strictly on a need-to-know basis.

How do I change my environment to Zero-Trust?

If your organization is not currently using Zero-Trust architecture, there are a number of steps you should take to adopt this highly secure approach to cybersecurity.

• Define what Zero-Trust means for your organization. This can look different depending on your network, users, identities, devices, and other factors unique to your business. some text
  • For example, you can approach a zero-trust approach that assumes users aren’t safe until they’re verified multiple times, and that devices and even network connections are inherently vulnerable until proven otherwise.
• Assess your current sensitive data exposures and realities of workflows. For example, if all of your employees work from the office only, you don’t need to worry about a Zero-Trust network.
• Evaluate which solutions (like traditional VPNs) may not be relevant once you’ve moved to a Zero-Trust architecture.
• Embrace the principles of Zero-Trust, following best practices set out by NIST.
• Consider third-party solutions to help ease you through the transition and ensure you’re protected moving forward.