How to manage a data breach

3. How to manage a data security incident Initiate response ASAP • Time is one of your two most important assets • You will start in a hole if the incident is not identified and escalated immediately • Have a policy with a clear duty • Train to the duty

4. How to manage a data security incident DON'T REST ON ASSUMPTIONS

5. How to manage a data security incident Don't rest on assumptions • Information is your other important asset • Probe in areas of discomfort* • Find the facts and the evidence • Ask, "What data elements are we dealing with?" • Ask, "Who is affected?" • Ask, "What is the risk to the affected?" *vendor breaches raise special considerations

6. How to manage a data security incident KEEP THE BALL MOVING

7. How to manage a data security incident Keep the ball moving • Incidents can be complicated • You deserve reasonable time to understand • Your timeliness, however, may be judged • So strive for progress and constant movement

8. How to manage a data security incident DON'T RUSH

9. How to manage a data security incident Don’t rush • Once you put information on the public record you are stuck with it • Once you put information on the record you suffer a loss of control • Never go to the regulator for advice before you know what you are dealing with • Strive for a confidence level of 90% • If you need to, send a "placeholder" notice

10. How to manage a data security incident OBTAIN OBJECTIVE INPUT

11. How to manage a data security incident Obtain objective input • You are human correct? • You may be influenced by a feeling of guilt • You may suffer a temptation to downplay a problem • Enlisting an outside lawyer and/or crises communication professional may help

12. How to manage a data security incident OBTAIN TECHNICAL INPUT

13. How to manage a data security incident Obtain technical input • IT investigating IT can be a problem, especially in smaller organizations • If "who" and "how" need to be determined, you may need technical (forensic) help

14. How to manage a data security incident TAKE A BROAD VIEW OF NOTIFICATION

15. How to manage a data security incident Take a broad view of notification • Consider statutory and professional obligations • Consider the forseeability of harm • Consider whether people are going to find out • Yes, there are cases in which notification is not appropriate

16. How to manage a data security incident PUT YOURSELF IN THEIR SHOES

17. How to manage a data security incident Put your self in their shoes • And ask, "What would I want to know about this?" • Describe all data elements clearly • Include all of the basic facts that shed light on the risk

18. How to manage a data security incident DEMONSTRATE COMMITMENT TO DOING BETTER

19. How to manage a data security incident Demonstrate commitment to doing better • Please avoid platitudes like "we value your privacy" • Demonstrate your commitment by saying what you are going to do • Draw on a strong root cause analysis and make a genuine commitment to things that will be effective

20. How to manage a data security incident APOLOGIZE

21. How to manage a data security incident Apologize • Beware of your jurisdictional exposure when considering statutory privileges • Good information supports a good apology • Acknowledge, accept responsibility, express regret • By a senior spokesperson who can demonstrate empathy

22. How to manage a data security incident - Ten tips from a breach practitioner Dan Michaluk September 24, 2015

23. How to manage a data security incident - Ten tips from a breach practitioner Dan Michaluk September 24, 2015

Notas del editor

PRESENTATION -foundation for good incident response -incident response plans -communication when in crises -notification and remediation RE-FRAMED – MORE PRACTICAL INSIGHT -ten tips – will weave in my bullets -art of breach response LAW FIRMS – SPECIAL CONTEXT -most of the incidents I manage are "affected population incidents" -that's the type of incident I'm going to speak to -recognize that law firms are often faced with "vendor-client incidents" -less challenging and more challenging -less challenging because you have one primary relationship of concern -more challenging because the risk of a breakdown process caused by self-protective behavior (a challenge in any incident) is more acute
This is the first of three tips about timing I suspect you all know the general sequence of incident response I describe it as follows 1. identify and escalate 2. contain 3. investigate 4. take action 5. close (every good process has an end) Good timing is the essence of disciplined incident response I can't stress that enough
So the first tip is to identify and escalate without delay Note that identification (intrusion detection) is now an IT function some would say is a required part of a reasonable data security program It is also an element of response Identification problems happen all the time – foreseeable risk -example – malware problem on computer lab, kept deep in IT for weeks -individual who created the problem may self-assess with bias (USB key is somewhere in my house… it will show up) -individual who created the problem may try to self-remedy Features of response policy -clear duty to report -hinges on the identification of problems and potential problems -clear prohibition on self-assessment -clear reporting lines -define who receives and triages the report (with redundancies) -clear prohibition on telling others (if something becomes widely known internally that will prejudice your response)
In the process we're moving to containment and investigation Investigate means investigate There will be many assumptions that can be brought to bear on a typical breach and a (dangerous) natural "opportunist's bias" – the tendency to employ wishful thinking that can lead you to "incident response light" Example – Apple XCode hack -the prevailing theory is now public -developers in China accessed a corrupted version of Apple's development software from a third-party site, which caused their applications to be infected with XCodeGhost malware subsequently distributed through the Chinese App store -if you were Apple -write this down -validate with facts and evidence -evaluate the reliability of the facts and evidence -adjust -lots rides on the theory -Who might be affected? -How?
Here are the more particular prescriptions and some common questions Let me focus on the footnote because law firms are vendors -put yourself in your client's shoes -something bad has happened -it could be associated with significant liability to others -you need to manage -you need need to investigate -but the vendor has all the information -practical advice we give to your clients is to have strong written contract terms that require post-incident cooperation -the practical advice I'd give to you as a law firm manager is to be prepared to be as open as possible with your client, even if the facts suggest that you have messed up (or even if you don't yet know) -this is business advice in essence, but there are likely legal (fiduciary) and professional duties that also favour transparency -there is always reason to keep detailed information about security controls secret, but you'll need to employ a balance
-Manage these as crises -People need to prioritize response over their regular duties ………. Leading towards containment and ultimately some sort of action Principle – embedded in breach notification legislation Do so "without unreasonable or undue delay" Media and the public get this It's one of the things you will be judged on Good metaphor is a sports metaphor (apologies) -allowed to pass the ball before shooting -but keep it moving Does happen -month slow off in identifying -unexplained month delay in investigating -the whole premise of incident response is about getting ahead of it and being seen to be responsible -delay can undermines this strategy to the point so that, if you don't have a legal duty (rare for law firms), you chose to keep the whole thing under wraps
Here's just a summary of the basic prescriptions Use this to address my bullet on "the foundation for good incident response" -the foundation is good data -data that fosters a quick and reliable understanding -see this stressed recently by the Ontario IPC in addressing hospital snooping cases -want comprehensive access logging
But wait, don't rush! This is very common -clients come to me having already notified the regulator -now what do we do? Manage the breach in accordance with its "clock speed" -how many people (internally and affected) know about it -the degree of harm that is foreseeable -assess clock speed and assign a number one to five Example of a 1 -network compromise indicating potential access to business information Example of a 5 -e-mail containing attachment with SINs sent to 4000 employees Mange the breach to slow the clock speed -limit the group inside your organization who is involved -limit decision-making by e-mail (appropriate for other reasons)
Here are some particulars Two points here One – don't strive for perfect knowledge, that's unreasonable and will make you too slow Two – there is a concept of a placeholder notification -if notification is necessary -can send something that says what you know and includes a commitment to send further information -not ideal but may be necessary when your clock speed is high
Here's the self-interested pitch for using an outside breach coach …
Here's my cross-examination witness We're all brilliant analytical minds We all have impeccable judgement But when our own interest is at stake we suffer bias Two biases -guilt… unnecessary self-flagellation -opportunism - opportunist bias -pull in competing directions, which causes dysfunctional decision-making (paralysis and group think) Put in incident response policy (which can have a very practical focus) -experts with bench strength on retainer (insurance) -legal, communications -authority to draw upon that resource without approval
Let me start by that outside IT services (especially forensic IT services) can be expensive I also think that as a principle, incident response, needs to be proportional to the risks (Too many breaches approach each breach as life threatening. Use a risk matrix.) But it may be necessary to seek outside IT assistance
The probing will often lead you to questions about technical matters The questioner needs to be conversant with technical matters Just helps things move faster Also, IT may resist -workload -conflicting interests So get someone on your team who can help you meet the "conversance requirement" Can be a conversant lawyer Can be someone from IT security Or you can use an outsider Not always a forensic need, but can be If you are looking to find the bad actor and recover losses forensics may be important
Process again 1. identify and escalate 2. contain 3. investigate 4. take action 5. close Leads to taking action Not about notification, but certainly tends to be the focus Other action outcomes -do nothing -make an offer to affected individuals -sue someone for data recovery -change your process
Set aside giving notice b/c it's required or b/c of foreseeable harm – easy Here are some factors for you to consider Point - Notification is part of a strategy that rests on the complete and early acceptance of responsibility -hurts less overall to tear the band aid off quickly -rests heavily on the following ideas -accidents happen (consistent with negligence law) -we have nothing to hide -we care about you -legal basis – response is relevant to the moral damages analysis Very strong trend towards "voluntary" notification You will be compared against the right-thinking corporate citizen … Are cases when notification is not appropriate -risk is low -create unnecessary worry
Here's how to notify
Driven at answering the questions, "What would I want to know about this?" All data elements All basic facts that shed light on risk -How long was the data exposed to theft? -Can the people who received the data inadvertently trusted? Why? -Are there any facts that suggest why the computer was stolen? -Where was the unencrypted USB key dropped? -What knowledge have the police conveyed? (Be careful.)
I mean to stress the word "demonstrate"
Platitudes are very annoying -We value your privacy -We've amended our policy so x doesn't happen again Let your actions speak Rests on a good investigation and good root cause analysis Other ideas -Hard to defer taking a position for too long -Don’t commit to new policy w/o committing to communicate and/or train to it -If people are responsible, hold them accountable! (Strong focus of IPC/Ontario.)
Apologize ………. -check your jurisdiction -it is privileged in most jurisdictions -it will reduce your exposure to moral damages -this means you can't lose and you can only gain -watch, however, the scope of your "apology" -I'm sorry. This shouldn't have happened. -We were completely negligent and are at fault. -having said this, the facts are the facts -a strong investigation will support a strong apology, which may get you a better outcome in the end
This is a summary slide Lots of literature from communication pros on what makes a good apology

How to manage a data breach

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a How to manage a data breach

Similar a How to manage a data breach (20)

Más de Dan Michaluk

Más de Dan Michaluk (16)

Último

Último (20)

How to manage a data breach

Notas del editor