Misconfigurations are unfortunately a very common but completely avoidable source of breaches and attacks. They’re what we think about as the “low hanging fruit,” the first place hackers will look to get into your system.
Here are five of the most common breaches we see, and the policies and practices to prevent them in order to protect your system and stop security drift.
Keeping the default credentials on a device like a printer or router is one of the most common and riskiest misconfigurations that we see in even the most sophisticated enterprises.
You purchase a new printer and it comes with a preset username “admin” and password “12345.” That login information is publicly available, but most people don’t even think to change it. They just focus on getting the printer up and running. If I’m a hacker, I can guess or know that the company is using a EPSON printer and try to log into that in order to get in the whole system.
We think of this issue as a “non configuration” — appropriate configuration was never completed because nobody even thought about it.
The Fix: As soon as you power up a new device, be it a printer or router or other tool, you must change the admin credentials. Change the password and if possible, the login as well. Organizations should make this step part of their policy and workflow for deploying new devices in the business environment.
Policies driven by user convenience as opposed to security best practices are a huge risk.
Enterprises keep their password policies weak for a reason that might be surprising: the convenience of senior leaders and management. Folks don’t want to remember 12 characters, they just want an easy password. I’ve seen organizations where managers have a separate password policy from the rest of the organization, maybe as few as five characters required.
While it can be annoying for a security leader to receive complaints on long and complex passwords, it’s far less of a problem than a hacker getting into your CEO’s accounts because they had a six character password with no special characters.
The Fix: Your team might not like it, but the solution to this is clear: strict, complex, password policies enforced uniformly across the board. A combination of capitals and lowercase letters, numbers and special characters, at a standard of 14 or more characters in addition to enabling some form of Multi-factor Authentication (MFA) — all of these factor into a safer password that’s harder for a would-be attacker to crack. This is the requirement of all leading compliance policies, whether that’s the DISA-STIGs for government or the CIS Benchmarks. Sicura can assess and fix servers that are out of compliance with password and other security policies.
Many organizations don’t properly implement role-based access control (RBAC) to manage who can access what data. Individuals and teams have access to data they don’t need and shouldn’t have, increasing the risk of an external breach or internal leak.
You must segregate your data based on real “need-to-know.” For example, the system admins at a healthcare company might need access to manage the servers and applications the company is running — but they don’t need access to the actual patient’s personally identifiable information (PII) stored or managed in databases on those systems.
Still other organizations will accidentally leave data open to public access. We see examples of this misconfiguration in the news all the time, with open S-3 buckets and other backdoor access for hackers to data that shouldn’t be accessible.
The Fix: Like the previous issues, the solution to lax data access rules starts with developing and enforcing a policy. An overarching policy that categorizes and specifies types of data and details requirements for access to each of those categories is critical. Establish a policy with an emphasis on least privilege which promotes categorizing data types and access control. Once you’ve established a policy, use automation (script or tool) to monitor open shares or detect when unauthorized users are attempting to access systems and / or datastores.
Open ports are another example of what happens when you prioritize speed and efficiency over security and compliance. Developers are focused on enabling functionality and system admins are taught to get things up and running, usually on a deadline. Often that means going back and locking down your applications and packages after they’re shipped.
When teams set up a system, they tend to focus on the specific app or product they’re working on, without considering and even noticing what else is happening on that server. They may configure a webapp to use port 8443 which is secure for my web app, however, by default port 80 or 8080 is left open which is insecure.
Open ports can be an attack vector for allowing a malicious user system and data access. When I worked in offensive security, I saw applications that would open 3 or 4 ports by default but the app only required 2 to be functional, and the team was afraid to close those 2 because they didn’t want to accidentally break something.
The Fix: Implement a policy that all ports are closed as soon as a host is stood up, and then engineers can open whichever ones they specifically need to use. Get your team in the habit of tracking which ports are open and in use, which are open and not needed, and closing them. Periodically scan for open ports and services to see which ports are open — this is what a hacker on the outside will try to do. Many organizations try to solve this by masking open ports with a firewall, but that’s just hiding the problem.
The operating system is the very base of all systems and infrastructure, and yet organizations still fail to lock down their OS. The basic configuration of physical and cloud servers is the first step in efficiently locking down your entire system.
Even if a server was 100% secure when it was spun up, the impact of human error and time means it’s probably not going to stay that secure. Policies change, people make mistakes, and you’re left with a server that has drifted away from a secure state. This is even more true with legacy systems that haven’t been modernized, often because they’re running critical infrastructure that you can’t afford to take down. Technical compliance policies like the CIS Benchmarks detail the requirements for modern and legacy hosts alike — but organizations have to dedicate time to enforcing and remediating them.
The Fix: At Sicura, we're shifting security all the way to the left: beyond the application level, the code level, to the operating system, instead of waiting until the end of a deployment process to worry about security.
When you try to implement security later on in the pipeline, the train has already left the station. Maybe the brakes are broken, or the engine needs repair. You’re now chasing the train to try to catch it and fix it while it’s moving. But when you start at the OS level with secure configurations, that’s like checking the train before the wheels start turning, improving safety and efficiency.
Reach out to Sicura today for an assessment to reveal misconfigurations on your system and a path for fixing them.
Ready to maintain secure and compliant infrastructure focused on cost, automation, and consistency?