Home

Threat & Vulnerability Management

Threat & Vulnerability Management
RansomwareRansomware

What is the current state of ransomware attacks? What level of defense and preparedness do companies have from their backup support?

If you had a magic wand - what's the #1 daily business challenge you'd eliminate?

Top Answer: Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.

Does the concept of Attack Surface Management vs. Attack Surface Analysis make sense to you?

Top Answer: Speaking from a security standpoint the two terms mean different things and they should be distinguished. Attack Surface Analysis is an analysis of the number of exploitable vulnerabilities. It can be used by both sides to discover weaknesses in a system. You start by scanning the target for vulnerabilities and then checking which ones have exploits available, and you choose the attack vector. OWASP has an attack surface analysis cheat sheet. Attack Surface Management is the process of, discovering/resonance, inventorying, classification and monitoring of the systems. This is more on the offensive (attacker) side point of view. You are looking at what IT assets are exposed inside the organization and to the internet.

RansomwareRansomware

What is the future of cybersecurity and what changes are organizations making? Should the government implement more defined rules to protect businesses from cyber attacks?

What advice would you give security practitioners regarding evolving cyber threats?

Top Answer: Just like you can’t defend what you can’t see, another hard truth is that you can’t secure that which you don’t understand. I think the #1 issue in this space today is the pace of change and the difficulty that security practitioners have keeping up, especially in environments that have multiple generations of technology. If I had one piece of advice for security practitioners, it’s that you need to stay current with new technology as, or before it's being adopted in your firm. Your colleagues can’t and won’t put their deadlines on hold to wait for security to catch up. I can't emphasize that enough. If you take a job as a CISO or security analyst at an AWS shop, you need to be getting AWS knowledge and certifications to demonstrate to your peers that you understand the space. If you take a job at an Azure shop, a GCP shop or a mainframe shop, you need to be gaining knowledge on those platforms and technologies that you're responsible for securing.  Fundamentally, you can’t do it without your colleagues and teammates, and if you don’t understand mainframe security, the mainframe operator who's been doing it for 30 years isn't going to listen to you. If you're not constantly learning and taking courses from places like Coursera or Pluralsight or somewhere, you'll be stale in two years. The idea is to stay ahead of the curve, which is only possible if you have already caught up and can keep up. And if you aren’t caught up with today, it’s almost impossible to anticipate the attacks of tomorrow. 

What do you think of organizations’ responses to the potential for cyber threats due to the Russia-Ukraine conflict?

Top Answer: When the Russia-Ukraine conflict came to a head earlier this year, our company offered small and medium enterprises our product for free, to help with the impact. We made the offer via LinkedIn and got upwards of 1,600 views within 24 hours, but nobody responded. I'm not sure why, but the early feedback I received from several peers was that the offer hadn’t moved the needle for them because this conflict was seen as a formidable global opponent, which has been found to be not worth the effort. The estimates were overblown and there hasn’t been much impact. A lot of the nation-state teams that I read from continue to predict that we have yet to see the best of what’s to come. So my question is: What's the benefit of holding back your punch? I sense that there is another piece that has yet to fall into place. We're only seeing the early steps towards something. 

How should security leaders approach API security today?

Top Answer: Security leaders should approach API security holistically. The first generation of API security tools did a good job of illuminating the core problem and the need to monitor API traffic, but it was limited to a “spotlight approach,” which means it only focused on part of the problem. As a CISO, I want to see sunlight: I want to see everything from code to production, with simulated attacks to validate and prioritize exposures. For the last 18 years as a CISO, I've said to vendors, partners and suppliers, “Whatever the threat model is, I need to see assets; actors, meaning who's involved; interfaces, so I know how they are getting to my assets; and actions, which show me who's doing what to what via what.” Only when you have that visibility can you develop a baseline for what normal behavior looks like. Once you have that baseline and you can get your arms around your space, then you reduce your attack surface and deploy resources to remediation of code and 24/7 monitoring, and use machine learning and automated models to alert you when something deviates from that normative behavior. But you can't monitor or defend what you can't see, and blind spots are prevalent; around 50% of APIs are unmanaged today.  That focus on visibility is one reason I’m a fan of the NIST model here in the US; the first principle is “identify.” You can’t protect what you can’t see. Creating and exposing APIs is very easy, but finding, governing, and securing them all is not. Adoption of APIs and their exposed logic has outpaced security and DevOps teams’ ability to keep up with or even put a lens on how their data's coming in and out.

Why is API security so difficult to manage?

Top Answer: There’s an old saying in security: “Your defense must be informed by the offense.” In general, defenders are always one step behind the aggressors, whether we’re talking about the digital or the physical space.  The Maginot Line is a good analogy for the current state of API security in most organizations. The industrial revolution didn’t happen in order to build machine guns, it was for commercial reasons. But these innovations created new military capabilities and in 1914, defenders in Europe didn't anticipate the degree to which the attackers were embracing industrialization in the context of kinetic warfare. Unfortunately, this meant they went riding into battle to defend their homelands on horseback, only to be met by mechanized columns of machine gun fire. After that conflict, in 1930, the best military minds in Europe began construction of the Maginot Line, which was an amazing set of fortifications built to resist a robust ground invasion like the ones they had just endured. But only 10 years later, the next attacks went around the Maginot Line through Belgium and the Luftwaffe flew right over it. The Maginot Line, as impressive as it was, provided a false sense of security and failed to take into account the next set of innovative thought patterns of the attackers. This is basically what we’re seeing in the world of web security, and these same rules apply to what’s happening across the world as companies rapidly create and expose their APIs.  We've been dealing with and securing web apps for over 20 years, but 20 years ago they were built much differently than they are today. The legacy term is “monolithic application,” and that was a standard design pattern for years and years; many companies still operate this way. There’s a well-known application security model from an organization called OWASP, and while it’s still valid, it was first published in 2003. You still have to defend against the attacks from the original OWASP Top 10, like SQL injection and cross-site scripting (XSS). But now companies and governments are rapidly embracing APIs and microservices, and in doing so they're expecting these new exposed services to do a lot more of the security that used to be centralized. The “I” in API stands for interface, and publishing new interfaces changes your attack surface. Attackers always change their tactics to take advantage of new attack surfaces, and if your defenses don’t evolve in real time, you are left with gaps and undefended blind spots. A lot of security and development teams don’t know that OWASP published a new Top 10 specifically for API vulnerabilities beginning in 2019, so unless they’ve revisited their whole framework in the last year or two, there’s a very good chance that they haven’t taken these new attack vectors into account.  Going back to the Maginot Line analogy: they didn't have anti-aircraft capabilities when they built it because air power wasn't a big thing, so they had to adapt during battle and learn how to defend up, not just left and right. In the same vein, we need to increase our abilities to defend against the new attacks against APIs, but today API adoption is dramatically outpacing security and the longer this happens, the further apart adoption and security get. There's a huge paradigm change from monolithic applications and the old attacks to the new, distributed API and microservice attack surface. The changing attack surface is one thing, but another is what’s available on the new attack surface. APIs expose application and business logic directly. That's not a bug, it’s a feature. It's by design, but the defenses like web application firewalls (WAF) that we use to defend against the old Top 10 list can’t understand or defend against logic-based attacks.  Yet another aspect of modern application architecture is that you can have multiple teams iterating and changing their APIs quickly. Some folks change their APIs several times per week and sometimes several times per day, and security can’t keep up with these changes. But once you fall behind, it's very difficult to catch up. As API security is a very new space, I use the Maginot Line analogy only to provide a non-computerized historical perspective. This paradigm happens over and over again, and in 10 years, it'll be something else. But for now, when it comes to API security, we're all behind the curve and it's become a big problem that is only getting worse, at least in the short term.

Will the US government’s response to ransomware be an effective deterrent for bad actors?

Top Answer: The degree of political pressure or danger for ransomware operators is more real today than it was a year ago, but it's definitely not enough to be a deterrent. When I talk about ransomware, I always try to frame it as a business model rather than as a piece of malware, because it got popularized by grandpa getting phished and we've gotten stuck on thinking about it that way. Ransomware is the ability for a financially motivated bad actor to monetize things that would've been worthless in the absence of ransom as a business model. And that suggests that it will continue to evolve and innovate. There was an interesting campaign against MongoDB and Elasticsearch around 2018, where ransomware operators were saying, "I have your data. Pay me and I'll give it back to you." But they weren't doing that. They were just deleting everything. At the time, that would probably get you hurt by your competitors as a ransomware operator, because they pride themselves on being able to support their customer. But now we've moved on from that. Now there’s this idea of a secondary take around disclosure and spreading out information in that sense just seems like what I'd want to do as a bad actor. So what's next? It doesn't seem to be fading away as a means for cyber criminals to make money.