cyber-security
A data access policy becomes an issue for any company as soon as it accumulates a considerable amount of valuable and sensitive data. That doesn’t mean the policy is always in place when it should be, or that it’s implemented properly.
How should the policy work so that it doesn’t interfere with security and increase risk? It’s simple: Every employee should only have access to the data that’s related to his or her own job. In practice, this is a bit more complex.
In his recent article Kirill Kruglov, Kaspersky Lab’s expert, writes about protecting critical systems from unauthorized changes and reducing the possibility of attacks on the corporate network. As the proper course of action he lists the following items:
- specify those objects (equipment, systems, business applications, valuable documents, etc.) on the corporate network that require protection;
- describe the company’s business processes and use those to help determine the levels of access to the protected objects;
- ensure that each subject (a user or a corporate application) has a unique account;
- limit subjects’ access to objects, i.e. to restrict the rights of the subjects within the business processes;
- ensure that all operations between the subjects and the objects are logged and the logs are stored in a safe place.
At least three of these items are directly related to data access rules.
Keeping in mind the assertion that an employee should only have access to the data needed over the course of their work, this means that in a more restrictive environment any given user has very limited privileges in the system they’re working with: no software can be installed to the workstation by the user, web access is limited to those few resources they’re supposed to visit during the day, and access to corporate documents and applications is limited to their role.
Employees typically don’t like “excessive” restrictions such as limited web access; they would also prefer to have the ability to install software, and not to request a system admin’s support for such a “mundane” task. Besides, it may take some time between sending the request and getting help from the admin, especially if the company is large and IT workers are few.
Kruglov further writes that in practice the proper ways aren’t followed. For instance,all corporate documents are stored centrally in shared folders on one of the servers of the company. Access to critical systems is denied to everybody but administrators – any administrator – can log into the system remotely to quickly repair any failure, and sometimes administrators use a “shared” account.
All corporate documents stored in shared folders on just one server? Helpful, but unsafe for a number of reasons.
If there are documents that only a “selected few” are supposed to view and change, no other person should even see them. If these documents can be viewed and modified from any corporate account it opens up the possibility of an employee using his own device (an Android-based smartphone, for instance), logging into the corporate network, and infecting the system with a piece of malware.
Imagine getting a Cryptolocker-like ransomware into your file server. Sorry, if you already don’t have to imagine this – more than a few fellow IT workers told us about such experiences and only in a few cases were those problems resolved without huge losses.
Crypto, for example, would encrypt any data within its reach, so if all of the documents are stored together “in one basket”, damage may be deadly.
System administrators’ shared accounts are also a big “don’t”. For an attacker, getting access to such an account is like acquiring a master key: all systems of the targeted company now lie at their feet. And if there is indeed collective access to this account, it may be a huge problem to backtrack the path an attacker used and prevent it from happening again.
An ideal approach is to have all the corporate data segmented as to limit the possible damage from hacker attacks or malware; to separate access rights for all users, according to their roles in the company; and to avoid using any “master keys” – no shared accounts, and a minimal number of people with access to critical systems and/or data.
Essentially these are the ways to diminish the attack surface, thus reducing the risks that are very high on their own.
