[BreachExchange] What chief data officers can learn from Facebook about building better big data security practices

[Audrey McNeil]

https://www.techrepublic.com/article/what-chief-data-
officers-can-learn-from-facebook-about-building-better-big-data-security-
practices/

The harvesting of millions of voter profiles by Cambridge Analytica in
order to exploit personal fears and influence the outcome of the 2016 US
presidential election has not made life easy for Facebook this recently.

Cambridge Analytica's data was enriched by a separate firm, Global Science
Research (GSR), which compensated hundreds of thousands of users to take a
personality test and agree to have their data collected for academic use.
At the same time, GSR collected information on the test-takers' Facebook
friends, building a database of tens of millions of user profiles.
Facebook's policy allowed only collection of friends' data to improve the
user experience, and barred this data from being sold or used for
advertising. Unfortunately, Facebook never confirmed that data policies
were followed, which they weren't.

Errant behavior like this strikes at the heart of big data stewardship and
governance. It delivers a warning to enterprises engaged in big data (as
almost all are) that the security and safekeeping of big data are every bit
as important as they are for traditional data systems.

Unfortunately, most companies are ill-prepared for the kinds of security
breaches and data compromises that threaten their big data on a daily basis.

What can chief data officers and big data project managers do to combat
these growing big data security challenges?

1. Identify your business risk

Situations like the one Facebook finds itself in can damage your brand and
your revenue-and it all started with lax big data governance and security
practices. Although it is IT that implements the technologies to protect
and prevent security and data breaches, none of this means very much if the
CIO, CSO, and CDO can't explain in plain terms to the CEO and the board how
a security breach that compromises documents containing vital customer
information can harm your business. How do you discuss the topic in
business risk terms? You say, "A customer data breach will cause our
customers to lose faith in our company and move to a competitor," not, "A
customer data breach will compromise our system and will take two days for
IT to repair."

2. Get the right kind of help

One of the reasons organizations lag in their big data security is that
many don't have the in-house security expertise, and it is difficult to
find this expertise in the job market. If this sounds like your company's
situation, don't get deterred by it. Instead, build the business case for
bringing in outside consultative help, because hackers are working every
day to compromise systems and steal information. You can't afford to wait.

3. Focus on social engineering

Much of Facebook's problem could have been avoided if someone in charge of
the data had followed up to ensure that it was returned as agreed, and not
given to others. This step wasn't followed—and it isn't clear as to what
procedures and practices were in place to ensure that it would have been
done. Possibly, employees inadvertently facilitated a data breach because
they did not follow their data security practices. When the employees
within your four walls are the culprits facilitating a data or security
breach, social engineering (i.e., training your employees so they respect
and execute appropriate security) is a major reason. This is why all
companies should focus on documenting and training employees in appropriate
data security practices. Periodically, refresher training in data security
should also be given.

4. Emphasize prevention, not detection

Detection can help you identify threats once they've invaded your systems,
but it's even better if you can prevent intrusions altogether. You can do
this by screening incoming documents, emails and other forms of big data at
the edges of your network-before you admit them into your central network
and systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180327/3c0d3996/attachment.html>