The shifting sand nature of software

OS hardening by design

Software facilitates our life in various ways. From writing letters to helping find our way in cities or in the wilderness applications are performing tasks today that we could have only dreamt about yesterday. And tomorrow they will be doing things that we can't even imagine. This is, in part, because software programs are not static. Every day, programmers find new ways of helping us and adapt the software they are responsible for. Software is mutable. The are called software for a reason!

This flexibility comes with a price. Changing a program that works may introduce mistakes. By accident, someone may change a piece of software and introduce vulnerabilities. Or worst, a malevolant actor could replace a perfectly secure application with one that was infected with some malware. All of the previous usually happens without your knowledge. That is because the softwares, and the underlying file system are not immutable.

The mutability of softwre impacts IT and OT organisations in many negative ways.

• Stability of operation is reduced due to the fact that different systems may have different patch level, or, even worst, some of them may have incomptable updates applied to them.
• Security breaches become possible by the introduction of defective software or malware viruses.
• Difficulty of diagnosing issues by not being able to identofy the exact operating condition as it relates to sofware version and path level.
• Reduced traceability since not 2 systems are identical and due to the inherent challenge of managing differences.
• Complex operation solutions required for managing the mutability. Adding tools and methods to manage the chaos should be the last resort!
• Rising certification cost since guess work must be made. Heterogeneity implies more software combinations and longer recertification time and delays.
• System restauration becomes almost impossible due to the lact of traceability and missing information to exactly replicate a failing system.

The list above is not exhaustive and I could on long and long. We can think of backup cost, start-up time and potential reduced hardware cost to name a few reasons to prefer immutable filesystems.

Cost at the Edge

The acuteness of the impact of software mutability is more visible when operating Edge computing ressources at scale. The sheer number of Edge instances makes every inefficiencies cost to quickly add up. Any dollar savec is multiplied by the large numbers of servers and makes a difference. Further, the downtime costs are exacerbated by the difficulty of sending someone on site to perform a repair.

Immutable Operating Systems and their Read-only file systems

Numerous general purpose Operating Sysmtem flavours exist allowing the selection of features and benefits that suit the use case you have in mind. Just to illustrate, this blog, 3 Immutable Operating Systems, lists 3 variants. Another option is to use specialized and purpose built Edge computing OS, which were created with security and ease of use in mind.

How do we do it

Expend on a story here.

To do an upgrade or restoration, an existing read-only filesystem can only be, arguably, removed and replaced by another one. It is not possible to write to it. When the filesystem in question is also the operating root filesystem, which is often the case, the best and easiest approach is to simply shutdown the Operating System (OS) and perform the replacement. NearEDGE's solution at is heart is able to operate outside the realm of the OS and thus enables remote ability to erase and replace a read-only filesystem. Immutable Operating System can then easilly be deployed, or redeployed at will.