Device configurations are one of the most important elements of your organizational security today. Why? For starters, security misconfigurations are one of the most critical threats you’ll face, accounting for 35% of all security incidents.
Security misconfigurations happen when device or service settings—or how they are used—leave endpoints vulnerable to cyber threats. Improper device configurations can include errors, misuse, insecure or imprudent defaults, policies that aren't properly enforced, and unpatched (or unpatchable) vulnerabilities. With the rapid adoption of cloud technologies and increasingly complex IT environments, addressing security misconfigurations is a critical priority in 2024.
Organizations must tackle security misconfigurations with precision. The focus should be on identifying and rectifying specific configuration errors, policy lapses, and vulnerabilities that expose endpoints to threats.
In this blog, we will explore the most common misconfigurations that could be leaving your systems vulnerable and provide practical advice and best practices to help you avoid these frequent but dangerous pitfalls.
Usernames and passwords, together referred to simply as "credentials" are the one of the most common routes attackers take to compromise an organization. In fact, research indicates that over 80% of breaches involve weak, stolen, or reused passwords. The widespread use of default credentials makes them a prime target for cybercriminals. Once attackers gain access, they can exploit these credentials to infiltrate networks, escalate privileges, and compromise critical systems.
Of course the weakest password is no password at all. And you’d be surprised by how often operators leave their devices and systems without any password protection. But even when passwords are put in place, they are often not strong enough. These non-complex passwords consist of recognizable words, a short string of just letters, or a short string of just numbers that can be easily extracted from personal information, intuition, or brute force sequencing.
A default password is by definition reused. These passwords come pre-configured in all the products of a specific vendor, device, or software. These credentials are stand-in, with the expectation that they will be changed by the device owners.
Default credentials, such as preset usernames and passwords on new devices or software, are often neglected, posing significant security risks. Unfortunately, many organizations neglect to change these credentials, opening the door to bad actors.
But it’s not always so obvious when devices are using default credentials. For example, it is not uncommon for devices to be pre-configured with network services that use default passwords. Sometimes these devices can work without network services, but sometimes they can’t. And even when they can, it's important that IT be aware of this potential line of network connectivity. Usually, they are not.
This creates a significant and often unseen point of exposure. Examples of such network services include:
Having a default password in place for any one of your many devices' many network services can make the device and the whole network vulnerable.
A prime example of the dangers of default credentials is the Mirai botnet, a type of malware that exploits IoT devices with default usernames and passwords. Mirai scans the internet for vulnerable devices, taking control of them to form a massive botnet, which has been used in several high-profile Distributed Denial of Service (DDoS) attacks.
One of the most infamous incidents occurred in 2016 when the Mirai botnet was used to take down major websites like Twitter and Netflix by overwhelming their servers with traffic, all due to the exploitation of unchanged default credentials on IoT devices.
The fact is that, over time, default passwords are naturally shared and make their way into the public domain. And it's neither the device manufacturers' fault nor their problem. It's incumbent on operators to be responsible and conscientious.
Better credential management offers maximal impact for minimal effort. In fact, it's the absolute lowest hanging fruit for most organizations intent on shoring up their cyber defenses.To mitigate this risk, it’s imperative that organizations enforce the immediate replacement of default credentials upon deployment.
This should be part of a broader security strategy that includes using strong, unique passwords and implementing multi-factor authentication (MFA) to provide an additional layer of protection against unauthorized access.
A strong (complex) password will consist of a combination of letters (ideally in both upper and lower case), numbers, and symbols. If that string of characters can be random and meaningless, even better.
If you’re using some sort of password manager (even if it’s just a document or post-it note), it's important that usernames and passwords be stored out of public reach and shared only with duly authorized parties. And you should be protective of those credentials at all times, double-checking the legitimacy of any request for you to share or even key in your credentials.
Of course, even with these practices in place, you’ll need to remain vigilant. You’ll need to have some way to monitor your credential storage system and the network as a whole.
If you have reason to suspect either one of being compromised in any way, you will need to change all your passwords immediately. Unauthorized access to your network, or even a single password, can potentially lead to a domino effect that exposes every endpoint and password.
“Patching” makes it sound so easy. You have a vulnerability, you apply a patch. Done. Unfortunately, in the real world, it’s rarely that simple. For starters, 80% of exploits publish faster than CVEs. And, on average, patches are only made available 9 days after the CVE is published. So right out the gate, you’re virtually guaranteed to have a stretch of time when you’re exposed in the wild with no protection.
Bad actors know that. Which is why the first couple of weeks after vulnerabilities are disclosed are the most active in terms of attacks. It’s a perverse sort of foot race – pitting their sprint to land an exploit against yours to patch the system. And the advantage is not on your side.
Of course, even after a patch is made available, implementation can also take some time. In fact, according to research from the Ponemon Institute, it takes an average of 97 days to download, test, and deploy a patch – leaving a wide window of opportunity for adversaries.
Patching can be delayed for a number of reasons, especially in organizations maintaining more sensitive, closed networks. In such cases, the patch is typically subjected to several stages of scanning and sandboxing before it’s applied to connected devices and systems. These organizations will also need to review the patch’s compatibility with operational standards and requirements.
In some cases, it may even require a period of active pen testing. And then there’s always a human error element capable of slowing things down and mucking things up.
All those delays can meaningfully increase the organization’s risk exposure, especially when dealing with a new, high severity vulnerability. Is risk acceptance really the only option in that interim? (Hint: it’s not!)
But the struggle doesn’t stop with delays. In many cases, the security and operability reviews will conclude that the patch is unfit for purpose and not an option.
If for example a patch requires some sort of service-level rollback to a prior version, otherwise downgrades an encryption method, or calls on a protocol forbidden by the organization’s internal policies, the patch may be rejected for safety concerns.
Similarly, if the patch disables a port, protocol, or service that the business uses, it would interfere with core business functionality. This is something we encounter a huge amount of the time. When facing the prospect of guaranteed business disruption today, on the one hand, and the chance of a security risk tomorrow, on the other hand, most decision makers roll the dice and play the odds.
Just as problematic are instances where the vulnerability extends to sensitive devices and systems that require 100% uptime and lack backups. In these cases too, patches aren’t an option.
Further complicating things is the matter of visibility and continuity. An organization may think they’ve resolved their vulnerability exposure and moved on when in actual fact they are still very much vulnerable. This is something that we’ve encountered many times at GYTPOL. After long, expensive projects to eliminate vulnerabilities like Log4J, an organization pilots our solution only to find they’re fielding thousands of still vulnerable devices.
But that’s not even the worst of it. There’s no shortage of vulnerabilities affecting deprecated digital ecosystems, where vendors refuse to issue patches or extend support. In some notable instances, those zombie vulnerabilities – vulnerabilities affecting products after their end-of-life – impact the majority of the market. In those not uncommon situations too, patching is not an option.
With all this in mind, it probably won’t come as any surprise to learn that 60% of all data breaches stem from unpatched vulnerabilities. Thankfully there are faster alternatives to traditional patching.
GYTPOL, for example, uses posture management and hardening practices – usually at the configuration level – to block the attack paths of vulnerabilities. These mitigations are usually made available well before patches and can be implemented with a few quick clicks. They don’t require downtime. And they don’t risk disruption to the wider business. This approach ensures that systems remain protected, even when patches are not immediately available or feasible.
Granting users excessive permissions poses a significant risk to organizational security. When employees or systems have access beyond what's necessary for their role, it creates vulnerabilities that attackers can easily exploit. The more access granted, the larger the attack surface, increasing the chances of data leaks, privilege abuse, or accidental changes to critical systems.
Excessive permissions often arise from a failure to continuously monitor and reassess access controls. Organizations may not regularly review or adjust access when roles evolve, employees transfer, or projects end. As a result, users needlessly retain access to sensitive systems, exposing the organization to added risk. And when it’s a struggle just to identify gratuitous access, you can be sure that there won’t be enough active oversight to identify the abuse of that access.
It’s probably not a surprise then that human error is a big factor in these scenarios. Over 95% of all security incidents (you read that right!) include some element of human error, often in the form of misconfiguring systems, mishandled patch management, or failure to change default passwords. Less common but more sinister is the case of malicious insiders.
In such cases, privilege controls typically serve as your last and best line of defense. Conversely when managers take a generally permissive approach, the destructive force of insider threats can be amplified exponentially.
One real-world example is the February 2022 intellectual property theft at Yahoo. A former research scientist, Qian Sang, used excessive permissions to access and steal valuable source code and strategic information. Despite existing security protocols, the lack of permission oversight allowed Sang to move data from his corporate laptop to personal storage. This case highlights how excessive access can lead to data exfiltration and unauthorized activities.
The solution is rooted in the principle of least privilege — ensuring users only have the minimum access needed to perform their duties. Regular audits, permission reviews, and sophisticated monitoring tools can help prevent oversights and mitigate risks.
Improper device configurations are not just technical oversights; they are gateways to potential disasters. Common mistakes like leaving default credentials unchanged, relying solely and slowly on patches to protect against known CVEs, and allowing excessive permissions can leave your organization dangerously exposed.
In an era where cyber threats evolve at breakneck speed, staying one step ahead can make all the difference. Proactively addressing misconfigurations, taking a layered approach to vulnerability management, and enforcing least privilege access can dramatically reduce the risk of a breach. Remember, security is not a one-time effort — it’s an ongoing process of vigilance, adaptation, and improvement.
Even if your systems are secure today, the threat landscape is always shifting. Regular audits, continuous monitoring, and leveraging advanced tools to manage and rectify configurations are crucial.
In this dynamic environment, the ability to swiftly identify and correct misconfigurations can be the difference between a minor hiccup and a major breach. At the end of the day, keeping your defenses strong requires both strategy and action.