Common Security Misconfigurations and Their Consequences

[aum]

Everyone makes mistakes. That one sentence was drummed into me in my very first job in tech, and it has held true since then. In the cybersecurity world, misconfigurations can create exploitable issues that can haunt us later - so let's look at a few common security misconfigurations.

 

The first one is development permissions that don't get changed when something goes live. For example, AWS S3 buckets are often assigned permissive access while development is going on. The issues arise when security reviews aren't carefully performed prior to pushing the code live, no matter if that push is for the initial launch of a platform or for updates.

 

The result is straight-forward; a bucket goes live with the ability for anyone to read and write to and from it. This particular misconfiguration is dangerous; since the application is working and the site is loading for users, there's no visible indication that something is wrong until a threat actor hunting for open buckets stumbles upon it.

 

Careful security reviews of all applications and sites before they get pushed to the live environment - both for initial launch and for update cycles - are critical in catching this type of misconfiguration. Each bucket should be checked to ensure that it has the least viable permissions set on it to allow the platform to work, and nothing more.

 

On the non-cloud side of the house, one of the most common misconfigurations is not enforcing Group Policy, anti-malware, and other centralized management rules and updates. Laptops that rarely ever connect directly to a company network may go for months without getting these critical changes, leaving them undefended as the security landscape changes.

 

One common example is a laptop that has been roaming for an extended period. Such a laptop may not be permitted to receive Active Directory Group Policy updates when it isn't on a VPN or other secured connection, which would lead to its GPO's becoming out of date over time. This means that prohibited actions or operations may be possible on such a laptop, leaving the protected network exposed when that device finally does connect in such a way that it once more has access to protected resources.

 

The fix for this is to ensure that devices with access to organizational resources must accept organizational management changes. Tools like AzureAD and de-centralized anti-malware platforms can allow remote devices to receive updates securely. HTTPS connectivity is generally enough for these tools to push updates and enforce policy changes.

 

Using distributed device management ensures that they are kept in-line with policy, even devices that are only used to access cloud-available resources, like Office365, and do not directly connect to the organization's protected networks regularly.

 

Many such tools - especially things like anti-malware systems - don't even require that the device be managed by Mobile Device Management platforms. This means that even if the device is not otherwise "owned" by the organization, it can still be kept up to date and protected.

 

While we're on the subject of remote workers, there is another misconfiguration that occurs with regularity. VPN systems allow remote workers to access company data safely, but a large number of VPN clients default to an insecure configuration out-of-the-box. Split-tunnel VPN configurations route user traffic over the secure network only when protected systems are being accessed but send all other traffic directly to the Internet.

 

This means that when a user attempts to reach a file server, they do so over the VPN, but a call to Salesforce goes over the unprotected Internet. While this benefits performance, the problem it creates is that a user's device may create a bridge between the outside world and the internal network. With a bit of social engineering, a threat actor can create a persistent connection to the user's device and then leverage that user's VPN tunnel to break into the protected network.

 

The vast majority of VPN clients support single-tunnel configurations. This means that while the VPN is active, all traffic will route through organizational networks - including traffic destined for external sources. It also means that all traffic will also be subject to the same controls as traffic that is originating from users directly connected to the protected networks.

 

While misconfigurations can happen very easily, they pose a clear threat to the organization's security. Taking the time to review security when tools are pushed to live or updated can catch such misconfigurations.

 

Additionally, companies can deploy continuous security validation tools that continuously challenge and asses digital environments in much the same way as a threat actor does to discover misconfigurations rapidly.

 

Combining these two approaches of reviews and continuous security validation adds some complexity to projects but is worth every moment spent on ensuring that things are configured adequately at every step of the way.

 

Source