The Dangers of Default: Cybersecurity in the Age of Intent-Based Configuration

Technology has recently been evolving at the speed of light. We have seen the onset of increased cyber threats across all industries. Gone are the times when threat actors had a specific goal and target. We now live in an age where robots collect, collate, and save information for a more opportune and profitable day.

It is ever more important to understand the security measures individuals and organisations implement to safeguard themselves against such threats. But a threat overlooked by many is the threat posed by “default.” Well, what is this? It is the process of accepting the preconfigured, predefined settings or states or any system or infrastructure, whether IT, OT, or non-technically related.

The Dangers of Default

When you deploy software, set up a new router, create a new account, or do many other tasks, you are inevitably given a username and password. These are defined as “default” settings. More recently, they have countered the default credentials, which are the same across all routers, by creating new usernames and passwords using an algorithm configuring the routers en masse during the production phase. However, this is still the default because the ability for that algorithm or the process to be compromised means it will inevitably affect your infrastructure and organisation.

The Cybersecurity & Infrastructure Security Agency (CISA) provides context and guidance on why and how to go about ensuring that you do not run afoul on the default factory configuration vulnerabilities.

As an example, a recent attack against some Programmable Logic Controllers (PLCs) demonstrates why default configurations are so dangerous. The attack itself allowed the exploitation of vulnerable PLCs, which are used in the OT space in industries such as food manufacturing, chemical production, and water processing plants. The exploitation of the default password and network ports on the PLCs – and their exposure to the internet – created the perfect opportunity for compromise. These PLCs and related controllers are often exposed to outside internet connectivity due to the remote nature of their intended functionalities. Something as trivial as defacing the controllers’ user interface rendered the PLCs inoperative. With this type of access, deeper device and network-level access were made available, with potentially more profound cyber-physical effects on processes and equipment.

To expand this idea, the default configuration is just as bad as a default password.

This is because the configuration defined on a system depends on a generalised configuration for the majority rather than the minority. This may be very applicable to your organisation, as you may fall into the majority category today, but this could change tomorrow, and you could become a minority. The ability to define specific settings that fit your use case and for your organisation is something I call “intent-based configuration.”  The problem with leaving a default configuration is that these are defined by the vendor, not by you or your organisations. If we take group policy configuration, there are thousands of settings that are configurable, and many of these will be left as the default, as they provide a configuration state which many organisations accept. But the fundamental problem with this is if you as an organisation define the intent of this setting, you are reliant on this setting being the same if there is an update or upgrade. This means that you lose sight of something that is good today and what may not be good for your organisation tomorrow.

For example, in Active Directory, the “Allow log on locally” within the “Default Domain Policy” provides different contexts and applications, depending on the endpoint.

We can see that when applied to Workstations in comparison to Domain Controllers, we have a different set of Users and Groups. Some of the compliance frameworks will ensure that an explicit setting is defined and that the default or “Not Defined” setting is not used in their policies. The other compliance frameworks will provide you with guidelines on “Best Practice” approaches and guide you on what is acceptable. Now, if what they suggest is acceptable and is contained within the “Default” or “Not Defined” category, I would posit that this is not “Intent-based Configuration” unless you explicitly choose a particular configuration.

There are cases when some of these settings are applied, and the setting will continue to persist even if it is no longer defined in the policy that originally applied it. This can be for a few reasons:

• The setting hasn’t been previously defined for the device.
• The setting is for a registry security object.
• The settings are for a file system security object.

How Tripwire Enterprise Can Help

This is where Tripwire Enterprise (TE) can give you in-depth insight into what your environment is configured for. TE gives you the ability to run your machines against the desired compliance standards, but if it does not meet a specified condition, it will be considered a failure. Therefore, the “Default” or “Not Defined” approach will be highlighted as a failure and a point of concern.

Knowing the above, how can we go about ensuring that we avoid the dangers of default? There are multiple ways to achieve this, and this can span from the processes and procedures an organisation takes to ensure that things like default credentials and settings are not implemented, but the method that will assist the most to achieve this is to be able to leverage something like TE to define a compliance policy that negates such issues. This does require an organisation to understand and define what your organisation’s compliance and security needs are and, more importantly, configure the systems with that intent.