Software security patch management refers to “the process of applying patches to the security vulnerabilities present in the software products and systems deployed in an organisation’s cyber environment”. This involves identifying, acquiring, testing, installing and verifying pat
...
Software security patch management refers to “the process of applying patches to the security vulnerabilities present in the software products and systems deployed in an organisation’s cyber environment”. This involves identifying, acquiring, testing, installing and verifying patches for vulnerabilities, requiring intricate coordination among stakeholders. Less than 50 percent of organisations can quickly patch vulnerable systems to protect against critical threats and zero-day attacks. Attacks on OT systems components have increased, with more than 90 percent of organisations operating within the industry having one or more damaging security events in two years. Within the transportation sector, cybersecurity breaches could pose significant safety risks, emphasising the need for efficient collaboration in patch management.
From the literature review, it can be concluded that very little literature can be found regarding the interactions employees have to carry out (human interactions) to address vulnerabilities within cybersecurity (security patching). Socio-technical challenges have been identified; however, there is a
lack of information about the roles and effects of these challenges, as well as known vulnerabilities and their intake. Furthermore, most cited references neglect human interactions associated with security patching or patch management in their research. It can be seen that these found gaps within the
academic research world are dedicated to security patching in IT, without further research towards security patching within an OT environment. Information about current practices of security patching in OT is lacking, combined with a lack of insights into governance and contributing factors related to human interactions and the complexity of security patching processes, resulting in the main research question: "What lessons can be learned from the current practices, governance and complexity factors within security patching processes in an industrial, operational environment?" An embedded single case study is performed at a logistic service provider in the liquid bulk industry to answer this main research question.
An exploratory research design is used to shape this case study, where the socio-technical system theory of Mumford (2000) is used as a basis for the analytical framework, where three sub-research questions were derived. Three types of research methods were used to gain the data for each sub-research question: SRQ1 direct observations during multiple security patching rounds and internal cybersecurity audit. For SRQ2, internal document analysis of internal documents regarding OT security and three semi-structured interviews with internal expert interviews of the selected case study organisation. For SRQ3, twelve semi-structured interviews with OT suppliers of critical OT systems of the selected case study organisation were organised. The data was analysed via a SWOT analysis (for SRQ1), and reflexive thematic analysis (for SRQ2 and SRQ3) to retrieve final themes as results, where Atlas.ti was used as a qualitative research tool.
In answering the main research question of this research, lessons learned can be drawn from the current state of the selected case study organisation’s security patching processes based on the identified strengths, weaknesses, opportunities, and threats. More lessons can be learned in addressing an organisation’s governance, revealing poor centralised control over OT suppliers, incorporating standards into policies without expertise surrounding these certifications and weak interdepartmental coordination. Governance is also lacking in implemented performance metrics (e.g. missing KPIs), limiting the efficiency of the OT security policy in practice. The last lessons learned are dedicated to five key factors regarding supplier dependency, ignorance of the OT environment, missed certification in the OT landscape, human knowledge remaining necessary, and complexity within the OT domain causing delays in security patching. With underlying contributing factors of this resistance towards security patching by OT suppliers,
misalignment of terminology of security patching, inconsistent patch log processes with many organisational differences between OT suppliers, and lost information due to email traffic surrounding no central point for the documentation of reported problems.
Within the discussion section, a diversion can be seen into the reflection on OT-specific considerations (from an industry perspective), where little information is available about security patching in OT, the enormous impact of patching behaviour by OT experts, and missed governmental guidance within the industrial and operational environment. Secondly, the reflection on the selected case study organisation’s perspective regarding the lack of incorporated KPIs in the SLA addendum and closing with limitations of the research. The knowledge gap of lacking information regarding security patching processes, combined with socio-technical aspects in an industrial operational environment, has been made smaller via this research. It can be concluded that practical insights of lessons learned are identified regarding the knowledge gap, including reasons for delays in implementing security patches and contributing factors of resistance towards security patching within this complex, industrial, operational environment of the specific case study organisation. However, the identified knowledge gap is not yet closed. Therefore, two types of recommendations are given for the industry. Further research is needed regarding security patching in an industrial, operational environment, and four practical recommendations are provided for the selected case study organisation.