Introduction
With the transition to NIST SP 800-53 rev 5 comes the requirement for more proactive, adversarial testing for those wishing to meet the moderate and high accreditation standard. Admittedly, the control as written leaves this requirement open-ended and in need of some interpretation to properly apply in the FedRAMP context. Recently, the FedRAMP Program Management Office (PMO) hinted at upcoming guidance to do just that. In the meantime, we aim to give you some context around Red Teaming, what it means in terms of FedRAMP, what to expect, and how to plan and execute an effective Red Team exercise to do more than cross of CA-8(2) from a control’s checklist.
Red Team exercises are employed to simulate attempts by adversaries to compromise organizational systems in accordance with applicable rules of engagement.
– NIST SP 800-53 rev 5 CA-08(02)
Practical Changes
While FedRAMP accreditation and authorization already requires offensive testing in the form of a penetration test, and has since the inception of the program, the addition of a requirement to perform a Red Team exercise is a separate effort that won’t be covered by the penetration test baked into the existing accreditation process. The main question here that must be answered is – what changes in real terms with the addition of this requirement?
First some necessary background, at the most basic level a Red Team exercise and penetration test are related but markedly different activities with distinct goals and outcomes – when performed correctly. Where a penetration test aims to be an exhaustive evaluation of a target attack surface (in this instance a Cloud Service Offering (CSO)), a Red Team exercise starts from a set of objectives based on the security posture and maturity of the target organization – beyond the exclusive boundary of the CSO. This means identifying specific scenarios to exercise to build a picture of what is or isn’t working (more on this later) within the broader security program.
Scope – The exercise must include the corporate boundary and may include associated personnel and elements of the CSO where they become accessible from within the corporate boundary (this will often be a primary target objective as the most critical control boundary).
Method of Operation – The Red Team exercise must be conducted in a manner that is threat-representative. The Red Team should attempt to simulate the mode of operations, as well as current tactics, techniques, and procedures (TTPs) of real-world threat actors to the extent necessary to evaluate the preventative, detective, and response capabilities of the Cloud Service Provider (CSP).
Output – The Red Team exercise must emphasize actionable improvements to the preventative, detective, and response controls of the CSP security program, which may include technical and processes-based recommendations, in addition to reporting of any identified vulnerabilities.
In short, the Red Team exercise should cover previously out-of-scope aspects of the CSP operational environment, utilizing a different mode of operation, and delivering value in the form of strategic drivers aimed at uplifting the CSP’s entire organizational security operation.
Doing Red Team Right
Now, let’s look in more detail at what it takes to plan and execute an effective Red Team exercise in three phases – setup, execution, and after action.
SETUPBefore the project starts is the most critical element of a Red Team exercise. During the planning phase, the Red Team and CSP should be in active discussions to design realistic attack scenarios paired with actionable target objectives based on the target landscape and operational posture of the CSP security program. Remember, we’re looking at the organization’s overall landscape and how that intersects with the CSO, not just the CSO itself.
Planning attack scenarios should not be arbitrary. Scenarios should be informed by an understanding of what the relevant and likely avenues for access an attacker is likely to traverse in a real compromise scenario. When available, up-to-date threat intelligence and threat research should be used to help shape the most useful scenarios for the target organization. Similarly, the objectives associated with these attack scenarios should also reflect the internal control boundaries present within the target environment. Objectives should be reasonably specific so that actionable information can be gathered on log telemetry, proactive detection, and response posture in the event of a live compromise.
Here’s an example of an internal compromise scenario and objective:
Scenario – Compromise of single sign-on credentials of a representative organizational user, granting access to corporate systems and services generally accessible to employees and/or contractors.
Objective – Demonstrate access to internal systems, services and/or data in a privileged context within the build, deploy, or administration path of the cloud platform.
An understanding of attacker methods and those used against a particular type of organizational target are an element to consider here. Wherever we can ground attack scenarios in observed attacker behavior versus theoretical avenues of attack, we should do it. Fortreum highly recommends this is included as part of scoping and objective setting.
Ceded access, while often overlooked, is also an important approach here. It will likely be necessary to intentionally place the Red Team into specific access contexts to effectively exercise key objectives to accurately assess the CSP’s preventive, detection, and response capabilities.
EXECUTIONThe lifting here is almost entirely on the Red Team. Their responsibility is to tailor tooling and methods to simulate attacker behavior, suitable to the specified objectives, to the degree necessary to both identify technical gaps and observe the detection and response posture of security operations. This means realistic command and control, remaining conscious of likely detection points during reconnaissance and actions on objectives, and selectively triggering events to initiate a security response.
The target organization should not modify their standing security posture (unless necessary to enable certain objectives) and respond to events in a realistic manner. This is called an “exercise” for reason, it’s a live opportunity to play out (at least part of) a realistic breach scenario to see what is or isn’t working. Having both perspectives on the activities performed during the exercise will only improve the result.
AFTER ACTIONWhen the exercise is over, the work isn’t done. The Red Team and CSP Security Team should collaboratively review the results – what objectives were met, methods used and their effectiveness within the environment, telemetry and alert data capturing Red Team activity, etc. Then, collaboratively discuss how these elements describe the posture of the security program. From that discussion the Red Team should provide both tactical and strategic recommendations targeting specific control enhancements and overall program improvement for the CSP.
As far as what to expect in an actual report, expect it to describe the methodology and activities slated to be performed, outline a schedule of testing activities, organizational resources performing the test, escalation and deconfliction procedures, and appropriate authorizations from the CSP. The report should summarize the test results, outline the exercised attack path(s), annotate any findings, and provide associated recommendations for remediation.
Don’t expect an exhaustive list of vulnerabilities, remember this isn’t a penetration test.
Conclusion
Hopefully this post has helped to clarify some of the upcoming (expected) changes to offensive testing related to FedRAMP and what Red Team exercises can (and should) look like when the time comes to take on that effort. The last thing I’d like to emphasize here is the importance to collaboration throughout this process. The more open and collaborative the effort, the better the experience and outcomes will be. The goal for the Red Team is to provide meaning full input to better the security program of the organization we’re working with, and I hope this serves as a reminder that we all be working to raise the security bar and make sure the Security Team is ready for every eventuality.
Should you have questions about your Red Team readiness and methods, reach out to us at info@fortreum.com or Contact Fortreum Today.
