Development and operations a practical guide
Download 4.62 Mb. View original pdf
|
- Navigate this page:
- Custom Breach Model
- Assume Breach
- Indicators of Compromise
| Consider This Assuming a breach can lead to disbelief in the results. All too often, defensive staff and even senior managers attempt to downplay legitimate Red Team activities. With the assumed breach, more immature organizations may attempt to do so by hinging an activity’s success to being “provided access to the system or network rather than recognize the lessons learned by understanding how the defending team was able to execute its defensive strategies. Custom Breach Model Custom breach models allow the Red Team to design scenarios that enable the test or measurement of specific areas of concern to the target. A Custom Engagement Model: May start at any point in a threat cycle Focuses on any of the phases as designed by the goals and objectives Is highly efficient where limited staff, time, and funds are available Is nearly always announced and coordinated with real-time interaction The Red Team should most often use an Assume Breach strategy. This strategy was made popular by Microsoft and is admittedly more philosophy than deduction. Reactively waiting for evidence of a breach causes companies to reveal not only that they have been compromised but that they have been compromised for years. Indicators of Compromise Although it is commonly thought that adversaries can cleanup after themselves, it is almost impossible to remove all evidence. A good security operations team has the potential to find even the most advanced adversaries. Evidence is always left behind. Indicators of Compromise (IOCs) are artifacts (bits of information) that identify or describe threat actions. An IOC can be anything used to identify a threat action including, but not limited to: Unusual network traffic Unusual user activity Geographic-specific connections Increased network traffic Increased database reads Unusual file changes or modifications Registry changes or modifications Specific naming or usage conventions Identifying actions or action attempts Signs of DOS/DDOS Most security organizations rely on some trigger to take action. Systems such as network sensors, security sensors, or even end-users typically trigger an investigation of "strange" behavior. When a security team responds to a trigger, they are challenged to test their ability to leverage IOCs to identify, contain, and eradicate a threat. This play between Red and Blue generating and identifying IOCs is at the heart of Red Teaming. In order to replicate a malicious actor, a Red Team must understand a threat's TTPs. These TTPs are emulated by controlling the "when" and "how, as well as the type of IOC generated or left behind. Given this concept, Red Team Operators must know what indicators are made by a tool or action. If those IOCs are acceptable, they can proceed. If the IOCs are not acceptable, and the action is performed, there is a significant risk of exposing the Red Team before planned expectations. Not only is the management of an IOC necessary for threat emulation, but an IOC can get you caught when the timing is not appropriate and may also put an entire engagement at risk if not controlled and managed. Download 4.62 Mb. Share with your friends:
|