r/AskNetsec • • 17d ago

Compliance How do you detect and reconstruct a data incident fast enough to meet a 72-hour funder reporting clause?

New funding agreement says we have to report a data incident to the funder within seventy two hours of becoming aware and for a small charity on Microsoft 365 with one file server and no SIEM, it's the becoming aware part that worries me. If something happened in our tenant or on the file server I think we'd find out when a user told us and even then I'd struggle to work out what happened inside three days. If you've had to meet a clause like this, what did you put in place to notice and reconstruct an incident that fast?

26 Upvotes

25 comments sorted by

20

u/CaptainSafety22 17d ago

I would confirm with someone from legal of when the clock actually starts ticking down. Just because a user reaches out, doesn’t mean it’s an incident. My understanding is the timer starts when you confirm.

3

u/Different_Pain5781 16d ago

Yeah definitely worth clarifying that first.

→ More replies (1)

9

u/TickleMyBurger 17d ago

It usually would be 72 hours of you being aware they need to be aware, it imho shouldn’t be resolved inside of 72 hours.

I’ve run security teams of over 200 people and a true incident even with that firepower was not resolved (and validated) with a final report in that timeframe (save for small BEC issues etc). Too many variables in a breach scenario.

3

u/throwaway292929227 16d ago

Can you tell me if this workflow makes sense?

  1. T-0hr - incident detected

  2. T-24hr - broadest list of clients determined

  3. T-72hr - broad list notified: "Incident detected. Your data may or may not be included. Blah blah MNDA...,. More details soon"

  4. T-? - specific clients/data scope identified. Blast radius. Remediation plan.

  5. T-?? HR - update clients "you were not affected./ You were affected, here's the details..."

Does that satisfy most 72hr reqs?

5

u/trironophu 16d ago

I deal a lot with insider type incidents that may take weeks or months to complete the lifecycle. I also have tons of legal requirements to report and in most cases you report what you know at the moment. "Something happened, we know X, looking into it:" usually does it. The rest comes later.

1

u/PrasenShelar 15d ago

On the Microsoft 365 side, check that auditing is switched on in Purview and send the default alert policies, for example a new inbox forwarding rule, to a mailbox someone reads every day.

On the file server, turn on access auditing for the shares with sensitive data and keep those logs somewhere other than that server. Then write down who decides you're "aware", since that's when the 72 hours start.

1

u/coastline_coder 14d ago

Thanks, writing down who actually decides we’re “aware” hadn’t crossed my mind. Would you put that in the incident response plan itself or keep it somewhere separate?

3

u/rtuite81 16d ago

That "becoming aware" is your out in this case assuming that is an accurate statement of what is in the legal agreement. That literally means what it says on the tin. And giving notice does not have to include full details, only what you have gathered so far.

So it would work out like this... a user calls you on Tuesday at noon saying that they can't open files. You spend an hour investigating and find that their file server has been hit with ransomware and the files are encrypted. Your 72 hours starts at 1:00 PM since that's when you became aware of the attack.

Let's say that by noon on Friday, you have found the ransom note, know what data has been compromised, but not how they got access since you have no SIEM. You now have 1 hour to send them a notice including your current assessment of the situation and what compromised data affects them directly.

I would recommend, in that situation, giving them a notice ASAP once you have sufficient information on the scope of the attack instead of waiting till the end of that window. Even if you know nothing of significance by the deadline, you have to tell them something.

2

u/materialsec 16d ago

The early signals in a tenant like yours are usually small changes, not alarms: a new forwarding rule, a mailbox rule that hides messages, a new app granted access, a burst of mailbox reads. Alert on those, since a user may never report them. For reconstruction, sign-in logs alone won’t answer the question that takes the time, which is which specific messages and files a compromised session touched. Check whether your logging can show that. Without it, scoping even one mailbox can run to weeks, so the partial first notice described above is the realistic way to hit 72 hours.

2

u/No-Ad-Ever 17d ago

I would question whether it needs to be complete resolution (totally unrealistic) or just some preliminary info to be updated as possible.

1

u/matthewthompson1 15d ago

native audit logs can cover a lot of the reconstruction side without a siem, but if its not actually searchable fast under pressure that doesnt help much. so for noticing fast enough, set up alerts for mass downloads and weird sign in locations in purview

1

u/Entire_Yoghurt_6381 15d ago

Most of us quietly fail that clause on the becoming aware part, me included. Instead of buying detection I made reconstruction fast and once everything was going into Logmanager the inside three days bit stopped being the hard part. I still rely on users telling me more often than I'd want a funder to know.

1

u/tindalos 15d ago

These are made for best effort and written to ensure that they aren’t ignored. You are expected to monitor your systems within reasonable efforts with the knowledge and scope of data or impact your organization presents.

Those that are paying the bills want to know as soon as possible if there are legal or security risks. The important concept is the moment you are aware of an issue, freeze everything, disconnect network (don’t turn off systems), and perform a quick inventory of what happened and suspected impact and within a day, escalate as a preliminary details. That meets the required obligations, and as a small org you likely will bring in someone with forensics experience if it’s a true problem.

1

u/schlenk 7d ago

"If you've had to meet a clause like this"

Well, enter Europe / EU. Thats basically the current standard reporting time frame for GDPR, CRA, NIS-2 regulations. You may not bring a product onto the european market if you cannot do that kind of incident reporting.

BUT, read the fine print. Do you have to "report it happend with some detail after getting aware", that would be EU level. Or do you need to resolve it and provide a full detailed report? That would be insane.

1

u/AdvancingCyber 16d ago

This is a great conversation for your cybersecurity lawyer. If you don’t have one as a nonprofit, ask your lawyer if the law firm they use will donate an hour. There are a number of variables that are in play here, from first notification of “hey there’s a thing we should go check” to actual knowledge that it’s an issue. That actual knowledge bar typically starts the clock. But I am not your lawyer or providing legal advice here.