There have been many developments for policymakers, privacy advocates, corporate execs and, in fact, the public at large to contemplate considering recent news about Cambridge Analytica and the information collected by Facebook. The facts have been covered heavily elsewhere in the mainstream and industry press, so I’ll spare you a repeat play-by-play here. However, I do think there are a few important, timely observations to call out for leaders and practitioners in the security, risk and assurance communities.
Specifically, regardless of whether you are an end user of enterprise technology, an enterprise software vendor, or just an individual concerned about keeping your (and your household’s) information protected, there are some “lessons learned” to prevent or mitigate headaches down the road.
I should mention at the outset that these aren’t the only lessons that can be gleaned from these events, and they may not even be the best ones depending on your environment and circumstances. And, of course, we will continue to track developments as the story evolves, with perhaps more lessons on the horizon. Consider these, then, prudent measures for anyone – either observer or impacted party – and for organizations to benefit from, with current events serving as a useful “proof points” to explore at the enterprise level.
A punch in the face?
The first factor is being aware of permissions you give and agreements that you enter into – particularly in relation to privacy and security. Quite a few people were surprised and concerned about the volume of information collected by Facebook on mobile platforms, and many viewed with alarm the realization that Facebook collects call records and sent/received SMS messages on Android phones. However, the permissions requested by the Facebook-supplied app (which users agree to when they install) let it do exactly that. While some might view the outcome as undesirable, the app specifically requested these permissions and users agreed to them at the outset.
An analogy would be someone asking you if they can punch you in the face. If you give them your consent to go ahead and take a swing, are they in the right or in the wrong when they follow through? That’s a thorny question, and arguments can be made on both sides (for example, it might matter how they asked the question in the first place). But they did ask for your consent first and, if you don’t want to get punched, you can say no.
This might sound a bit like “blame the victim” – and, if so, that is not my intent. I bring it up because there are lessons here for those on both sides of this equation: end user and technology supplier alike. For the end user, viewing critically (and with a healthy skepticism) the permissions that apps request – and the measures agreed to by a supplier or service provider – is always an exercise in prudence. While some vendors might be more transparent about what they’re doing than others, keeping a handle on what is being requested (or promised) is absolutely critical. This is, in fact, what the Android permission system was built for in the first place.
This same principle extends beyond mobile. For example, if your cloud provider says it is performing a certain task (such as a security countermeasure), how confident are you in that? Are you checking? How would you know if not? For those supplying those services or products, being transparent about why you’re asking for the permissions you’re asking for (and how they’ll be used) can save you quite a bit of hassle down the road and being explicit about what you’re doing to keep information (and how) is likewise valuable.
The supply chain
The second item I’d call to your attention is the “transitive property” that exists between suppliers and the end entity – at least from a perception and customer point of view. For example, in this case, while it is true that Cambridge Analytica allegedly broke the rules and violated Facebook’s terms in how they acquired data, public angst (at least quite a bit of it) is directed at Facebook.
Are there reasons to be concerned about Facebook’s privacy and security more generally? Perhaps. But in this case, much of the pain that Facebook seems to be in results from actions taken by a member of its ecosystem rather than itself directly. As organizations become more interdependent on suppliers, contractors, business partners, and even customers, the lesson of how customers and the world at large will view a failure of trust is important. This is particularly true as it relates to private information about those users and customers.
So, lest we needed to be reminded, a lack of confidence in an organization’s data stewardship (i.e., a privacy issue, a security breach, or any other issue that impacts users’ information) caused by someone in the broader ecosystem can and often does generate ill-will to those connected to it via supplier, partner or other relationships. You’ve heard the old saying that “you can’t outsource liability”? It’s as true now as ever.
I’m sure as events unfold, we’ll all learn more about these circumstances and, with that, new lessons will continue to emerge that we can adapt to the work we do on behalf of our organizations. But starting with these, and working to make sure that we are aware of permissions and agreements that we might have entered into (including potential consequences that might arise), and the relationships that we have in our supply chain that can potentially impact us, is a useful way to ensure we’re keeping our organizations in solid shape.
Ed Moyle is director, thought leadership and research, ISACA. Read more ISACA blogs here.
