Security Think Tank: Balancing data accessibility with security controls

Core challenges

But there are challenges. Cyber security teams often focus on the macro and micro levels, looking at specific fields, such as how individual files are accessed and how this access will be granted. At the other end of the spectrum, data architects often work at the conceptual level, or on data models that assume an ideal of free information flow. 

Areas of conflict include infosec professionals objecting to data being combined and publicly accessed, or finding that users have stored duplicate copies outside centralised business intelligence tools, while data architects often don't want to deal with network segregation.

Problems are exacerbated by the lack of interaction between the two groups. In some organisations, this occurs only if security wants details of what data is present within a data object, or when the architects need confirmation that they can store more data in yet another cloud provider.

Finding common ground

Key to working together better is for each side to comprehend both the concerns of the other group and their context, and for this knowledge to be used to work out what can be done to avoid that friction.

For architects, this means understanding an organisation’s classification schema and what constitutes sensitive, or privileged, data. From there, they can be more selective in what data is extracted from systems and databases, and be conscious of creating privacy or data sensitivity issues if combining two (or more) sets of data reveals more information than intended. 

For example, a list of factories exported from one source is fairly anodyne, but used in conjunction with separately sourced information on hazardous products and shipping details potentially flags where these materials are stored and puts the enterprise at risk.

Security, on the other hand, needs to apply appropriate controls based on the data present and the way it is accessed, rather than adhering to an inflexible set of policies and standards. Controls should reflect the way the business works and protect the data requester from causing an accidental data breach, rather than forcing onerous controls that employees will bypass if they prevent them from getting on with their job.

Communication is key to foster this shared understanding and this can be reinforced by specific actions in a project delivery framework, such as a data privacy impact assessment during high-level design or a data sensitivity check once the solution has been built. However, the aim is to get people working collaboratively and in a more continuous manner. This is achieved more easily via good personal working relationships and when each team has empathy with the other’s pain points.

We are moving further and further into an age where even the smallest organisations are collecting more data per second than they have in the past 10 years. This makes it critical that architects understand what they are collecting, why they are collecting it, and where it is being stored, while security needs to recognise that not everything needs to be protected to the same level, or in the same way.

Organisations are looking at a future where having thousands of data points is the norm, from smart offices controlling the lighting, to devices in the field collecting telemetry. Volumes will be such that a company cannot possibly store and organise it all, nor can security expect to protect everything. Rules will need to be set to decide what should be retained (the key elements for reporting) and what can be discarded.

As data combines and manipulates itself into thousands of different forms within seconds of being processed, applying a hard-and-fast classification schema will not be possible. New tools and ways of working need to be developed to identify the “sensitive” elements within a data flow (a person’s name, or a bit of intellectual property, for example) so that the relevant policies are applied only to this subsection. This will improve the efficiency of any controls, rather than treating an entire data source as one item and applying the same level of control to everything, regardless of the need.

Similarly, as more data is collected from multiple sources and combined, the inadvertent creation of privacy issues needs to be considered. It is one thing to collect telemetry from a company vehicle, but if the business intelligence (BI) data lake then combines that with the HR department’s list of drivers, and a list of who is driving which vehicle, then suddenly we are tracking individuals on a new level, which goes against most companies’ privacy policies.

Viewed in these terms, it is clear why it is not an option to keep the worlds of infosec professionals and data architects separate and unconnected.