Development and operations a practical guide
Download 4.62 Mb. View original pdf
|
- Navigate this page:
- Consider This Red Teaming may use offensive security techniques but is not offensive in nature. It is arguably part of the security defensive community.Red cannot exist without Blue
- Cost and Funding
| Key Chapter Takeaways Red Teaming is the process of using Tactics, Techniques, and Procedures (TTPs) to emulate areal- world threat with the goals of training and measuring the effectiveness of the people, processes, and technology used to defend an environment. Red teaming focuses on goals related to training blue teams or measuring how security operations can impact a threat's ability to operate. Technical flaws are secondary to understanding how the threat was able to impact an organization's operations or how security operations were able to impact a threat's ability to operate. Vulnerability assessments and penetration tests are focus on technical flaws that result in mitigation and attack surface reduction. Consider This Red Teaming may use offensive security techniques but is not offensive in nature. It is arguably part of the security defensive community. Red cannot exist without Blue Homework 1. Develop a lexicon of terms to maintain a common unbiased base of understanding that can be shared and referenced among internal and external stakeholders. Create or adopt a definition of red teaming and store in the lexicon. Adopt the Is vs Should be approach when developing threat-based scenarios. Perform the Adversarial Mindset Challenge in the Appendix to better understand the adversarial point of view. Engagement Planning All engagements must start with Engagement Planning, the first step in a Red Team engagement. It is not possible to conduct a professional and successful execution without fully understanding the goals and scope of the engagement, understanding the resources required to execute, and creating a solid plan. Cost and Funding As with any security effort, cost and funding are significant influencers in planning, scheduling, and executing a Red Team engagement. Several factors contribute to the overall cost and scope of an engagement. Each element should be carefully reviewed and documented explicitly in a contractor agreement. Regardless of team status (internal or external service provider, each factor applies. Scope Scope plays the most significant role in the overall cost of an engagement. Consider scoping a vulnerability assessment. There is often a considerable benefit and need to conduct a full-scope, in- depth review of every node in an environment. The equipment and software employed are usually part of the priceless additional licensing requirements, setup and configuration are already being conducted, and the addition of target space to the contract is generally cost-effective. This scoping effort is arguably straightforward and typically broken into the asset type being assessed. Scoping could be split into workstations, servers, network components, or any logical asset category. Now consider scoping a Red Team engagement. There are significant differences between an in-depth assessment of 1,000 nodes vs. one of 14,000 nodes. Accurate assumptions about the environment can be made based upon the data obtained from a few similar nodes however, this data does not necessarily enable the Red Team to meet the objectives of the engagement. In general, as a target environment grows, so does the complexity of its security controls (and ideally its effectiveness). Sometimes, that complexity benefits the environment. Other times, it introduces weaknesses a Red Team may use advantageously to gain access or achieve threat-based goals. In either case, the Red Team has to manage the complexity of tactics to test and validate the overall threat strategy accurately. Red Teams are known for leveraging multiple systems or data points and "bending" configurations to meet the engagement's needs. Common security tools and applications don't regularly discover many of these flaws or paths. This understanding drives scope development toward a scenario rather than testing every node in a target environment using standard security testing tools. The scope should always directly and effectively support the operational objectives being measured. |