Common Security Misconfigurations and Their Consequences

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.

For more information, visit www.cymulate.com^[1]
and register for a Free Trial^[2].