Purpose-built OT Software Trumps Repurposed IT Software

#AwenAsks

For the next 5 weeks, we will be releasing questions on LinkedIn about a whole variety of things including cyber security, software, industry 4.0 and much more. We are tagging it with #AwenAsks, or you can view the questions directly via our Awen Collective LinkedIn company page.

Week Commencing 16th November 2020

In the week commencing the 16th of November 2020 we asked two questions on LinkedIn:

1. Would you be comfortable using repurposed IT tools on your OT / ICS / SCADA / IIoT system?

2. Do people in engineering departments think differently to those in IT departments?

The purpose of asking these two questions was to understand more about how software in both IT and OT worlds are treated.

These were our first two LinkedIn polls, so we were not expecting to receive a large number of responses. Question 1 of this week received 10 votes within 1 week. Question 2 received 11 votes within 1 week. The questions for the following week have already been released, and have received more votes than our first week.

What were the results?

Question 1

With a 0% for yes, and a 50% as no, this indicates to us that people (at least those who we are well connected with) recognise that there are differences between Information Technology (IT) and Operational Technology (OT). As such, our requirements for software which interacts with these systems should be treated differently.

The 40% who voted “Maybe” and 10% that voted “I don’t know” most likely either have particular scenarios in mind (e.g. there may be particular OT devices which are directly controlled by IT software), or are unfamiliar with the differences between IT and OT.

Question 2

The result for “do people in engineering departments think differently to those in IT departments” - posed more as a process-thinking, rather than a belief-thinking question, shows a resounding yes response at 82%. Within this small sample, people do believe that engineers think differently from a process perspective to IT staff.

This most likely hints towards user experience (and also data dashboard) requirements of IT software and software that handles OT, are very much different. The approach to these members of staff should also be different.

Summary and Why are we interested?

In summary it seems that for Operational Technologies (OT), software developed specifically for OT trumps repurposed IT software. This software should not only be built from the ground up for OT, but should be tailored to the specific needs of engineering.

When we started Awen Collective in 2017, we discovered anecdotal evidence of this, and it shaped the way that we developed our software products Profile and Dot. We therefore strongly believe that purpose-built OT software trumps repurposed IT software.

However, while we believe that OT should have OT-specific tools, there is a place for IT involvement in the OT (especially in OT cyber security). The IT world has a lot more experience with, and mature products for, cyber security. So, at Awen we like to speak to people from across an industrial business - OT, IT, Cyber, Risk and the executives - just so that we can get a deeper understanding in how we can best support now and in the future.

If this sounds interesting, then please do feel free to contact us.

Questions released during week of 23rd November 2020

• Does the geographic origin of software matter to you? [Opened 24th November 2020] [Closes 1st December 2020]

• How much do you think politics plays a role in cyber security? [Opened 26th November 2020] [Closes 3rd December 2020]

The results were analysed by Daniel Lewis, CEO & Cofounder of Awen Collective.

Awen Software Engineering Approach

In this blog post our CEO, Daniel Lewis, discusses his experience of software engineering approaches and the direction of the Awen Software Engineering approach.

Agile but Pragmatic

A well known formal definition of the traditional “Waterfall method” (as it has become known today) of project management / software engineering was established by an academic by the name of Winston Royce in 1970 [1]. Royce defined it as a flawed method which is a risky, failure-inviting method. (Note that older and newer definitions are available)

I, personally, have found the waterfall method to be flawed too. When a software project is started, we do not always know all parameters in advance either because the software exists in a complex, ever evolving system, or because implicit/tacit knowledge was not uncovered upfront.

This is why, I believe, some of the earliest descriptions describe the waterfall method as flawed. It just cannot react to the needs of the project/system as it evolves and is discovered internally and externally. I like to see the waterfall method a little like the original game from which Monopoly was derived (known as The Landlord’s Game). This game was specifically developed to show the negative effects of land grabbing on both the economy and on the human psyche - the waterfall method is similar, it was essentially developed to show how the worst of the popular/contemporary ways of working.

With this said, the Agile approach, where projects go through iterations adapting to new information, is not without its faults. The biggest fault that I have seen in agile approaches is that it has become a bit of a soup of buzzwords, where agile project managers tend to run agile projects with as much rigidity as they would with waterfall that the overheads often become too costly to make much benefit.

This is why at Awen we approach software engineering with a pragmatic agile method. A kind of soft agile method. Depending on our clients, we often have to work with a sort of waterfall-like method implemented alongside PRINCE2 or ITIL, but the internal technical work we run our own pragmatic soft agile approach. Do the things which work, don’t do the things which won’t work, minimise overheads and maximise impact. Our approach is always evolving, especially as the business continues to grow, and gaining new people with new experiences.

Security-by-Design

Even though our software engineering project management might seem flexible, there are some things within software engineering which we do not compromise. One such thing we consider as uncompromisable is developing everything that we do with Security-by-Design.

In particular we follow the Cyber Security Design Principles by the NCSC:

1. Make compromise difficult

2. Make disruption difficult

3. Make compromise detection easier

4. Reduce the impact of compromise

These principles are all based on top of various software development testing techniques and cyber security testing techniques that we employ alongside development.

We are also aware that our software is deployed in highly sensitive areas, where equipment is safety-critical (or at least operations-critical). This is why Safety-by-Design is also a consideration in our software development, and is a key component of our innovative Dot product for asset & vulnerability discovery on Operational Technologies (OT).

Conclusion

When Awen software is deployed and used, you can rest assured knowing that the highest levels of pragmatic software development have been employed, everything has been thoroughly tested and the products and services are well thought through with both Security-by-Design and the industry critical Safety-by-Design. Our software can help industrial organisations reach Industry 4.0 and beyond, pragmatically and securely.

1. Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.