Security Think Tank: To follow a path, you need a good map

How do IT security teams tackle the challenges posed by the increasing use of third-party platforms and services? These changes to the way a company’s IT infrastructure is provisioned gives malicious actors a much larger attack surface to play with and, once access has been gained, a broader range of opportunities to move through a target company’s IT infrastructure. 

With the assumption that the security team has a solid understanding of the organisation’s business and its internal and external processes, a good starting point would be to map out all the processes and sub-processes – IT, paper and other. 

The aim of this mapping is to identify the various boundaries between applications and services, including where third parties themselves use third-party services. In so doing, you should be able to identify what type of control you should have over the individual services and the interconnecting boundary between services.

By being able to identify these controls, or lack thereof, coupled with business knowledge of what is at stake should a control fail (or not be present), leads to the development of a risk landscape and, from that, a risk management strategy. Note that this is, at this stage, a paper-only exercise.

The first step is to identify what is under the direct control of the organisation – for example, on-site IT infrastructure and equipment such as PCs, laptops or mobile phones used by staff that are provisioned and maintained in-house and subject to the organisation’s security policies, procedures and standards.

The second step is to identify those infrastructure areas and service provisions where there is a reliance on a third party to provide, support and maintain – for example, there is reliance on the third party’s own security policies, procedures and standards.

The third step is to identify those areas which are essential to operating the organisation’s infrastructure, services and operations but where there is no organisational control over security of those services – for example, the use of the internet or other third-party networks. 

Once these areas have been identified, documented, risk assessed and the risks prioritised, the task of evaluating what controls are in place and their effectiveness can commence. The difference between what ‘should’ be in place and what ‘is’ in place, together with the risk priority, will lead to a corrective action plan.

What follows is my take of what controls I would typically be looking for. It is not exhaustive, and I have not gone into heavy details – there are many sources of helpful information, be it books, courses or internet searches.  

Looking at step three first, where you have no control. The security measures you can take broadly fall into three areas:

1. Encrypt data in transit – for example, point-to-point encryption between systems and services, evoke opportunistic encryption on email servers, encrypt email content at the end devices.
2. Control data egress such that only non-sensitive data is made available.
3. Control data ingress – for example, ensure that all interfaces are patched up to date and subjected to regular IT health checks to ensure that there are no detectable vulnerabilities. Ensure that email systems and associated internet domain settings are fully compliant with SPF, DMARK and DKIM protocols.

For the second step, where reliance is placed on third parties to be secure to a level acceptable to the organisation, the main control is the service contract.

This should not only spell out the organisation’s security requirements, but also how they should be qualified. Simply stating that the service being acquired is certified to a formal standard such as ISO 27001 is insufficient. The contract should identify the areas the certification should cover (ISO 27001 Statement of Applicability, for example), must be inclusive of all areas that are part of, or influence, the service being provided, and must be able to provide formal evidence of certification currency.

Other areas not being covered by the third party’s formal certifications could include staff hiring and discipline processes, internal audits and the procurement of services pursuant to the provision of services to the organisation. These areas should be contractual statements.

The first step, of course, is looking at and evaluating internal organisational policies, procedures and standards – for example, staff vetting. Is a prospective hire’s CV vetted and more than one reference taken up? Are any security policies and supporting procedures and standards up to date and are they followed? Is sufficient staff training and education in place? Are the IT and IT security departments properly resourced? Are regular IT health checks carried out on the internal infrastructure as well as the external-facing interfaces? Are contractors subject to follow the organisation’s polies and procedures? Has the organisation’s IT been subject to formal certification, for example ISO 27001, Cyber Essentials, and so on? Are other ISO standards being followed, such as ISO 27004 (monitoring measurement and analysis), ISO 27005 (Information Security Risk Management) and ISO 27033 (Network security)?

This should all be second nature to the seasoned IT security specialist.