Aaron SotoJul 7
Matt Linton 

I was mulling over a principle of incident response today and wondered what others in my field might think.

Yes or no: "To operate effectively, incident responders need to be able to obtain at least the same level of access to a system as the attacker has potentially obtained."

Jul 7 at 2:30amWeb
Show threadSteveJul 7
@amuse not directly in incident response so take my comments with a grain of salt, but yes, in the absence of an audit trail spelling out what has been accessed (and even with it in case there are bypasses to audit logs from the level of privilege the attacker reached) you are working with 1 hand tied behind your back if you can’t obtain the same level of privilege and access the attacker had
Show threadRootWyrm 🇺🇦Jul 7

@amuse as the person whose job it is to tell you that you absolutely cannot have access and absolutely under no circumstances will we be installing <insert stupid tool here>:
Yes.
Once the system is suspected to be compromised, it no longer matters.
And as soon as it's suspect, if infra isn't already planning to nuke it from orbit so that it doesn't matter, FIRE YOUR INFRA TEAM. OUT OF A CANNON.

(You still cannot have root or domain admin for anything on network.)

Show threadJon WilsonJul 7

@amuse Yes. But potentially with different side effects.

If the attacker has accessed PII and bypassed auditing, I may need, in very limited circumstances, to access the same PII. But auditing must remain on for me. I go through the front door always.

Show threadMatt Linton Jul 7

@bassthang I definitely didn't mean to imply unaudited access 😁

But this is a great use case. If the attacker potentially accessed pii, then you need your response team to access the pii so that they can notify people that their pii may have been accessed!

Show threadPseudo NymJul 7

@amuse

I've not worked on government nor military systems that use (dusts off dormant neurons I haven't used since the CISSP exam most of a decade ago) the Bell-LaPadula security framework (i.e. "read down, write up") but in such a case, I assume you would need higher access than the attacker had, at least sufficient to read audit logs and anything the attacker wrote to the system. By definition that would give you read access to everything they had read access to as well, and more. Right?

Show threadCGRAYJul 7

@amuse I guess it depends what kind of IR processes you're running. If its a classic internal IR team in a relatively complex on-premise environment I would say that your IR team probably don't need local admin or application admin rights to servers/apps but should have the ability to elevate to DA equivalent as well as isolate, freeze, export images from the hypervisor as well as escalate quickly. I don't think I've seen anyone do it in a repeatable safe way yet.

I think my question is how do you do this in a constrained manner? Its not appropriate to have domain admin/global admin, but there needs to be a way to enact general as of yet undefined actions in an environment which means that prescriptive "I must have helpdesk admin and security contributor" doesnt make sense as the scope is too limited for fly away incident response.

Maybe the answer is trust your tooling to proxy this level of access, such as an EDR disabling accounts at the behest of a user that has lower permission, or design automations in your tooling that have limited scopes but large impact with high auditability.

Show threadMatt BrownJul 8
@amuse broadly agreed; but presumably a lot of this boils down to how much you trust your logging/audit trails, both to obviate the need for the access in the first place, but also to track it if you do grant it...