Well Maintained logging is essential!

All organizations with information systems need to know what’s happening on, and between those systems. This is where a comprehensive logging setup can be very beneficial. It shows you what has happened and when it happened. Make sure we protect these logs from being altered or destroyed, and that admin access to the logs is monitored should also be considerations.. Finally making sure your time is synchronized across your estate ensures you can build an accurate timeline of events when things go wrong.

Security category – 12.4. Logging and monitoring

12.4.1. Event logging.

On any system that processes information we should ensure we have auditing and logging in place. We must also ensure that it cannot be tampered with by the users of that system.

One way to accomplish this goal is to use rsyslog to store logs remotely, away from the clutches of a compromised local system. This control is important for any event that requires investigating and can help us find the cause of problems quickly and accurately. The level of logging should also be tailored to what is useful and what is useful depends on the type of information and purpose of this server. Too high of a logging level will lead to important log entries being overlooked due to the “noise” of excessive logging or even the servers hard disk filling up causing a crash or for older log entries to be overwritten. Too low of a logging level can lead to important event information not being recorded. Reviews of logs should be regularly carried out and logs should be kept according the retention period decided by what your organization deems necessary for investigations.

12.4.2. Protection of log information.

Logs are only as useful as they are accurate. Steps should be taken to ensure users cannot alter log entries, either maliciously or accidently. Enough storage space should be available to reduce the risk of excessive log files being generated to overwrite previous, important, entries. In addition, only authorized staff should be able to view logs. Ways to ensure logs have not been tampered with include storing logs remotely and ensuring integrity is maintained using file hashes.

12.4.3. Administrator and operator logs.

Who watches the watcher? The age-old question can give security teams sleepless nights. The system owners, administrators, often have root or administrator privileges. To protect against abuse any use of these privileges should be recorded and reviewed. Likewise, the audit trail kept should be stored in a way that the administrator cannot tamper with.

12.4.4. Clock synchronization.

As important as logs are they can simply add to the confusion if an organizations logs don’t follow a standardized data/time format and time zone throughout the various time zones the company operates in. While this may not be an issue for organizations based in the one time zone best practice dictates the organization decides on a time zone and format to follow and enforces that on all its assets and logs. This is known as your reference time. In many cases organizations settle on UTC for their reference time

Identity Access Management for ISO27001

If you have been following along with our blog posts on building up our security framework then by now you will have thoroughly vetted your staff prior to them joining and have HR controls in place we now move on to consider their user account and access management. Having a good User Access Management is vital, not just for ISO 27001 but also other security standards such as PCI-DSS and GDPR.

There are 6 controls in all, from the initial account creation right down to preventing privilege creep by auditing user privileges.

Security category – 9.2. User access management

9.2.1. User registration and de-registration.

This control details how our organization onboards new employees and disables the accounts of former employees. The process should be formally documented and procedures in place for the registration and deregistration of accounts. This includes provisioning unique user ID’s for the employee. The registration process should be carried out for any information service that the user needs access to and should include regular audits to ensure user accounts are disabled when a staff member leaves their role. This control is primarily about authentication.

9.2.2. User access provisioning.

While the previous control described the authentication process staff should go through to log into an account to access a server, the level of access the user requires is described here. During the user provisioning process, specific rights and permissions will need to be granted to the employee and these rights should be recorded in a central repository which makes auditing and reviewing them easier. It can reasonably be expected that an employee may change roles one or more times during their time with your organization. During these role changes the level of access and rights the user requires can fluctuate and regular reviews can counter privilege creep; where long serving staff retain access to systems they no longer have a business need to access. With correct access management we can reduce risks and if we specify sanctions for any unauthorized access attempts a staff member might make we will improve our security posture.

9.2.3. Management of privileged access rights.

Privileged access should be strictly controlled as it allows the employee to circumvent security controls. A good example of this is not allowing staff to use root or admin accounts to perform their daily duties, and only using those privileged accounts when there is a specific need. The privileged access usage should be clearly documented including which users can access privileged rights and for which services. Requiring users to authenticate with their unique ID allows us the ability to audit the use of these accounts and to check and protect against abuse of privileged access. The access such be reserved and only used if there is an absolute need. There should also be a documented procedure outlining the authorization process required to gain access to this privilege level.

9.2.4. Management of secret authentication information of users.

One of the biggest risks that is often ignored at companies is how a user’s credentials are provided to them, and managed. An example of poor practice is if a company’s IT department simply emails passwords to users in clear text and with no requirement in place for the user to change their password or keep it secret. Proper password management should ensure credentials are sent to users over a secure medium in a co-ordinated and documented way, with steps taken to ensure that the user changes their password once received and acknowledges receiving it. The user should have to agree to a password policy that describes not only password requirements such as complexity but password management best practises such as not sharing it, or keeping it written on a post-it under your desk.

9.2.5. Review of user’s access rights.

Users roles change over time. What access a user requires now, may not be what they require in 6 months’ time. In many companies long serving employees can move between roles throughout their time with the organization. Having regular audits or reviews of user access rights can ensure that rights a user has retained from a previous role can be removed when no longer needed.

9.2.6. Removal of users of access rights.

When an employee leaves the organization or their contract changes often the level of access the require for different services changes. In this case un-needed access should be removed then and there to prevent permission creep. This also extends to informing relevant staff of the role change to avoid un-intentional disclosure of information.

Defining your Access Control in line with business requirements

Ensuring access to your business assets are controls improves their protection and this can be tailored in accordance to your business needs. Segmenting your network and having different controls for different segments that are guided by organization wide policies can have a great impact in reducing threat vectors and protecting your company.

9.1.1. Access control policy.

Access to assets is a key concern for any organization. Access should always be based on the businesses needs and tailored to the specific employee and asset type. Employees need just the right amount of access to perform at their job. Too little access and key functions in an organization may be left unfulfilled. Too much access and the organization may suffer a data breach, tampering of services and outages, either by accident or by malicious intent. The best way to approach access controls, and is the way recommended by ISO, is documentation! This is a reoccurring theme but we need documented process to ensure repeatability, uniformity, and fairness. In this case we should consult with asset owners on what access levels different users, or user roles, require and document them. It is important to ensure we protect both physical and logical access. Restricted SSH access is only so helpful if the server hardware is physically protected.

Keep in mind when granting rights to users that the user must have both the correct security clearance to access that data and a legitimate business need to require it. By keeping these in mind we can avoid granting excessive access to individuals. Periodic reviews can also help us prevent privilege creep as roles and requirements change.

9.1.2. Access to networks and network services.

This is similar to the above control but where 9.1.1 focuses on access to assets, 9.1.2’s scope is focused on network access. Best practice for access control should expand to the entire network, not just the assets. This policy should specify which networks and services should be accessible with authorization and authentication procedures for access, consideration for workers accessing the network from public areas using VPN or Wi-Fi and monitoring requirements should all be detailed. Consider segmenting your network into separate areas with VLAN’s, DMZ’s or similar to control network access between different areas of your organizations.

Different kinds of information needs different classification levels!

Information is vitally important that we protect for various reasons. From ensuring compliance with legislation like the GDPR in the EU to reducing costs for e-discovery. Knowing what information is stored in our network and where it is stored is vital these days.

Classifying this information with tags and even labels for physical media and ensuring there are procedures in place to instruct the handling of that information helps us understand our environment more to help us protect it.

8.2.1. Classification of information.

Not all data is made equal. Given the high costs in both resource and complexity of more stringent security controls and the unequal value of data it is recommended to take a tiered approach to data management. This simply means dividing data based on some requirement into tiers, with each tier having different security requirements and levels of access. One of the most famous example of this is the United States of America’s federal government’s data classification levels of Top Secret – Secret – Confidential – Unclassified with the criteria for each listed below from Wikipedia (Classified information in the United States, n.d.);

Top Secret shall be applied to information, the unauthorized disclosure of which reasonably could be expected to cause exceptionally grave damage to the national security that the original classification authority is able to identify or describe.
Information is classified Secret when its unauthorized disclosure would cause “serious damage” to national security.
Confidential is defined as information that would “damage” national security if publicly disclosed, again, without the proper authorization.
Unclassified is the default and refers to information that can be released to individuals without a clearance.

Having a well-defined and simple to understand data classification scheme can reduce the effort required when deciding how to secure systems housing the data by giving a baseline of security requirements for that tier.

8.2.2. Labelling of information.

Having developed your classification plan you now need to ensure all data in your organization is designated a classification and is easily identifiable as being given that classification to avoid accidental disclosure or mishandling. An example of this would be to label media used for storing the data with coloured labels, such as RED for top secret, anyone handling the media then knows its classification level at a glance. There should be procedures in place to instruct authors how to correctly classify their outputs. All documents should state their classification level in an easy and quickly understandable way. This labelling effort should be part of your organization’s standard process and documented in your handling procedures.

8.2.3. Handling of assets.

This is very important for organizations dealing with sensitive information. There should be clear, documented procedures for how data is handled at the different tiers including how information is stored and transported and who is authorized to handle it. There should also be instructions on how data and media should be destroyed at the end of its life.

Tracking physical assets; an often forgotten step.

We often put the emphasis on our staff being our most valuable assets and while that is true, we should not ignore our physical assets. Physical hardware needs to be kept track of. There are many cases where organizations, who do not keep an inventory of assets, that have had those assets lost, or stolen, and not known about it for a protracted period of time. Organizations need to ensure all assets have an owner, or custodian, for assets purchased and those assets have an acceptable use policy to prevent abuse. After all nobody wants to find out their data centers are used for bitcoin mining as we have seen happen in the past.

Part of this category also connects with our termination of employees blog post; Ensuring there are procedures in place to recover company assets held by employees.

8.1.1. Inventory of assets.

This control is one that is all too often overlooked. How many companies and organizations have a complete list of all their IT assets and those assets owners? Often our inventories grow too large to be managed without additional resources and then become neglected and out of date. This can lead to security risks of lost assets (unowned) sitting on our network waiting to be compromised, new rogue devices getting added to our network and us being unable to distinguish them from our legitimate assets, even from a patch management perspective knowing what you own is essential for security. Any device that is associated with information or information processing should be recorded. We should keep a record of all these assets including documentation for them, license information and contracts/SLAs (for utilities). There are tools that make this task easier and while it is something that can require a dedicated and substantial effort to develop and maintain, it is something that is one of the more essential building blocks to implementing your ISMS.

8.1.2. Ownership of assets.

All assets in your organization need to how owners assigned to them. This gives us a point of contact should any issues arise that require further investigation or remediation. These asset owners can log in and take care of the regular maintenance of a system, such as hardening and patching. This record of owners should be included in our inventory list described in the previous step. Knowing who to contact can be vital in timely remediation and damage mitigation during a breach when every second counts. Knowing the owner also lets us know who is responsible for protecting those systems, adding/removing them from our inventory and abiding by the asset lifecycle policies, including correct disposal of the hardware and data when that asset is end of life.

8.1.3. Acceptable use of assets.

No user should have complete, unfettered use of company assets. Having the acceptable use of assets documented in an Acceptable Use Policy and then distributing that to all your employees can help you ensure assets and resources are used in a responsible way. Part of this policy is to ensure assets have an appropriate level of security for the data and function it is used for, this means you can have multiple Acceptable Use Policies, one for each classification level of data housed in the various assets. By reducing misuse of assets by employees, making them aware of and having them agree to this policy we reduce risks being introduced by assets being used for non-business purposes.

8.1.4. Return of assets.

If we don’t ensure company owned assets are returned to the company during termination we run the risk of losing control of those assets and, more importantly the data contained within. We also run risks that the assets may be misused or damaged. Human resources and your IT team should liaise prior to termination of employment to ensure any company assets in the control of the leaving staff member are promptly returned to the company. There should also be technical controls in place to ensure that data residing on any personally owned devices of the employee is transferred to the organization.