Security Think Tank: Get basic security policy right, and the rest will follow

I looked in the archive of my back articles for the Security Think Tank for inspiration for this, my first article for Alex Scroxton, who has taken over from Warwick Ashford as the security editor at Computer Weekly (best of luck, Warwick, in your new position).

A theme that occurred more than a few times could be summarised as “Get the basics right first”. In my many years as an infosec consultant, I’ve noted that in quite a few organisations, the decisions about securing data were left solely to the IT or IT security group, be that internal or outsourced. Although any decisions on how data was finally secured were often tempered by IT budgetary constraints. 

One of the key basics comes, I believe, from a realisation that the business must own its data, not the IT group. This translates to the business articulating (to IT) who owns any specific piece or grouping of data, noting that there must only be one owner for any particular grouping of data, for example the finance director owns all the finance data.

The data owner must then clearly identify the sensitivity of the data under their ownership, any necessary legal or regulatory compliance requirements and, importantly, who or what process can be allowed access to their data and what those persons or processes can do to the data, for example create, update, only read, be denied access, and so on. The data owner should also specify the required availability of their data and its lifetime and archive time. 

These non-technical attributes of data can then be translated, not just into technical solutions, but also supporting policies and procedures. They also give IT and other groups in an organisation, such as compliance, building security or HR, a common platform for discussion.

For example, the compliance group might require some of the attributes to be tightened where a business unit wants an internet-facing customer portal (for example, General Data Protection Regulation (GDPR), encryption standards for overseas access), while the finance group might want access to their systems limited to a set of authorised processes, not people. The IT group might also question some of the attributes, as a technical solution might be very difficult or expensive to achieve and manage. 

I noted earlier that a data set can only be owned by one person and that would mean that the person would be authorising each access request and well as undertaking regular reviews of who has access.  In large organisations, although the director or senior manager would be the actual data owner and set the high-level attribute policies, the actual day-to-day operation of authorising access requests and associated monitoring would necessarily be devolved. 

Another basic comes from IT groups not fully leveraging the in-built security features of server and network operating systems. Examples I have come across more than a few times include where a company file system is flat, so that key servers are in the same address space as users and so not protected from them.

Another issue is where users have local administrative rights on their PC. By so doing, a piece of malware could gain access to the PC, which, in turn, could promulgate itself throughout the network. Administrative staff must have at least two user identities, one for day-to-day administrative work (emails, report writing, accessing network management tools, and so on) and at least one to undertake administrative tasks on the network, its servers and user PCs (new software installs, patching and software updates, for example).

Another simple basic is the principle of “least privilege”. Just because a person is a manager (senior or otherwise) does not mean they need access to every file in the network, nor do they necessarily need full access privileges to the files they should be able to access – read-only privilege might be more than sufficient. I have seen a number of successful ransomware attacks where a senior manager opened a file that released ransomware and, as they had wide-ranging write access, the whole company was taken off the air. 

So the message is, get these basics right and you might find that you don’t need quite so many whizzy security applications or appliances.