Garrett O'Hara is Principal Technical Consultant at Mimecast and isn't afraid to tell us what he thinks. In this short chat, we explore data availability in a virus-infested psyche (sorry, world).
iTWire: Can we start with some simple background? How did you get to where you are now? And what's Mimecast's reason for existing?
O'Hara: Well it was spring '75 when my parents had their second bundle of joy… wait that's probably not what you want to hear. I spent about a decade as a developer back when hard coded passwords were all the rage, HTTP trumped HTTPS and dev was just dev…the 'ops' and 'sec' bits hadn't been codified - sorry for the pun. The work led to technical consulting for other companies and doing presales engineer work in lots of cool countries, and then ultimately into the security world. Its cheesy but it feels like I've found "my people" in this industry and particularly Australia. Lots of good people (some of whom I get to interview on our "Get Cyber Resilient" podcast) and we're working on things that matter to whether businesses stay open.
And Mimecast… well it exists to make organisations cyber resilient. We have a tag line "stop bad things happening to good people." Our pedigree is email security and we've parlayed nearly 20 years' experience in that space into web, awareness training and proactive brand exploitation protection. Our approach is purely cloud and always has been. The platform was built to hyper scale… that's powerful because we can stack a lot of tech inline to secure email and web traffic, but also use global views to quickly protect organisations from what is happening. So, minimising the patient zero problem.
The other parts of resilience are end user awareness, protecting and allowing access to data during or after an event, and making sure email services can run if there is a planned or unplanned outage.
iTWire: Allow me to open with a slightly oblique question. What's the most important thing that most corporations fail to understand when it comes to the data they collect and hold?
O'Hara: First things first: you need to understand what the data is. That can be an incredibly difficult thing to work out for bigger organisations. Employee data, customer data, operational data, marketing data, sales data. Where is it being generated or collected from? How sensitive is it? Can it be deanonymised? Does it contain personally identifiable information?
iTWire: 'Data,' it's such a small, insignificant word, isn't it?
|
O'Hara: That one seemingly simple word - "data" - opens a pandora's box of questions to define the exact thing that needs to be stored and protected. Without understanding what the data is you cannot decide where the safest place to store it is. And if the work involved in understanding the data doesn't make you curl into the foetal position in a warm shower shuddering with anxiety, you probably haven't understood the size of the task… especially if an organisation hasn't been founded and grown with security/privacy by design.
Second things second: you need to understand the staff and outsiders. At this point you can move from the shower to the bar. Cut to the chase and buy a bottle of spirits. Anything else, you're in denial. Who are the staff? Do they need to access the data? Why do they need to access the data? Do they need to access all the data, or a subset? How is data access logged? How are the audit logs stored and who needs to access those? Who needs to access the logs of who accessed the audit logs? Maybe buy another bottle of spirits. How will staff access the data securely? How will accessed data be controlled? DRM? DLP technologies? What level of authentication and authorisation will be needed for different datasets? Who manages those? What processes are in place to ensure the security of the data?
iTWire: I think I need to share that second bottle you just bought! So, after a couple of deep sips, in your opinion, what's the safest way to store all this critical data?
O'Hara: When we say safest, what is the priority for the data in terms of confidentiality, integrity and availability (CIA)? Does "safe" mean that the data is secure in terms of confidentiality? Does it mean secure in that we can ensure data integrity? Does it mean that the data needs to be available to staff and outsiders? It will be all three in reality. And the CIA triad considerations all affect each other and will often lead to the security vs productivity conundrum.
iTWire: Can you pass that bottle back again? I think I need it. So, you've started to describe just how ugly the problem is, do you see any best practice?
O'Hara: Be like Estonia - creator of the world's first "data embassy" As a very advanced digital society, Estonia is incredibly reliant on the data it stores. When figuring out what "safest" meant for their country, they realised that in the event of a land-based attack they needed their data to reside outside of their country. But that runs into data sovereignty issues. The powers that be had a lightbulb moment and they created data embassies, which aren't based in Estonia but are totally controlled by them. [See note below]
iTWire: Thus keeping their data safe.
O'Hara: Actually, I really like to use the word "safest" rather than "safe" here. "Safe" implies an absolute which doesn't exist. An attacker with enough motivation, time and resources will be able to get into anything. If you've used an incredibly strong encryption methodology, I'll use what Bruce Schneier calls "rubber hose cryptanalysis." Part of thinking about this should have us thinking about what will happen if the data is exposed regardless of us doing everything well. Here's an obligatory comic to explain it.
(Paying due respect to copyright, iTWire has chosen to link rather than include the XKCD cartoon that O'Hara is referencing. Needless to say, it is riffing on Schneier's 'rubber hose' techniques.)
iTWire: So, how about we collect nothing? 'Lean and mean,' as they say.
O'Hara: How can we make our jobs easier by collecting and storing as little data as possible? There is a cost here in terms of processes and processing. That said, purging data that is not useful, or needed, helps with the job of storing and securing the data. If we can avoid storing a dataset, and ideally not collect it in the first place, then we have fewer things to think about. This works at different scales from the choice of which fields to include in an employee or marketing survey, to the decision to collect/store entire datasets - for example, the all-too-common scenario of a database that sits on hardware in the corner of the server room that hasn't been accessed in years.
iTWire: In an attempt to do serious harm to your thoughts, I wonder if you've simply given us a choice between sitting on the beach and diving in over our heads!
O'Hara: If data is the new oil, then humans are swimming through an oil spill. The collection of vast amounts of attribute and behaviour data, overlayed with exceptional analytic and predictive tools is incredibly useful. It helps manage traffic, track health epidemics and spot trends that may cause societal harm. But at the same time, it creates election manipulation, political divisiveness and addictions to screens. Maybe we need a data collection moratorium; just until we figure out what it all means.
iTWire: The 'natives would get very restless' if that were to happen. How could they continue to provide the, let's call it, out-of-band data to people who probably shouldn't have it?
O'Hara: This raises all sorts of questions about "outsider" data access: how; why; from where; on what devices; with what level of authorisation and authentication; access revocation; and access lifetime.
Deep breath after that! So…. to answer the question:
iTWire: We asked a question? I'm sure we were only here for the spirits!
O'Hara: The key question is: "Where's the safest place to store it and how do you protect it?"
And the answer is: That depends. Maybe on a hard drive bought at a hole-in-the-wall computer shop, using a one-time pad and a guard dog that isn't fed nearly enough. And laser beams.
There are incredibly strong encryption methodologies that may fall apart if we get quantum computing working. There are physical locations that are incredibly secure. And then there are humans who are and will always be vulnerable to mistakes, blackmail, being disgruntled…we haven't quite figured out how to fix that problem just yet.
iTwire: So, basically, we're screwed. Good to know. Garrett O'Hara, thanks for your time, I think.
O'Hara: You're very welcome. Hey, can I have that bottle back?
Estonia's Data Embassies: https://www.oecd.org/gov/innovative-government/Estonia-case-study-UAE-report-2018.pdf