It was great being a part of the SANS DFIR 2020 Summit and breaking out the lunch-and-learn topic, “Think Like A Threat Actor to Handle Remote Work Risk.” The session seemed to garner a lot of attendance and some great questions. Here’s a recap of the material—a video of the session is right below—, along with some thoughts to questions asked.
Remote work = Added pressure
A tale of two case studies
When we talk about remote work risks, most people think we are talking about the risk of remote workers accessing systems and technology. While part of it is just that, this session instead focused on the steps taken to enable employee access to remote technology and the impact it has on an attack surface. Certainly, we all know the explosion of requirements to allow remote work over the years and in recent months ever more poignantly so. In this scenario, we see IT under pressure to provide access to systems that defy the security architecture designed for that solution. The need for speed adds to that pressure, creating challenges in complying with security processes. Compounding this issue is the fact that IT and Security teams now have to work remotely. This means accessing sensitive control systems and possibly enabling remote management services that are typically turned off or enabled in strict network zones.
Looking at these issues allows us to explore two use cases from two different customers who experienced some of these issues recently.
One organization moved a customer service critical application outside the corporate network to the DMZ due to the need for remote workers to access the platform. The impact it had on the attack surface would have been catastrophic if they did not have automated and continuous attack surface intelligence (ASI). The issues discovered with continuous ASI included:
- exposed credentials
- an exposed sensitive and SQLi vulnerable API
- publicly accessible remote management services
All of these issues are foundational–non-existent when the system was operating in the architecture it was designed for.
The second use case has a similar feel but included some unique elements. In this case, a product vendor released a security advisory about hard-coded credentials. Ignore the facepalm you just gave yourself because it gets worse. As we all know, once an advisory is out on the wire, it essentially becomes Open Source Intelligence, AKA OSINT. Naturally, this means adversaries are looking at it as well. As it turns out, this customer had just recently exposed this system to the Internet due to remote work pressure, improperly closing available services. The result? Hard-coded credentials found in OSINT news sources were used on port 22 (SSH) for this platform. This allowed full access to the system, command history, and the ability to execute code.
There are a few lessons in these use cases that we can take away from this and apply to everyday security life.
- Use continuous attack surface intelligence: Even though it may seem foundational, understanding your attack surface at all times and on a continuous, not snapshot, basis is critical to understanding risk. Adversaries are always, and more so now, looking for the low hanging fruit. Errors like this are it, and they are hard to find without automation and tooling.
- Use threat intelligence: You don’t need to be an intel expert to get value from contextualized or personalized threat intel. Your adversaries use it, so why let them have that advantage? Knowing that a vulnerability exists in the network and having automated intel about it was vital to heading off this incident before it started.
How to mitigate these pressures
It’s great to be able to find these issues. Everybody is strapped for resources, though, so understanding the priority of issues and how to remediate them can be daunting. Having a product that delivers remediation guidance in detail and with context for prioritization can be immensely helpful. In some instances, bringing people in to help, on a long-term or short-term basis, maybe the optimal choice for some organizations. Regardless of how the resolution of these issues takes place, it is paramount they don’t get overlooked just because they aren’t sexy or sophisticated. Most of the time, the fundamental issues are the ones that lead to more significant, more complex issues.
Speaking of complex issues, one of the questions from the summit was on the opposite side of the perspective of the talk. The question was related to VPN technology and the trends around VPN as an attack vector along with existing alternatives. There most certainly has been a trend in VPN as an attack target or attack vector.
I liken VPN to building a pier into the ocean. Where it will end and who can hit it from the side, rarely does one know with a very high degree of confidence. There are some alternatives to VPN that are worthy of consideration, but many of them combine VPN with other technology or techniques, like TOR for obfuscation and elusiveness. Others propose mixing VPN with browser isolation technology. Yet other solutions exist, like software-defined perimeter and remote workload technology. Before diving into any solution, the industry needs to come up with alternatives, and each organization needs to determine where their risk is the highest before deciding on a strategy.
In closing, it’s easy to say the world is changing, and so is the security landscape. But that’s a reality that we in security have already well accepted. Stay focused on the foundations, employ people, process, and technology to solve complex issues, and always be rethinking your strategy. We know THEY are, so we need to as well.