Security in your supply chain matters!

Its often said that you are only as secure as your weakest link. In most cases this weak link is described as your end users. But in more cases an often forgotten risk is the weak link in your supply chain. Third party vendors and providers must be reviewed as part of your security management strategy.

The best example of this is one of the first lessons of a web application penetration tester (or a malicious hacker) is to identify how many websites are being hosted on the same server as their target. Once they have this list they can go through each to identify the site with the weakest security and use that to attempt to gain access to the hosting server.

For other third parties who may have a VPN tunnel established with your corporate network; without adequate consideration and controls put in place to manage this access any compromise of your third parties network also compromises your network. Similarly any of your third parties staff, without appropriate controls in place, could damage your organisation.

The solution is to never assume security when dealing with third parties. Where possible several steps should be taken;

  • Security requirements should be detailed in contracts and compliance monitored.
  • Access to the organisations network should be managed, segmented and monitored to ensure only authorized actions are taking place.
  • Only reputable third parties should be contracted.
  • At a minimum all internal security policies, process, guidelines and standards should be applied to all third parties.

What does ISO27001 say?

Security category – 15.1. Information security in supplier relationships

15.1.1. Information security policy for supplier relationships.

Rules should be in place that govern what a vendor can access and how they should access it, as well as specifying other security requirements. These should require the security a vendor should have on their own network, how incidents should be reported and any other requirements your organization deems necessary, depending on the value of what the vendor will have access to. Having a policy outlining what is expected can help guide us when we are considering vendor relationships.

15.1.2. Addressing security within supplier agreements.

The rules we set out in our Information Security Policy for Supplier Agreements should be included in all contracts with vendors and they should commit to upholding these requirements. Periodic auditing can be considered to ensure compliance.

15.1.3. Information and communication technology supply chain.

It stands to reason that if there is access allowed between your network and your vendors network, then any party with access to your vendors network potentially has access to your organization, such as your vendors suppliers. There should be policies in place to ensure access between you and your vendor is restricted and controls to protect against unauthorized access. Ensuring your organization and your vendor keep an audit and log trail to track access and requests can provide accountability and requiring your vendor to screen their suppliers can also reduce this risk.

Security category – 15.2. Supplier service delivery management

15.2.1. Monitoring and review of supplier services.

This will provide us with the confidence that are suppliers are adhering to the security requirements of their contract. Reviewing the audit trail of a vendor, conducting vulnerability assessments on their network and engaging in regular meetings to ensure the vendor understands their obligations can all prove helpful.

15.2.2. Managing changes to supplier services.

Vendors should not be able to make any ad-hoc changes to their service. This can include patching, upgrades and improvements. Any changes should be managed to limit disruption and ensure service continuity in the event of problems occurring. This also gives us a chance to review our security posture and introduce new controls as required to ensure the changes do not weaken our security position.

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.