Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If a service was compromised, what evidence is enough to reconnect it?

8 decision pointsThe pack behind this answer: Security Incident Management

Add to board memo

The short answer

Recommendation
Reconnect only when there is evidence for each of the incident plan's recovery criteria, confirmed by the person responsible for it. Reconnect in stages under closer monitoring, and close the incident only when the monitoring period passes without the attacker returning.
Reasoning
The pressure to reconnect is strongest when the evidence is thinnest. A patch or a clean scan shows the weakness is closed; it does not show the attacker has gone. The criteria ask for the way in found and closed, backups or images checked before use, systems patched, scanned and monitored with credentials changed, the owner's test, and the monitoring period started. A missing criterion goes back to the phase that owns it.
Considerations
  • In the pack's defaults the monitoring period is 7 calendar days for Severity 1 and 2 incidents. The plan sets none for lower severities; the email compromise playbook leaves a Severity 3 period to the incident manager to set and record.
  • Any backup used must date from before the earliest sign of the attacker, as well as before the damage, and be checked for integrity and scanned before use.
  • If the business needs the service sooner, agree a temporary workaround. Do not reconnect a system that may still let the attacker in.
  • The ransomware playbook's checks are a sound model for any compromised service: each criterion confirmed by the provider or owner who can show it.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartA compromised service is ready to come backDecisionIs it contained, with no attacker activity since?DecisionHas the way in been found and closed?DecisionHas everything the attacker left been found and removed?DecisionWere credentials that could have been taken changed?DecisionWas any backup or image used checked before it was used?DecisionIs it patched, scanned and monitored?DecisionHas the service owner tested it and confirmed it works?OutcomeDo not reconnect yet: close the gap firstStepReconnect in stages and start the monitoring periodDecisionDid the monitoring period pass with no sign of the attacker?OutcomeClose the incident

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 12 steps.

  1. Start

    A compromised service is ready to come back

    The pressure to reconnect is usually strongest just when the evidence is thinnest. The plan's rule is that nothing returns to normal service until the recovery criteria are met, so the attacker does not come back through the same door. Each question below asks for evidence someone can show, not an opinion.

    In the pack

  2. Decision

    Is it contained, with no attacker activity since?

    Contained means the incident can no longer spread or cause new harm. The plan sets no quiet period. The ransomware playbook, used here by analogy, confirms containment only after no new encryption, alerts or attacker activity across every site and hosted service for 2 hours in its defaults. Evidence: the monitoring provider's confirmation and the containment time in the case log. If you cannot say, the answer is no.

    In the pack

  3. Decision

    Has the way in been found and closed?

    The first recovery criterion: the cause is understood well enough that the same route in is closed. Evidence: the route recorded in the case log, such as the phishing email, the remote access or the unpatched system, and the change that closed it. Patching the weakness you suspect is not the same as finding the route the attacker used.

    In the pack

  4. Decision

    Has everything the attacker left been found and removed?

    Assume the attacker had more than you have found. Look for new accounts, mail rules, scheduled tasks, remote access tools and changed settings on the sign-in directory. Evidence: the responders' list of what was found and removed, and the monitoring provider's confirmation of no activity since containment.

    In the pack

  5. Decision

    Were credentials that could have been taken changed?

    Change the credentials of every account used on an affected system, including service and administrator accounts, and end all signed-in sessions. The plan sets no order. The ransomware playbook's order, a sound model here by analogy, is administrator accounts, service accounts, remote access, the backup system, then users, all from clean devices. Evidence: the reset record with dates.

    In the pack

  6. Decision

    Was any backup or image used checked before it was used?

    The second criterion. For ransomware, each copy must date from before the earliest sign of the attacker, not just before the damage, be checked for integrity and be scanned before use, with the check recorded. Where nothing was restored, record that it does not apply and why.

    In the pack

  7. Decision

    Is it patched, scanned and monitored?

    The third criterion: patched, scanned and monitored, with credentials changed where they could have been taken. The ransomware playbook's checks, used here by analogy, are each system rebuilt or restored, patched, running endpoint protection and monitored before it reconnects. Evidence: a scan result, the protection console showing the system, and the monitoring provider confirming it sees it. A clean scan shows the weakness is closed, not that the attacker has gone.

    In the pack

  8. Decision

    Has the service owner tested it and confirmed it works?

    The fourth criterion: the owner of the service, not the people who restored it, tests it and confirms it works. The ransomware playbook asks for that confirmation in writing, and it is a good habit for any service. Keep it in the case log.

    In the pack

  9. Outcome

    Do not reconnect yet: close the gap first

    A missing criterion is not a formality. Send it back to the phase that owns it: containment, eradication or recovery. If the business needs the service sooner, that is a conversation about a temporary workaround, not a reason to reconnect a system that may still let the attacker in.

    In the pack

    See also

  10. Step

    Reconnect in stages and start the monitoring period

    The fifth criterion is that the monitoring period has started. The ransomware playbook reconnects one site or service at a time under closer monitoring, watching for the indicators found; the same staging is used here by analogy. In the pack's defaults the period is 7 calendar days for Severity 1 and 2 incidents. The plan sets none for lower severities; the email compromise playbook leaves a Severity 3 period to the incident manager to set and record.

    In the pack

  11. Decision

    Did the monitoring period pass with no sign of the attacker?

    Any new sighting of the indicators, or new attacker activity, means the eradication missed something. The service goes back to containment, and every criterion is checked again.

    In the pack

  12. Outcome

    Close the incident

    In the plan, the incident manager closes the case when the criteria are met, the monitoring period has passed without recurrence and the case log is complete. The ransomware playbook adds that every report due has been made. Severity 1 and 2 incidents then get a post-incident review within 10 working days of closure.

    In the pack

Practical checklist

  1. Confirm containment with the monitoring provider and record the containment time.
  2. Record the route in and the change that closed it.
  3. List what the attacker left and confirm it was removed.
  4. Change credentials that could have been taken, end signed-in sessions, and record the dates.
  5. Check any backup or image for integrity and scan it before use, or record why none was used.
  6. Confirm each system is patched, scanned, protected and monitored, and get the service owner's written test result.
  7. Reconnect one site or service at a time and start the monitoring period.
  8. Close the incident when the period passes without the attacker returning, every report due is made and the case log is complete.

Evidence to have ready

  • The containment time and the monitoring provider's confirmation of no activity since.
  • The route in, the change that closed it, and the list of what was found and removed.
  • The credential reset record with dates, and the backup integrity and scan results.
  • For each system, the scan result, the monitoring confirmation and the service owner's written confirmation.
  • The start and end of the monitoring period, and the closure record.

Assumptions

  • The incident has been declared and is being run under your incident procedure.
  • The criteria and periods shown are the defaults in the CISO Times incident management pack. Your own plan may set different ones.
  • The ransomware playbook shows how each criterion is evidenced for ransomware. The same checks are used here as a model for any compromised service.

Not covered here