Finally, the response phase, which occurs after the alert has been verified as true and the incident has been declared, includes the expulsion of the threatening actor. After determining the scope of the incident (how many systems, users, etc. are involved), security teams have a number of options to remove the attacker, from rebooting the host to remove memory-dwelling malware to more drastic measures such as burning. their whole nature. Ultimately, success is dual here – either the enemy is completely routed or not.
The biggest mistake I encountered at this stage while on the red team was when the security team mishandled the incident, which led to an incomplete release and allowed us to persist in the environment for about 18 months (we were finally kicked out only when the server we persisted on was decommissioned by their IT team as part of the technical life cycle upgrade process) . Optimizing the response process to reduce the enemy’s chances of avoiding repulse comes down to having robust processes that have been retrieved, the ability to identify the full range of compromises, and the ability to ensure the complete elimination of the enemy.
Documents
Defining XDR evasion with sufficient granularity allows us to better see which part of our detection pipeline failed, and more importantly, what we can do to fix it. Multiple avoidances can be programmed into either an awareness (that XDR has detected malicious behavior), a detection (that XDR has identified that malicious behavior), or a response (that behavior has led to an adequate response from the security team). During your next confrontation with avoidance, push for descriptive language and see what improvements in your repair process can be made.
Source link