Reduce security risk with 3 edge-securing steps

A cybersecurity leader’s role in reducing risk should always be clearly defined, but all too often in our business, it seems we’re not doing enough. Risk is everywhere these days, with attacks seemly coming at our businesses from all angles — ransomware, phishing, social engineering, and an ever-growing host of vulnerabilities that can be exploited.

Limiting the risk posed by these threats and more is a difficult task. It’s only prudent to ensure your firm allocates appropriate resources to monitor and mitigate risk, and that you educate yourself and your team about the latest attack methods and vectors.

But the best anti-risk plans start at the edge — if you aren’t aware of any and all risks to your edge access, you are not reducing risk.

For starters, don’t use outdated or vulnerable virtual private networking software (VPN) or other edge access tools that are easily attacked. It’s critical to have some sort of process in place to identify security issues in your remote access software and to be prepared, if necessary, to make the hard decision to shut down remote access should a vulnerability be identified for which there is no readily available patch.

Ensure you have methods to communicate such hard decisions and ensure that stakeholders understand why you are pulling the fire alarm and limiting access if needed.

Consider getting rid of SSL or web-based VPN

If you don’t have the ability to manage or maintain remote nodes, at least make sure you are moving to some sort of mechanism to manage and maintain this remote access software. If you only have access to an on-premises patching tool such as Windows Software Update services, you may need to invest in cloud solutions such as third-party patching tools or Intune in order to maintain remote assets.

But is patching enough? Over the past several years web-based SSL VPNs have been targeted and used to gain remote access. You may even want to consider evaluating how your firm allows remote access and how often your VPN solution has been attacked or at risk.

The Norwegian National Cyber Security Centre (NCSC) has even gone so far as to recommend replacing SSL VPN or web-based VPN, having long observed and provided alerts about critical vulnerabilities in VPN solutions that use secure socket layer/transport layer security (SSL/TLS), often known as SSLVPN, WebVPN or clientless VPN.

“The severity of the vulnerabilities and the repeated exploitation of this type of vulnerability by actors means that NCSC recommends replacing solutions for secure remote access that use SSL/TLS with more secure alternatives,” the authority says. “The NCSC recommends internet protocol security (IPsec) with internet key exchange (IKEv2). Other countries’ authorities have recommended the same.”

The NCSC goes on to suggest that new zero-day vulnerabilities will be likely uncovered in the SSLVPN product category in the future. “It must be emphasized that solutions that use IPsec with IKEv2 may also have vulnerabilities, but this technology choice results in a smaller attack surface and a lower degree of fault tolerance in the configuration of the solution.”

Remember that redeploying such remote access can also introduce risks to an organization and plan accordingly to limit access to known locations and geographic areas during the process.

Stop storing passwords in places they don’t belong

On a regular basis, we see news releases and headlines that someone has suffered a breach due to improperly storing credentials. In the zeal to ensure that a project is complete, we often fail to secure this information.

When these credentials are shared in a manner in which they are hardcoded or stored in an inappropriate storage platform, all too often attackers will be able to access these credentials and by extension the network.

Pay extra attention to how credentials that need to be accessed are protected from unauthorized access. Ensure that you use best practice processes to secure passwords and ensure that each user has appropriate passwords and access accordingly. GitHub recommends the following:

1. Use a password manager to generate a password of at least 15 characters.
2. Generate a unique password for GitHub. If you use your GitHub password elsewhere and that service is compromised, attackers or other malicious actors could use that information to access your account on GitHub.com.
3. Configure two-factor authentication for your personal account.
4. Optionally, add a passkey to your account to enable a secure, passwordless login.
5. Never share your password, even with a potential collaborator. Each person should use their own personal account on GitHub.

Review who has access to your cloud assets

Recently even Microsoft fell victim to misuse of OAuth credentials. When using cloud services, you need to ensure that only those vendors you trust or that you have thoroughly vetted have access to your cloud services. Always set up Microsoft 365 to ensure that there is some sort of authentication approval process for any third-party application added to your cloud services.

Having a process to regularly review which applications have been approved and if they’re still worthy of being an application in your organization is a must. If you use consultants, discuss what applications have access to their assets and in turn, have access to your assets.

Review Microsoft’s guidance for investigating malicious and compromised applications and perform the steps on your environment now, even before an incident has occurred.

As Microsoft notes, you want to “audit the current privilege level of all identities, users, service principals, and Microsoft Graph Data Connect applications (use the Microsoft Graph Data Connect authorization portal), to understand which identities are highly privileged.”

It simply makes good sense that the privileges of unknown entities and identities that are no longer in use or are not fit for purpose are scrutinized more closely. As Microsoft notes, “identities can often be granted privilege over and above what is required. Defenders should pay attention to apps with app-only permissions as those apps may have over-privileged access.”