The MOVEit Vulnerability, And Why Automating Server Deployment Makes Sense

In 2023 there was a major cybersecurity breach that affected a popular software by Progress, it was their Managed File Transfer Software software called MOVEit. Thousands of users worldwide were affected, who did not apply the security patch on time. These were organizations in finance, healthcare, and government. You may read more about this breach known as CVE-2023-34362.

Many persons assume that cybersecurity breaches are always sophisticated zero-day exploits, but if you notice from the many reported breaches, most tend to be related to something that was not done, or was done incorrectly, as in not following recommended policies or best practices such as applying security patches.

Most cybersecurity breaches can be prevented. According to recent research, 88% of security incidents are linked to mistakes by someone, not software flaws. The security fix exists, hardening guidelines, and best practices are available. But often, with the managing of multiple servers, daily operations, and coordinating required patching, things can get missed, or applied to some servers with others missed. Or someone hardening servers one way while someone does it another way, or when one IT professional no longer works with an organization certain steps are not following by the new person.

The Problem Isn't The Technology, But How it is Deployed

The MOVEit breach is one of many examples we can see where missing critical steps can later have serious implications in future. Whether it's failing to apply a security patch on time, or deploying a new server without checklisted harden approach, or skipping security steps under deadline pressure, the root cause remains the same. We rely too much on human memory and talent, manual checklists, and hoping that whoever is responsible for cybersecurity like the security analyst, can tell us what was missed in hardening the system.

Consider the following, you have a new server needs to deploy, and you are pressured to complete this ASAP. You sets up the basics, the OS, the network configuration, gets the application running, and the server goes into production. Security hardening is usually seen as a separate task that happens afterwards, if there's time, if it's remembered, if the person who knows the complete hardening checklist is still working there. And as for security patches and updates? Those get applied when someone notices the alert, when it rises high enough in the priority queue, or when there's a maintenance window scheduled.

Misconfigurations account for 23% of all cloud security incidents, and these breaches cost an average of $4.35 million to remediate. We have publications by NSA and CISA that speak about misconfiguration as being a common occurrence in breaches, "Top 10 Cybersecurity Misconfigurations" reports actual breaches that have been investigated, and every one could have been avoided through proper server deployment.

The majority of breaches aren't happening because attackers found some ingenious way around advanced security systems. They're happening because someone forgot to disable password authentication on SSH, or didn't apply a critical update, or left default credentials in place, or never set up proper firewall rules. These are basic steps that every system administrator knows should be done, but in the rush of daily operations, they get missed or because of not being knowlegeable about cybersecurity frameworks like CIS and ISO 27001, or NIST guidelines.

And here's an organizational problem that would make this even worse. Let's say you have a senior system administrator who's been working for your organization for many years who naturally would have developed from their experience or formal training a mental checklist or even scripts on how to effectively harden a server. Then one day that person leaves your organization. Suddenly, all that knowledge and best practice also leaves and the next person ends up restarting the process from building up their experience and even if they follow best practices there is still the challenge of manual procedures not being done due to pressure to complete deployments on time.

Or maybe you have a team of system administrators, all competent, all experienced, but each one sets up servers slightly differently based on their own preferences and experiences. One admin religiously configures AppArmor for mandatory access control. Another prefers different firewall rules. A third has their own approach to SSH hardening. The result is that your organization's security posture varies from server to server depending on who happened to deploy it, and no one can really say with confidence exactly which security controls are applied across your entire infrastructure.

Hardening Should Not Be An Afterthought

I've always believed that hardening shouldn't be an after thought, something that you do after a server is already deployed to production. Security should be a part of your deployment process, built into the foundation just like installing the operating system or configuring the network. And I don't think security should be exclusively the cybersecurity team's responsibility either. Yes, we should identify vulnerabilities and establish best practices and compliance requirements, but system administrators need to take that information and build it directly into their workflow and deployment procedures as well, so that security just happens automatically as part of setting up any server.

Recently, with a lot happening with my personal projects and not enough time, I realized that even my own careful manual approach had vulnerabilities, mostly with limited time and the temptation to do some tasks later which may be forgotten.

So I took the time to identify the best practices in hardening servers and applied that to the building of an automated deployment system, not only because I wanted to save time, but because I wanted to make sure that security hardening was done consistently. I wanted to make sure I identified all the important hardening procedures and best practices I have learned from experience and researched from documented frameworks and policies, and translate them into code that would execute the same way every time.

The system I built follows established cybersecurity frameworks like CIS Benchmarks, and NIST guidelines, along with standards from frameworks like ISO 27001. These aren't arbitrary security measures I made up, they're industry recognized controls that map to specific compliance requirements. The automation handles everything from SSH hardening and firewall configuration to intrusion prevention, kernel hardening, file integrity monitoring, and automatic security updates. A fresh Ubuntu server goes from installation to fully hardened, production ready infrastructure in minutes instead of hours.

But the real innovation isn't the technical implementation. It's what this approach solves organizationally.

Solving the Knowledge Problem

When hardening procedures are automated and tracked, several organizational problems disappear almost immediately.

First, there's no more tribal knowledge problem. Every security control, every hardening step, every configuration setting is documented in code. It's version controlled. It's auditable. When a new administrator joins a team, they don't need to only rely on learning a checklist or put together security procedures from different documentation. They just need to run the deployment automation, and the server inherits the complete security baseline that the organization has established. For clarification I am not suggesting they not learn and understand compliance but the hardening of servers should not only depend on this.

Second, consistency becomes guaranteed rather than theoretical. It doesn't matter which administrator deploys a server, or what time of day it happens, or whether they're under pressure to get it online quickly. Every server gets the same security controls applied in the same way. You can actually answer the question "which security controls are applied to each server?" with certainty, because this system tracks which policies have been applied, when they were applied, and what version of each policy is running.

Third, updates and patches stop being something that requires manual monitoring and remembering. This was the core problem in the MOVEit breach, organizations had the security patch available but didn't apply it quickly enough across all affected systems. The system I built includes automated notifications that alert administrators when security updates are available, eliminating the gap between "security patch released" and "security patch applied." There's no more "I didn't know there was a critical patch" excuse, because the system tells you. The whole "I forgot to patch that server" or "I thought someone else was handling it" problem that leads to breaches like MOVEit just goes away.

And finally, new servers don't have that dangerous window where they're live in production but only partially hardened. Security isn't something that happens after deployment. It is deployment. The server doesn't go live without the complete security baseline already in place.

What Benefited Me Can Also Benefit Others

I built this system to meet my needs, and I am realizing the value of this approach especially for companies such as hosting and organizations that deploy servers regularly, whether on premise or in their cloud infrastructure.

Think about a hosting company that provisions hundreds of servers for different clients. Every server needs to meet certain security standards, both for the company's protection and for regulatory compliance. With manual hardening procedures, you're trusting that every technician follows the complete checklist every time, that nothing gets missed during busy periods, that the procedures are documented and updated as new threats emerge. With automated hardening built into deployment, you know with certainty that every server meets your security baseline before it's handed over to a client.

Enterprises who manage their own infrastructure might have servers deployed by different teams in different departments, each having their own level of security expertise. An automated hardening system ensures that even if a development team needs to deploy a new test server, that server still meets the organization's security requirements and that the security outcome remains the same.

The time savings are significant too, going from hours of manual configuration to minutes of automated deployment, and that matters from a business efficiency perspective. But I think the real value is in what you gain in consistency, auditability, and confidence that your security controls are actually implemented, not just documented in a policy manual somewhere.

A Quick Note on Hardened Distributions

Some enterprise Linux distributions offer built-in compliance profiles. For example Rocky Linux includes free profiles, while Ubuntu Pro and RHEL include profiles with their paid subscriptions.

The reality is that many organizations, especially small businesses do not have enterprise subscriptions. And even when free options exist like Rocky Linux, or when organizations do pay for enterprise features, these profiles are just starting points. They help you reach compliance at installation but they don’t keep you there. As systems evolve, updates, new packages, or user changes can slowly undo that compliance unless continuous hardening or monitoring is in place.

My automation approach complements these tools when available, but more importantly, It makes security hardening accessible to everyone and works on any Ubuntu or Debian based system regardless of subscription status.

Looking At The Bigger Picture

A part from my need of speed, after considering how attackers are already using automation in their efforts to scan and identify vulnerabilities like weak SSH credentials and unpatched deployments, I saw the need to take the same approach, using automation as well.

If attackers are automating their search for vulnerabilities, as IT professionals we need to do the same and automate our security too. for both speed, consistency, and sticking to compliance. Not just for efficiency, but to eliminate the human error that causes 88% of security incidents.

The MOVEit breach should never have reached the scale it did. The security patch was available, the guidance was published, the vulnerability was known. But across thousands of organizations, the coordination required to identify affected systems, schedule maintenance windows, apply the patch, and verify it worked everywhere, that manual process took too long. Automation can't prevent zero-day exploits, but it can dramatically shrink the window between "security patch available" and "security patch applied everywhere." And in that window is where most breaches happen.

The same principle applies to initial server hardening, configuration management, and maintaining security baselines. This does not require suffisticated technology or more money. It's how we approach server deploymentment and how we maintain them. The solution isn't to work harder or trying to remember everything perfectly every time. The solution is building an approach and systems that make negligence impossible.

When I deploy a server now, I don't have to wonder if I remembered everything. I don't have to hope that I applied all the critical hardening steps. I don't have to worry that if I leave this job, the next person won't know the complete procedure. And when a critical security patch is released, I don't have to worry about whether it got applied to every affected system or whether something fell through the cracks. The security is just there, built into the deployment process, documented in code, tracked and auditable. The gap between "security patch released" and "security patch applied" shrinks from weeks or days to hours or minutes.

Breaches from negligence are preventable, but preventing them requires changing how we approach server deployment and maintenance. Security can't be the last step, something we do to a server after it's already running or something we get to when we have time. It needs to be the foundation, built in from the beginning, automated to the point where forgetting it isn't even possible.

What My Script Actually Does

Here are some examples of what my automation handles, based on me applying various compliance frameworks base on my scenario. So you will need to make modifications based on your scenario and research or include your cybersecurity analyst in the early stages of identifying the areas of interest.

SSH Hardening (CIS 5.2.x, NIST AC-3, ISO 27001 A.9.4.2): Password authentication gets disabled entirely, replaced with key based authentication. The system validates that the keys work before disabling password access, this prevents accidentally locking myself out. This removes the common SSH brute force attacks from succeeding because someone left password authentication enabled.

Update Management (CIS 1.9, NIST SI-2, ISO 27001 A.12.6.1): A cron job checks for available security updates and sends email notifications immediately. This is exactly what would have helped in the MOVEit situation, reducing the window between security patch released and the admininistrator knows about it. This allows you to move faster and not wait until you happen to read a security bulletin or manual weekly update checks.

File Permissions (CIS 6.1.x, NIST AC-6, ISO 27001 A.9.4.1): Proper least privilege permissions are set automatically. Configuration files get 644 (readable by owner, readable by group, readable by others but no write). Sensitive credential files get 600 (readable and writable only by owner). No more finding critical files set to 777 because someone was troubleshooting and forgot to fix the permissions afterward. These might seem like small details, but attackers specifically scan for overly permissive files. I am also testing how effective and practical it would be to have a cron job that periodically checks these permissions and trigger a report for the overly permissive files and folders.

Firewall Rules (CIS 3.5.x, NIST SC-7, ISO 27001 A.13.1.1): Set default deny policies with explicit allow rules for only necessary services. Automated configuration means every server gets the same baseline protection, not different firewall rules depending on which admininistrator set it up or what they remembered to configure.

System Monitoring (CIS 4.1.x, NIST AU-2, ISO 27001 A.12.4.1): File integrity monitoring, system call auditing, and intrusion detection are configured automatically. These aren't optional extras that get added "if there's time," they're built into the deployment from the start.

The automation doesn't just apply these controls, it tracks which ones are implemented, when they were applied, and what version of each policy is running. So when an auditor asks "which CIS controls are applied to your production servers," you have documentation, not guesswork.

Where Do You Stand?

The biggest vulnerability does not have to be sophisticated, it may just be that you forgot to disable password authentication when rushing, or that file permissions might get set to 777 during troubleshooting or DevOps team testing code and never corrected it, or that a critical security patch notification was missed once and forgotten forever until it is too late. Building these controls into automated deployment eliminate common risks and takes us closer to a hardened server(s).

References and Additional Resources

Security Frameworks and Benchmarks

• CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• DISA Security Technical Implementation Guides (STIGs): https://public.cyber.mil/stigs/
• ISO 27001 Information Security: https://www.iso.org/isoiec-27001-information-security.html

Distribution Security Profiles

• Rocky Linux DISA STIG Guide: https://docs.rockylinux.org/books/disa_stig/
• Ubuntu Pro Security Guide (subscription required): https://ubuntu.com/security/cis
• RHEL 8 Security Hardening (subscription required): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/security_hardening/

Breach Analysis and Reports

• MOVEit Transfer Critical Vulnerability (CVE-2023-34362): https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
• Verizon 2024 Data Breach Investigations Report: https://www.verizon.com/business/resources/reports/dbir/
• NSA/CISA Top 10 Cybersecurity Misconfigurations: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a

Security Automation Tools

• OpenSCAP - Security Compliance Toolkit: https://www.open-scap.org/
• Ansible Security Automation: https://www.ansible.com/use-cases/security
• SCAP Security Guide Project: https://www.open-scap.org/security-policies/scap-security-guide/

Linux Security Best Practices

• Linux Hardening Guide - ANSSI: https://www.ssi.gouv.fr/en/guide/linux-configuration-recommendations/
• Red Hat Security Guides: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/
• SANS Linux Security Checklist: https://www.sans.org/score/checklists/linux/