X

Cloud Security Perspectives and Insights

  • News
    January 7, 2020

Why Red Teams Rule the Cloud!

David B. Cross
SVP SaaS Security

This week, I have a contributing guest author, Kris Hatlelid, Vice President, SaaS Cloud Security engineering.

How well would your organization fare in the face of a full-blown cyber attack? If that question makes your palms sweat and your eyes shift, read on for some lessons we’ve learned at Oracle about penetration testing and red teams.

Different approaches, different results

Penetration testing involves discovering as many vulnerabilities and misconfigurations as possible in an environment. Subsequently, a penetration test engineer provides a formal report listing the found vulnerabilities, risk assessment, and evidence of the results, with steps required to reproduce the exploit or vulnerability.

Red teams perform simulated attacks by attempting to compromise the critical functions of a system. Red team activities measure how well your people, networks, applications, and physical security controls can withstand an attack from a real-life adversary. While penetration testing focuses only on individual systems, applications, or deployments, the target for a red team exercise is to evaluate the broader strategic environment, people, and processes.

The strategy of red teams

Red teaming always starts with a strategic plan which includes the target environment, the specific goals for the exercise, the timeframe to accomplish the evaluation, and the rules of engagement. The exercises often are planned and performed over a longer period and are designed to explicitly emulate a potential adversary or malicious insider.

Once the plan is established and documented, a red team often spends the next 6-12 weeks performing a set of functions using a multitude of tools, techniques, and approaches, which include:

  • Surveillance
  • Footprinting
  • Establishing foothold
  • Privilege elevation
  • Account and credential mining
  • Pivoting through network
  • Data exfiltration
  • Persistence

Why these functions?

Each of these functions is required for discovering or testing an organization and services defensive posture. The goal is to identify unknown vulnerabilities; configuration issues; gaps in detections, process, or people; and ultimately, to determine if a specific objective can be reached like data exfiltration from a database or denial of service.

A red team will often mimic a given adversary to see if a services defense would be effective in detecting them. A defensive team, like a blue team or a SOC/DART team, would attempt to detect, observe, and stop the red team if possible, learning from the exercise. This contrasts with a penetration test, which would go through a set of known vulnerabilities and network configurations with a very defined scope and duration for the purposes of a report for compliance.

What does success look like?

Initially, the red team will have a goal, and the first level of success is around accomplishing that goal or demonstrating that the defenses of the blue team are enough to have detected the red team. Often there is a set of documented learnings from both the red team and blue team. Ultimately, success is based on a well-structured analysis of the activities and the recommended actions, changes, and/or defensive and detection improvements to be implemented by the environment DevSecOps owners.

Can you automate red team activities?

Red teams carefully probe, explore, hunt, and exploit unique bugs, configurations, gaps in process, etc., that are environment specific and not standardized industry packages or modules. They must perform the analysis dynamically to discover the evolving venues and vehicles based on research using the same techniques current malicious attackers may use in deployed internet environments today. Key examples would be spear phishing for credentials, social engineering, or simply adapting to detected defenses.

Automating and templatizing these functions is often very difficult, if not impossible, given the infinite variety and breadth of space in the applications space. Red teams use automation in their exploit tools, and often, such tools can and will be incorporated by Detection and Response teams, once the tools are proven to be effective in a detection infrastructure. This is one of the best practices that the Red Team and the Oracle SaaS Cloud security organization performs today.

Summary

Both penetration testing and red team activities are critical for cloud security and application environments, and accordingly, performed by the SaaS Cloud Security (SCS) organization at prescribed and planned intervals. The combination of the required penetration testing functions and the proactive adversary emulation activities in the red team with proven blue team defenses built and owned by the SCS organization is what makes Oracle SaaS a very successful and strong cloud provider in the modern cloud marketplace.

 

Join the discussion

Comments ( 2 )
  • Philip Waters Thursday, January 23, 2020
    Spot on! "Automating and templatizing these functions is often very difficult, if not impossible, given the infinite variety and breadth of space in the applications space."

    A single product we've seen has over 500 separate subnets each with a unique function, Tens of thousands of hosts in the environment and over a quarter of a million network security rules.
    Hosts have dozens of unique processes listening on the network, and leverage a variety of unique code libraries. Containerization can multiply the attack surface of single asset.
    Having a red team find it first is super important for both Pen Testing and Red Teaming. In the first case to validate security strength in a multitude of permutations, and in the second case to press hard and persist strategically against a specific target of value.
  • Philip Waters Thursday, January 23, 2020
    Having a red team find it first is super important for both Pen Testing and Red Teaming. In the first case to validate security strength in a multitude of permutations, and in the second case to press hard and persist strategically against a specific target of value.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.