Home Forums Change control in red team exercises

This topic contains 1 reply, has 2 voices, and was last updated by  thelowerrandomproton 1 month ago.

  • Author
    Posts
  • #443388

    w0lfcat
    Member

    According to [Penetration Testing For Dummies](https://www.wiley.com/en-my/Penetration+Testing+For+Dummies-p-9781119577485) book chapter 9, page 121;

    >You will likely need to do a change control to document the fact that a change (scanning, testing, and attempting of changes on your network and systems) will be taking place.
    *Change control* is necessary to document what is happening but also to log the time, date, and other useful information needed if an incident arises from the scan itself and support teams need to mobilize to assist. A critical prep item should be a contingency plan if something goes wrong.

    Is similar control required for red team exercises?

    The reason I’m asking this is because:

    >Penetration tests are not focused on stealth, evasion, or the ability of the blue team to detect and respond, since the blue team is fully aware of the scope of the testing being conducted.

    while

    >Red teaming projects differ in that they are heavily focused on emulating an [advanced threat actor](https://www.ibm.com/security/solutions/detect-advanced-persistent-threats/) using stealth, subverting established defensive controls and identifying gaps in the organization’s defensive strategy.

    Reference: [https://securityintelligence.com/posts/penetration-testing-versus-red-teaming-clearing-the-confusion/](https://securityintelligence.com/posts/penetration-testing-versus-red-teaming-clearing-the-confusion/)

    If a change ticket is submitted for red team exercises, won’t it defeat the purpose to be stealth as blue team would be able to check the ticket number, and to find more details about the exercises such as exact date and time?

    What is the common/right process for this?

  • #443389

    thelowerrandomproton

    So during our red team exercises we keep extremely detailed notes of every step we take. We also have certain logging mechanisms that are done both from our lab and on our laptops. At the end of the engagement, we hand everything over to the client and then we brief them. We then work with them to resolve all of the issues we found. We don’t alert the blue team or whoever’s on the client side unless it’s a really serious issue (E.g. we find someone (who is not us) breached their systems or a mission critical system has a very serious vulnerability).

You must be logged in to reply to this topic.