1

Active defence using an operational technology honeypot

Dr Ian Buffey

Technical Director, Atkins

Dr Richard Piggin

Principal Operational Technology Cyber Security Consultant, Atkins

Authors

2

AbstractThis paper presents research to examine the benefits of deploying a high interaction hardware Operational Technology (OT) or Industrial Control System (ICS) honeypot, as opposed to a virtualised system. The Honeypot Project successfully developed and demonstrated an innovative approach to implementing a situational awareness capability in an operational industrial control system environment.

The approach also contributes to an organisation’s potential forensics capability for ICS systems. Furthermore, this has been achieved via a remote access platform without disrupting operations, whilst preserving vital evidence. The Honeypot project has demonstrated new techniques to enhance monitoring of ICS systems, indicated further benefits and illustrated where such approaches would be suitable.

3

BackgroundIndustrial control systems (ICS) are typically defined as the systems which govern an industrial process, they often include Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS) and Programmable Logic Controllers (PLCs). Industries utilise these systems to monitor and control, energy production, water and electricity distribution, manufacturing, distribution and leisure related systems such as theme park rides. Many of these systems also form an integral part of a country’s Critical National Infrastructure (CNI).

Situational awareness and forensics are challenging to implement due to different operational requirements and reliance on embedded systems. Business processes relying upon ICS or Operational Technology (OT) have high operational demands, often having safety-related functionality and specific system performance criteria. System security and data integrity are essential for reliable operation, with the absolute necessity to operate in real time.

System security and data integrity are essential for reliable operation, with the absolute necessity to operate in real time.

Control system honeypotsResearch has shown OT honeypot developments and their utility, objectives include identification of probable attack methodology, potential targets and systems of interest, to attempt to discover information on the perpetrators, and their intent. The variety of approaches, research and ongoing developments are illustrated with the following examples.

Conpot is a low interactive server side ICS honeypot that emulates a range of common industrial control protocols that could appear as a large facility [1]. Conpot can be accessed via real Human Machine Interfaces (HMIs) or extended with real hardware. Conpot is a development under the long standing HoneyNet Project. An implementation of the Conpot was undertaken by Charlie Scott to represent a building management system, his report provides details of other OT honeypots, the approach and results are presented in [2]. He concluded that a low-interaction honeypot presents a useful method to detect hostile scanning and other activity without necessarily modifying existing network and system configurations.

The research undertaken by Kyle Wilhoit of Trend Micro Incorporated provides an introduction to the subject of SCADA/ICS honeypots and deployments using cloud hosted virtualised systems [3]. His subsequent research discusses further deployments in SCADA and Internet of Things (IoT) petroleum (gasoline) tank monitoring systems (GasPot), again with geographically dispersed cloud instances [4]. The second report on SCADA and ICS honeypots further developed the architecture and attribution methodology using the Browser Exploitation Framework to retrieve information from the attacker’s browser [5]. The common theme of the Trend Micro (TrendLabs) research papers is the ease with which OT systems can be identified using Shodan, Google search engines or similar. The reports highlighted the surprising quantity of OT systems that were unnecessarily connected to the Internet, often with weak security implementations, potentially exposing systems to variety of nefarious acts, ranging from pranks, reconnaissance, extortion, or even sabotage [4].

4

The SCADA HoneyNet project led by Venkat Pothamsetty and Matthew Franz of Cisco has sought to investigate the feasibility of creating a software-based framework to simulate a variety of industrial networks such as SCADA, DCS, and PLC architectures [6]. The aim is to have a single Linux host simulate multiple industrial devices and networks. The objective is to provide tools and to simulate a range of industrial networks and devices, to build a HoneyNet for attackers, to gather data on attacker trends and tools; provide a scriptable industrial protocol simulators to test a real protocol implementation; and to research potential countermeasures, such as device hardening, stack obfuscation, reducing application information, access controls and the effectiveness of network access controls.

From the device perspective, the aim is to simulate the:

› TCP/IP stack of an Ethernet-based device for network OS scanning;

› Industrial protocols for device interaction;

› Device applications, including web servers, management applications such as SNMP and Telnet;

› Hardware emulation of serial devices and/or the serial communication protocol.

The SCADA HoneyNet Project intent is to develop network device entry points including:

› An Internet connected router, as control system networks are typically not directly connected a control network;

› A direct serial device that can support connections and behaves like an industrial device or is connected to one;

› An Ethernet enabled industrial device directly connected to the Internet; or an Ethernet serial gateway directly plugged into the Internet;

› An Ethernet serial gateway acting as a bridge between the IP network and the serial interface;

› Industrial wireless, as an entry points into an industrial network;

› Remote desktop access and HMIs and the software that communicates with industrial devices that usually run on Windows Operating Systems:

› Remote Access Server (RAS)

The project is also seeking to obtain information in order to produce signatures for commercial and Open Source IDS products (Cisco acquired Sourcefire in July 2013) [7].

5

Reporting and appreciation of OT riskRecent publications by the U.S. Department of Homeland Security and numerous other industry entities report significant increases in the number of cyber-attacks against industrial control systems (Figure 1) [8]. This information was consolidated to provide OT cyber security trend indicators by the author [9]. Several reports highlight the increasing sophistication of attacks, and also the likelihood that they will be physically destructive and cause significant loss, as demonstrated by the destruction of a German blast furnace [10]. The research was prompted by this increasing threat background, along with the low reporting and awareness of OT security incidents and, some organisation’s apparent reluctance to address OT security as portrayed by the Ponemon report [11], and by the author [12].

Several reports highlight the increasing sophistication of attacks, and also the likelihood that they will be physically destructive and cause significant loss.

Board members often find it difficult to appreciate the immediacy and magnitude of security risks to their ICS and the relevancy of the concerns raised by their in-house security team regarding the plant or process operations, despite management familiarity with the risks facing their day to day enterprise IT. It can be problematic to articulate the risks to board members when competing against other more tangible plant or operational projects.

Figure 1. Incidents reported to US ICS-CERTSource: DHS (2013, 2016)

350

2010

204

39

138

256232

303

2011 2012 2013 2014 2015

300

250

200

150

100

50

0

6

Given our experience conducting Open Source Intelligence assessments, it is often apparent that the impact of an intrusion may not be fully understood. Coupled with the absence of local, industry or ICS specific threat intelligence, these risks can appear distant and unqualified.

The appreciation of the threats to Operational Technology (OT) are often lacking, largely due to unsurprising reticence to report incidents, acknowledged by ICS-CERT [12] and share information internally or externally [13]. Exposing a suitable system to attack can provide evidence of current threats and vulnerabilities to OT systems, whilst providing an organisational or sector specific context, and could be used to raise awareness, and provide other benefits,

Honeypot utility in active defenceThe use of honeypots is increasing as they move from the domain of security researchers to the deployment of ‘production honeypots’ by asset operators seeking to strengthen their security regime through the adoption of additional countermeasures, as the previous examples illustrate. High interaction honeypots have enabled a greater ability to observe the actions of attackers and hence learn more about their tactics, techniques and procedures (TTP), and have often identified vulnerabilities in the systems under attack. A well designed and deployed honeypot can:

Depending upon how closely a honeypot implementation represents production systems, our research demonstrates that an OT honeypot featuring hardware can also be used for other important functions, including:

› Developing and planning incident response and control system restoration;

› Patch management, testing and systems validation;

› Testing of OT system hardening implementation;

› Security appliance experimentation;

› Impact assessment of security measures on OT systems;

› Device security assessment/vulnerability scanning;

› ICS network security assessment;

› Security testing of ICS perimeter (penetration test).

The ability to perform cyber security assessments using representative systems/components in a honeypot, may limit the necessity or requirement to undertake security testing on production systems. Such testing is treated with utmost caution on OT systems by engineers, due to the potential risk to physical production systems and safety. Specific guidance has been jointly published by the UK Centre for the Protection of National Infrastructure and US Department of Homeland Security [14].

Highlight risk to senior management

of the scale and seriousness

of the threat

Inform impact assessments, based

on the attackers observed activities and

capabilities

Direct forensic investigation

capabilities and incident remediation

planning

Provide specific organisational threat

intelligence

Bolster defence as decoy systems

Cross-functional design, operational & incident

response training

7

An engineering approach to honeypot designVirtualised systems or virtualised machine environments (VMEs) can be intentionally detected by malware and potential adversaries. The techniques are publicised and are not difficult to implement [15]. Although their use might have less utility as legitimate systems increasingly utilise VMEs for resilience and economic reasons. Analogies to the red pill and blue pill scene in the film the Matrix, have been made to distinguish the presence in the Matrix or reality and the ‘red pill’ program code used to detect VMEs [16].

Control system honeypots have been widely deployed as virtualised systems, which tend to have a low level of fidelity. We sought to remedy this problem by utilising actual automation hardware, exposing the hardware interfaces lacking in virtualised systems. Thereby creating a more realistic system from the perspective of an attacker. The research developed a methodology which can be applied to multiple sectors for active defence.

The research intent was to implement and operate an industrial control system honeypot. This was planned, designed and enabled in such a way that it would prove attractive to attackers and afford a significant degree of interaction in order to capture valuable intelligence on those seeking to compromise critical infrastructures. To further consolidate the credibility of the honeypot, we collaborated with infrastructure asset owners who assisted with modelling a credible sub-system that would be of interest to potential attackers.

In the initial stages the project scope was defined to inform the design and ultimately the development and operation of the system. The areas addressed at this stage were the type of system to be modelled, and the situational awareness requirements. These were developed in consultation with process experts, and system engineers. Challenges, risks and potential issues were highlighted, and informed progression of the project with early resolutions and suitable mitigations.

The project identified the requirement to maintain operational security at the outset.

The project identified the requirement to maintain operational security at the outset. Organisations involved in the project needed to remain anonymous, while the system itself needed to be non-attributable to any particular industry sectors, asset owner or systems integrators. Mitigating steps were taken in order that geographical data could not be extrapolated and used to determine the location and identity of linked organisations. The control systems engineering organisation that undertook the target system engineering intentionally appeared to be a small systems integration company, which had inadvertently managed to expose an insecure development system, which was directly connected to the internet.

Methodology overview:

› Facilitate Industry/stakeholder workshop to define industry needs and desired outcomes;

› Methodology report/system specification;

› Control system and process build;

› Data capture and analysis

› Infrastructure design and implementation;

› ICS System deployment;

› Ongoing campaign and analysis;

› Final report and presentation with collated findings.

Honeypot implementation was undertaken in six stages:

1. Industrial sector and control process selection;

2. Construction of the control system. This included the selection of components, PLC programming, HMI and SCADA development, plant process simulation and system modelling;

3. Implementation of security monitoring infrastructure, including selection of software and systems;

4. Integration of control system and security monitoring infrastructure;

5. System testing;

6. Exposure to the Internet.

8

including an active defence capability.

The Situational Awareness and Forensics (SAF) platform was specifically designed to allow forensic investigation while still maintaining, but not compromising functionality. The strategy to use actual automation hardware overcame the inherent fidelity weaknesses of a virtualised ICS platform, whereby, the potential for hardware interaction is largely absent at the level of detail supported by actual equipment, which is a key feature of physical ICS platforms.

The OT honeypot consists of four major components:

1. Control systems and process simulation;

2. Situational Awareness and Forensics (SAF) platform;

3. The attacker’s infrastructure;

4. Remote monitoring infrastructure for the Honeypot.

This was implemented in a standalone environment. The aim being to explore the feasibility of different implementations, whilst making the system attractive, and maintain separation from actual operational systems (Figure 2).

Figure 2. OT Honeypot architecture

Situational Awareness and Forensics (SAF)

Industrial Control System

SIEM

Firewall TAP

SalteddocsTAP

Firewall

Plant PLC

Simulator

Industrialswitch

EngineeringWorkstation

HMI

NetworkMonitoring

and Analysis

Internetvis GSM

Monitoring

KeyRaw networktraffic Attacker

Internetvis GSM

9

Making the honeypot attractive

In order for a honeypot to work effectively, it needed to be attractive to potential malicious actors.

It had to be identifiable with tools commonly used to locate control systems on the internet. Google tools were therefore used to ensure the system appeared in Google searches and were searchable using google search terms known as ‘dorks,’ for the specific internet facing control system components.

The findings indicated that the Shodan (www.shodan.io) search engine used industrial protocols to obtain specific information from automation devices. Normally search engines such as Shodan would identify the processor type from standard HTTP requests. The SAF identified the specific industrial protocol used in the Shodan scanning methodology. This was previously not known, and was not documented on the Shodan website at the time.

To appear enticing, an application was developed that resembled real automated processes using common control system components, and operator interfaces. These were chosen in collaboration with the industry asset owner partners.

ResultsThe majority of the attack traffic was automated reconnaissance scanning, which is often the first stage of an attack. Actual targeted attacks included:

› A successful password attack using vendor default credentials that included attempts to delete directories on the SCADA PC;

› An attempt to execute malicious program code by sending unexpected data;

› Sustained dictionary attacks, where a list of passwords is used to in an attempt to gain access to the ICS;

› A number of unsuccessful SSH brute force attempts

› A knowledgeable and focused attack against the PLC originating from the anonymising TOR network;

› An attempt to disrupt industrial data communications on the PLC.

In our analysis, the USA was the greatest source of connection attempts, followed by China and then the UK. The highest percentage of honeypot connection attempts used predominantly HTTP and to a lesser extent RDP sessions. The recorded source IP address for the traffic did not necessarily locate attackers, due to the use of proxies and VPNs. Some connections were attempted via The Onion Router (TOR) network, which is explicitly used by individuals to hide their location. The use of the TOR network for intentional anonymous internet communications, indicates individuals were taking significant steps to anonymise their malicious activity.

10

Increasing risk awarenessThe OT Honeypot project sought to demonstrate the feasibility and value to an organisational deployment. The results highlight how, in a relatively short timescale, exposed industrial control system are very likely to suffer multiple directed attack attempts. Such attacks, whether knowingly targeted at control systems or otherwise, have the potential to disrupt production systems and result in the possible loss of control, with safety implications. Although this honeypot was designed and deployed with a generic anonymous research orientation, in a very short time it yielded UK ICS incident data, which could illustrate specific threats and business risks to senior managers. The recorded attacks against the control system demonstrated a variety of approaches, differing levels of sophistication and in some cases a working knowledge of actual ICS products and associated vendor documentation.

Should a production honeypot be deployed, senior management could be presented with near real time evidence of the threat the organisation specifically faces on a day to day basis, thus overcoming the issue of low awareness and lack of reporting. The findings may also be shared with others via a secure and anonymising channel such as the UK Centre for the Protection of National Infrastructure (CPNI) and information sharing bodies set up for the purpose, such as Cyber-security Information Sharing Partnership (CiSP), part of CERT-UK (all now integrated in the UK’s National Cyber Security Centre).

Senior management could be presented with near real time evidence of the threat the organisation specifically faces on a day to day basis.

Threat intelligence affords informed controlsIt has been demonstrated in a relatively short time period that an Internet exposed industrial control system honeypot, equipped with a continuous security monitoring and forensic recording capability, can serve to gather valuable threat intelligence regarding attack perpetrators. It also showed which systems appeared to be most attractive, revealed attack methodologies, and indicated attack purpose. A greater understanding of an attacker’s capability and targeting can inform an asset operator’s security controls, enabling vulnerabilities to be identified and organisational resources to be better allocated, creating a more robust and proportional defence. Used more widely, such information could also be utilised to inform industry of particular threats, whilst informing best practice in the longer term.

Collaborative learningAn unplanned benefit of the ICS Honeypot was its use as an educational tool. It proved to be an excellent means to educate both control systems engineers and IT/security professionals, providing insights to the issues facing both communities. Control systems engineers were exposed to new threats and security monitoring and forensic technologies and methodologies. The IT security professionals developed an awareness of controls systems and learnt how to amend their practices to better protect the Operational Technology environment, whilst appreciating the differing technological and operational requirements.

Proven ICS hardware honeypot architectureThe project provided a high level generic architectural blueprint for implementing their ICS honeypots and an accompanying security monitoring platform. Although this approach requires more resources than an IT domain based virtualised system, its credibility to deceive attackers leads to a higher level of interaction, which increases the probability of obtaining more valuable threat intelligence.

11

Achieving situational awarenessThe honeypot attacks demonstrated the requirement for good situational awareness to detect potentially malicious activity, the threat of which was quickly realised. Timely forensics are critical to understanding how an attack occurred, the implications for the system and what can be done to prevent similar occurrences. The ability of the honeypot SAF platform to achieve this was clearly demonstrated across a variety of attack techniques, illustrating the threat intelligence that can be gained within an ICS environment despite the known constraints. Although the SAF capability was deployed to monitor the honeypot, it also illustrates an approach to implementing a non-intrusive continuous security monitoring regime in an ICS production environment.

Further work has since refined the implementation for more widespread applicability. A high-end approach for timely network traffic capture and storage was used, which provided contingency capacity for the research environment, which would not be required for operation application.

Demonstrated ICS forensic capabilityOn most ICS systems following an incident, the understandable priority is to maintain operation, or restart. In which case, the initial malware or system compromise may still be present. This research demonstrated a security monitoring solution that enables the control system to be returned to normal operation, whilst retaining the full network capture and other event information. In turn, this permits an off-line forensic investigation after the event.

Considerations and challengesThe project has sought to demonstrate the benefits and capabilities of the SAF platform in extracting maximum value from the honeypot, and illustrating the worth similar monitoring may have if deployed in a live operational ICS environment. However, such technology is not commonly deployed in control system environments. In large OT systems, the data storage requirements over an extended period are likely to be prohibitive. Asset operators would need to prioritise which data to be retained for an extended period (e.g. external network traffic and selective event logging).

Control system networks are more likely to be designed without monitoring as a requirement, and may often lack appropriate locations or infrastructure to capture traffic. Ideal locations include network communication choke points, such as area/zone boundaries or external connections. The network infrastructure used in OT networks does not usually support the functionality required for traffic capture. Many industrial switches for instance only support limited port mirroring, and lack the capability to provide accurate traffic capture. Where suitable locations for probe deployment or switches with aggregated port spanning exist, they may be physically remote and involve the installation of separate cables to the collection point which may be prohibitively expensive.

Capturing and recording network traffic and event data alone does not make a secure system.

12

The traffic and event data needs to be fed into a Security Event Manager (SEM) or Security Information and Event Management (SIEM) system so that correlation and analysis can take place. The SIEM needs to be suitably configured and monitored by trained individuals, often in the form of a dedicated Security Operations Centre (SOC) or similar. Deploying and maintaining a SOC solution could cost in excess of the systems which are being monitored, consequently organisations with a mature corporate IT security regime may incorporate OT security requirements into the corporate SIEM SOC to oversee the output of any ICS environment monitoring.

An alternative in organisations with a mature corporate IT security regime is for the corporate SIEM SOC to oversee the output of any ICS environment monitoring. This has the additional value of a single entity within the organisation having an overall view of the company’s cyber assets and operations. Conversely, some company’s may not want to have such a wide view available as they feel it may compromise security.

This approach using the same technology is unlikely to be deployed by companies with an immature ICS security programme; however, as maturity increases it can become increasingly valuable. The approach may also be used to provide an assessment of network activity over a short period or the potential intervention given suspected malicious activity.

These interventions would need to address potential impact to the control system in a production environment.

Further workA limitation of the research was the relatively short duration of the OT Honeypot operation. Extended operation would enable the collection of more numerous and richer results, demonstrated by the attacks in the closing stages of the project. There is the potential to model different industrial sectors, vendor equipment, technologies, applications and improve the quality of the process simulation. The existing system could also be utilised to assess security appliances, both for practical implementation and usability. The creation of a suitable scenario to provide open source intelligence (OSINT) in support of the honeypot instance would significantly enhance its attractiveness and potentially lead to increased traffic, particularly from more sophisticated adversaries.

In some cases the attackers clearly demonstrated an in-depth knowledge of ICS.

13 13

ConclusionsThe research successfully developed an ICS honeypot methodology utilising components common to actual control systems currently in operational use. Using physical hardware, rather than relying solely on a virtualised systems afforded a higher level of fidelity. The methodology can be applied to a various iterations in order to represent different industrial sectors, control systems and applications.

The honeypot was successful in highlighting the threats to ICS. These attacks clearly ranged in degree of sophistication. In some cases the attackers clearly demonstrated an in-depth knowledge of ICS. The research also highlighted a number of additional uses, including previously unknown security concerns.

Attacks on ICS systems will grow exponentially, with greater access to tools that reduce the technical knowledge required to operate. Given easily accessible information and the low cost of ICS starter kits, sophistication and methodology of future attacks will develop over time. A honeypot can indicate potential malicious intent and methodologies, providing a basis with which to strengthen the security posture of an organisation.

Future OT Honeypot deployments can be used to in isolation or in combination with virtualised environments to represent appropriate IT and ICS assets, and to ascertain potential nefarious intent, whilst diverting attention from actual operational systems.

Richard is a security consultant at Atkins. He has an Engineering Doctorate in industrial networking from the University of Warwick and has since focused on networking, technology evangelism, international standards, safety and security. He is a member of the IEC standards working group bridging safety and security. Richard also chairs the IET Cyber Security Technical Professional Network, a thriving community that enjoys membership from across all of the Institution’s sectors.

At Atkins, Richard is working with clients to make their Operational Technology resilient against current and emerging threats.

Ian has worked with Industrial Control Systems (SCADA and DCS) for over 25 years, specializing in security since 2004 with a record of successful delivery on complex systems controlling the Critical National Infrastructure in a variety of countries worldwide. He combines deep technical knowledge with an ability to manage cross functional teams and communicate concepts and value to audiences with a wide range of skills and backgrounds.

Dr Richard Piggin Principal Operational Technology Cyber Security Consultant

Richard.Piggin@atkinsglobal.com

Dr Ian Buffey Technical Director

Ian.Buffey@atkinsglobal.com

Authors

14

This whitepaper was originally

created for the E&T Cyber Security Hub

References[1] L. Rist, J. Vestergaard, D. Haslinger and A. Pasquale, “Honeypot, CONPOT ICS/SCADA,” [Online]. Available: http://conpot.org/. [Accessed 22 August 2016].

[2] C. Scott, “Designing and Implementing a Honeypot for a SCADA,” 2014. [Online]. Available: https://www.sans.org/reading- room/whitepapers/detection/designing-implementing- honeypot-scada-network-35252. [Accessed 19 August 2016].

[3] K. Wlimot, “Who’s Really Attacking Your ICS Equipment?,” Trend Micro Incorporated, 2013.

[4] K. Wilhoit and S. Hilt, “The GasPot Experiment: Unexamined Perils in Using Gas-Tank-Monitoring Systems,” Trend Micro Incorporated, 2015.

[5] K. Wilhoit, “The SCADA That Didn’t Cry Wolf: Who’s Really Attacking Your ICS Equipment? (Part 2),” Trend Micro Incorporated, 2013.

[6] V. Pothamsetty and M. Franz, “SCADA HoneyNet Project: Building Honeypots for Industrial Networks,” Cisco Systems, Inc., [Online]. Available: http://scadahoneynet.sourceforge.net/. [Accessed 21 August 2016].

[7] Cisco, “Cisco completes acquisition of Sourcefire,” [Online]. Available: http://www.cisco.com/c/en/us/about/corporate-strategy- office/acquisitions/sourcefire.html. [Accessed 21 August 2016].

[8] ICS Cyber Emergency Response Team, “Year in Review FY 2012,” US Department of Homeland Security, 2013.

[9] R. Piggin, “Cyber security trends: What should keep CEOs awake at night,” International Journal of Critical Infrastructure Protection, vol. 13, p. 36–38, 2016.

[10] Federal Office for Information Security, “The IT Security situation in Germany 2014,” 2014.

[11] Ponemon Institute LLC, “Critical Infrastructure: Security Preparedness and Maturity,” Unisys Corporation, 2016.

[12] R. Piggin, “Increasing risk in the fourth industrial revolution,” ITNOW, vol. 58, no. 3, pp. 34-35, 2016.

[13] ICS Cyber Emergency Response Team, “ICS CERT Monitor,” US Department of Homeland Security, September 2014 – February 2015.

[14] ICS Cyber Emergency Response Team, “Year in Review FY 2015,” US Department of Homeland Security, 2016.

[15] CPNI & DHS, “Cyber security assessments of industrial control systems: A good practice guide,” Centre of the Protection of the National Infrastructure and the Department for Homeland Security, 2011.

[16] T. Liston and E. Skoudis, “Thwarting Virtual Machine Detection,” [Online]. Available: http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf. [Accessed 29 August 2016].

[17] L. Wachowski and L. Wachowski, Directors, The Matrix. [Film]. USA: Village Roadshow Pictures, Warner Bros, Silver Pictures, 1999.

15

16

© Atkins Limited except where stated otherwise.