Schellman becomes The First ISO 42001 ANAB Accredited Certification Body!

Contact Us
Services
Services
Crypto and Digital Trust
Crypto and Digital Trust
Schellman Training
Schellman Training
Sustainability Services
Sustainability Services
AI Services
AI Services
About Us
About Us
Leadership Team
Leadership Team
Corporate Social Responsibility
Corporate Social Responsibility
Careers
Careers
Strategic Partnerships
Strategic Partnerships

Recommendations For Self-Managed FedRAMP Red Team Exercises

Federal Assessments

When FedRAMP issued Revision 5 in May 2023, the changes included a new requirement for a red team exercise in addition to the already-mandated penetration test. Now that Rev 5 is officially being enforced as of 2024, organizations pursuing FedRAMP Authorization must get this new obligation right.

FedRAMP permits organizations two options to satisfy their red team exercise requirement:

  • You can have one performed by a third-party assessor organization (3PAO); or
  • You can perform one yourself internally or via another provider (though your 3PAO must further attest that the prepared red team test plan and red team report meet or exceed their expectations).

While it’s ultimately your prerogative to determine whether you self-manage your required FedRAMP red teaming, as of February 12, 2024, the FedRAMP Project Management Office (PMO) has not published red team guidance. As the leading provider of FedRAMP assessments on the current Marketplace, we thought we would leverage our experience as both a 3PAO and as red teamers to try and fill that void.

In this article, we’ll outline the industry standards when it comes to red team deliverables so that if you decide to complete this exercise yourself, you can better ensure that your work meets FedRAMP standards and that you aren’t set back in your pursuit of Authorization.

 

How to Successfully Perform an Internal Red Team Exercise for FedRAMP

A red team exercise’s holistic nature means there’s quite the onus on cloud service providers (CSPs) performing their own as part of the FedRAMP journey, but what follows is what our team at Schellman would expect to see from a client-delivered red team exercise in order to sign-off on the effort.

Red Team Test Plan

The first necessary element we’d need to see is your red team test plan, which is a formal document detailing multiple components of your exercise. This document should be written before you begin the actual assessment, and the assessment should follow this plan as closely as possible—the more formalized this document is, the better.

At a minimum, we expect the following:

Plan Section

Explanation

Scope

The scope of the exercise dictates what is allowed to be targeted.

An important note: This is not limited to the FedRAMP boundary—your entire organization should be in scope. That being said, hosts, URLs, etc. do not need to be defined since they’ll be encompassed within the wider scope.

Defined Goal(s)

Without any defined goals, a red team exercise risks becoming a normal pen test or phishing exercise—when you set a red team goal, you designate how the exercise will challenge your current defensive strategies (which you’ll then attempt using several avenues during the actual exercise).

(When Schellman performs a FedRAMP red team exercise, we always set the goal of accessing the FedRAMP production boundary without any initial access to your organization.)

Escalation Process

Outline a process for the testers to escalate issues should they discover something that needs immediate attention. Usually, this means alerting the organization’s CISO (or a backup to the CISO).

Start and End Dates

Document the start and end dates so that your 3PAO can determine if the exercise occurred within a reasonable timeframe for FedRAMP requirements. (The exercise usually takes multiple or several weeks.)

Red Team Exercise Execution

Once the plan is done and documented, remember that a real-world attacker won’t tell you you’re being attacked, and so your red team exercise should follow the same practice! As such, limit the overall knowledge that your assessment is happening to:

  • Executives;
  • Your CISO; and
  • Your designated backup contact to the CISO.*

*Additionally, if status reports are issued, they should be purposefully vague.

Some important things to consider when performing your red team exercise include:

  • Do not limit it to a traditional pass/fail phishing exercise, since real-world attackers won’t just stick to phishing attacks when trying to breach your organization.
  • Remember, during a red team exercise, your entire organization is in scope.
  • Consider that real-world attacks are usually performed in tandem, and even chained together to accomplish the red team’s goals. 

With all this in mind, your team should take the exciting opportunity to use diverse attack scenarios, such as:

Attack Scenario

Explanation

Open Source
Intelligence (OSINT)

Scour the Internet for your sensitive data that may be publicly available, such as:

  • Company code repositories
  • Employee code repositories
  • Previous breaches
  • Unrelated database breach compilations

Credential Stuffing

Attackers can readily search for organization e-mail addresses within existing breach compilations and attempt these credentials against targets such as:

  • VPNs
  • Single sign-on (SSO) providers
  • Remote administration services (i.e., SSH, RDP)

Targeted phishing campaigns

Target specific individuals based on “reconnaissance” as real-world attackers would—in other words, create more realistic e-mails aligned to the target’s job role. 

External Network Penetration Testing

In addition to identifying outright exploitable vulnerabilities, attackers often gain other valuable details from external reconnaissance:

  • Services to attempt authentication against
  • Forgotten or old services
  • DNS misconfigurations (DMARC, dangling entries, etc.)

(Attackers can then wield this intel to then chain to other attacks.)

Web Application

Since web applications often sit within the FedRAMP boundary, you’ll want to target these where possible, while still keeping the red team’s goals in mind.

Some example attacks include:

  • Using a typical Cross-site Scripting vulnerability on a customer-facing website in a campaign to acquire an employee’s SSO session
  • Compromising a web host and then stealing the credentials of administrative users

Internal phishing

Using an employee’s e-mail account that was compromised earlier, send an incredibly convincing phishing e-mail or instant message to another employee and continue with the attack chain until the red team’s goal is met.

Vishing

When attempting vishing—that is, social engineering via phone calls—specific individuals and help desks can make great targets due to their level of access. If you have departments still using fax machines, consider targeting those as well.

Physical penetration
tests

Attacks don’t need to be completely limited to the virtual realm—you can simulate and assess material attack vectors like:

  • Could an attacker posing as a contractor compromise an on-premises network closet?
  • Would an employee plug in a malicious USB stick they found within their building?
  • Could a hardware keylogger be placed on a desktop?

Wireless attacks

Because many devices—like printers—emanate their own Wi-Fi signals—consider attempting to compromise these, as they may serve as a pivot into an internal network.

Other wireless attacks to consider imitating include:

  • Capturing credentials via rogue access points
  • Mousejacking (during which malicious keyboard and mouse actions are inserted to compromise a device)
  • Testing whether key presses can be recorded

For any and all scenarios you choose to test—assuming some form of access is obtained—perform lateral movement just as a real-world attacker would to identify how far the access could get them to achieve the original goal of the exercise.

For example, if a system administrator’s SSO account becomes compromised, determine what level of access the attacker would then gain—would they be able to compromise another host or user? If so, recursively continue the lateral movement process until the red team’s goal is achieved.

Red Team Report

Finally, you’ll need to prepare a red team report. Similar to the red team test plan, this document should also be highly formalized and incorporate the scope, goals, escalation process, and dates of your exercise.

In total, your red team report should detail the following:

Section

Explanation

Executive Summary

For individuals who need a quick reference, include a summary that highlights the results of the exercise.

Framework(s)

Specify the red team framework you used within your report.

(The most popular red team framework at the moment is MITRE ATT&CK).

Attack Path Narrative

Discuss the overall thought process during testing, as well as attempted and successful attacks.

Identified Findings

Describe all identified security gaps, including but not limited to:

  • The initial access method
  • Level of access obtained
  • Lateral movement attempts
  • A high-level description of any sensitive data accessed or exfiltrated

Remediation Plan(s)

Detail your remediation plan for each identified security gap.

 

Moving Forward with Your FedRAMP Red Team Exercise

Red teams are a relatively new compliance need in the cybersecurity space. For FedRAMP, they are a brand new requirement, so expect a degree of growing pains as both CSPs and 3PAOs navigate these changes.

And while our aforementioned standards to formally attest your self-managed exercise can appear subjective—and may vary from other 3PAOs—you at least have a baseline for what you’ll need to create and include when internally performing your required FedRAMP red teaming.

That being said, if you’d like to learn more about red teaming—or if you’d like to assess whether Schellman is the right 3PAO/red team to partner with for your FedRAMP compliance—reach out to our team today.

About Austin Bentley

Austin Bentley is a Manager with Schellman, based in Kansas City, Missouri. Prior to joining Schellman, Austin worked as a Penetration Tester for a large financial institution, specializing in Application Security and Internal Pentesting. Austin also led and supported various other projects, including security automation and code review.