Maksim Kabakou - Fotolia
Security Think Tank: Understanding tech is key to effective data segregation
What are the security benefits and challenges of segregating IT environments, and how best are these challenges overcome?
In my many years of practice in the InfoSec and InfoAssurance arena, one of my most-found issues was that of organisations not understanding the benefit of both segregating and limiting access to data.
Even where I have found segregated environments, there have been occasions when the understanding of the technology in use has been, shall we say, basic.
One of the simplest segregation techniques is to have multiple file locations, be they dedicated drives, dedicated folders, or a combination of both.
However, splitting data up in this fashion, whilst making it easier to locate data, does nothing for security unless access profiles are applied and enforced (for example, an HR file location should be accessed only by HR staff).
But access profiles must also be applied to the files themselves, allowing only certain groups (people or processes) the ability to carry out certain functions (for example, read only, write only, or read and write).
Where possible, access profiles should also be made context sensitive. This includes things like out-of-hours restrictions, restrictions based on type of network access (office vs mobile) or contractor vs permanent staff.
Profiles (or roles), which are associated with a person’s (or process) network access credentials, need to be carefully planned and regularly reviewed for applicability. I suggest annually at a minimum, and whenever a network/infrastructure upgrade occurs or a company reorganisation occurs.
Read more from Computer Weekly’s Security Think Tank about the security benefits and challenges of segregating IT environments
If you make the profiles (roles) not granular enough, security won’t be as good as it could be, but if you make the roles too granular, it will be a nightmare to manage. What files a person (or process) can access and what they (or a process) can do with a file must be based on the principle of least privilege to do their job, not on seniority or ease of infrastructure implementation.
The damage that can be caused by ransomware where senior managers have been given universal access can be quite devastating. With the exception of trusted IT staff, no person in an organisation, senior or not, should have universal access to all data. Directory systems such as Microsoft Active Directory or Unix/Linus LDAP Directories provide a rich range of attributes, so I recommend using them.
On the subject of IT staff, they should have at a minimum of two sets of access credentials, one limited for normal day to day office functions (emails, report writing, etc.) and others with administrator or audit credentials for network operations such as fault finding, implementing new or updating existing systems, reviewing logs, etc. Regular staff profiles should not include “administrator” abilities even for their own PCs.
In the design of a network infrastructure, data might be stored in segregated dedicated networks supporting such technologies as network attached storage (NAS), storage area network (SAN) or unified storage devices. Such dedicated networks would typically be connected to the main infrastructure via a firewall.
While firewall rule sets will provide a level of protection to files, complete reliance should not be placed on them. You will still need file access profiles.
A word of caution
Many infrastructures are based on virtualisation technologies and the security of the underlying hypervisor or virtualisation engine needs to be accounted for. An example from my recent past gives an indication of the type of issue to be aware of.
A client had a firewalled storage area network. The firewall was rated at evaluation assurance level (EAL)4+ and the rule sets were audited as being fit for purpose. The overall network architecture was solid and there was an Ethernet switch on both sides of the firewall.
However, closer inspection identified that the Ethernet switches were in fact virtualised ones and ran on the same switch hardware. The switch operating system was only certified at the EAL2 security level and therefore negated (by bridging) the EAL4+ security of the firewall.
The data did indeed need EAL4+ security, so installing two physical switches solved the security issue – but the trap of using virtualised switches is an easy one to fall into. Of course a single Ethernet switch with an EAL4+ rated operating system with appropriate rule sets could have also been a valid solution.
