FEDTECH: What’s the second most overlooked security vector?
Sabaj: The second major overlooked security vector is cloud security. In the context of the federal government, FedRAMP certification goes above and beyond the security that the cloud providers are already providing, which is great. But once you’re in the cloud environment, there’s the whole shared security model. The cloud providers are responsible for the security of the cloud platforms, but once you have your own infrastructure within any of the cloud service providers, you’re responsible for the security of anything that you put in the cloud infrastructure. A lot of people still overlook that fact.
FEDTECH: How does zero trust work in a multicloud environment, where information could be stored in any number of places?
Sabaj: When you get into a multicloud and hybrid cloud environment, you may have data in Amazon Web Services, you may have it in Microsoft Azure, you may have it in Google Cloud Platform. You may be utilizing cloud services like Dropbox or Box. You could have a hybrid cloud where you’re doing virtualization in your own environment. You need a system that’s able to understand all of that and provide consistent security controls across a hybrid and multicloud environment, and not just rely on the information that the individual cloud providers are providing. Not that they don’t provide great information, but AWS isn’t going to monitor Azure for you, and vice versa.
DISCOVER: What security issues must be considered in a zero-trust environment?
From a cloud security perspective, the biggest thing that people can do is implement some type of security posture management tool. Just understanding and knowing your cloud footprint is the first step to securing your cloud, and you need to have a posture management tool to do that.
We have a cloud solution that we call CloudGuard Security Posture Management. It’s a multicloud, hybrid cloud solution that allows you to gain visibility and do security monitoring and automatic remediation of your entire cloud environment. It will go in and scan the cloud environment and do asset discovery, security best practices and continuous monitoring of that cloud environment for security concerns. It also tells you how your cloud environment is interconnected and it can show you blind spots that you have no visibility into.
FEDTECH: So, what’s No. 3?
Sabaj: The next overlooked security vector is the combination of open-source, supply chain and DevOps security. We’re no longer just developing applications, testing them, putting them into production, maintaining them and then updating them on a regular basis. Everything is continuous integration and continuous development, shift left, DevSecOps, DevOps, whatever industry terms you want to use. This introduces the Infrastructure as Code concept, entire applications and environments are spun up in seconds using formation scripts or templates that may be also bringing in third-party libraries and applications. That opens several different security vulnerabilities: insertion of malicious code or supply chain attacks and nonmalicious, poorly written code that may contains security vulnerabilities. Through automation and continuous development, insecure code can be automatically deployed in dozens to thousands of places.
From an open source/DevSecOps/supply chain issue perspective, you need to introduce security into your shift left or DevSecOps process. This comes in the form of Infrastructure as Code scanning. Most cloud environments are scripted and come from formation templates or Ansible scripts or whatever tools you’re using that are pulling information in from different sources and building your cloud environment automatically. It’s very easy to introduce security issues into those templates and then automatically spin up an insecure environment at the drop of a [hat].
You need security that is constantly monitoring your code development for best practices for including vulnerable third-party libraries into your code, for doing things like embedding encryption keys or authentication keys; once that code’s exposed, people can compromise authentication and throw your zero-trust tenets out the window. Just like the security posture management tool, these are continuous tools that are constantly running. You can catch these vulnerabilities as they happen, and it also makes your developers more security aware. It creates that same constant user awareness where, in this case, the user is a developer, not just an average end user.
LEARN MORE: Keep an eye on patched Log4j software for future vulnerabilities.
FEDTECH: I was taken aback by how many commercial IT products relied on Log4j. Was that a generally known fact before the vulnerability was discovered?
Sabaj: Log4j was used in literally millions of applications out there. Really, any Java application that was doing logging used Log4j. It wasn’t malicious; it was a library that was created many years ago that was maintained by a few individuals who did this in their spare time, unpaid. It brings up the issue of who’s ultimately responsible for the security of open source.
You had lots of commercial applications using Log4j. Many security vendors were using it. Check Point was using it, but we were using a different version than the vulnerable one. It wasn’t that we saw a specific issue with that version of Log4j, but we thought a different version was more secure and we were right. Again, it brings up the question of who's responsible at the end of the day for the security of all these commercial applications using open source. I would like to think the commercial operators should be doing their due diligence and not relying on a couple of really nice guys that maintained this code for free for many, many years.
We have an application security product called CloudGuard AppSec. It’s an artificial intelligence-based application security platform that mainly runs in the cloud but can also run in hybrid cloud. It was really the only solution that we know of that was able to detect Log4j before it was even known. Now, we didn’t detect it as Log4j, we detected it as a possible cross-site scripting attack, which essentially it was, but we were detecting Log4j before it was even known with this AI-powered solution.
