AppSec: Engineering, Attackers, and Defense

Intro: This is the Cloud Security Today podcast, where leaders learn how to get Cloud security done. And now, your host, Matt Chiodi.

[00:14] Matt Chiodi: When you think about application security, what's the first thing that comes to mind? It's usually the code itself. Think about whatever language, maybe, your developers code in, you often think about securing just the application code itself, but with the guest that we're talking on today's podcast, is Daniel Krivelevich from Palo Alto Networks, we're going to go into a different side of AppSec, and this is what I would call AppSec for the modern engineering ecosystem, and a lot of this is based on a blog that I'll reference in the podcast, as I talked to Daniel, that he wrote back on May 18 of 2023. You can find that blog by looking at the show notes or going to Palo Alto Networks website and searching for that blog title.

In it, what Daniel talked about is this whole shift that's happened in software engineering, and during the conversation, I asked him to elaborate on those changes. We talked about how everything has become codified, we talk about new attack vectors, specifically those attack vectors, and how they impact the CI/CD pipeline, and then we talk about ways that you can mitigate those threats and some best practices. So, I really enjoyed this interview.

I can tell you, being a podcast now for the last almost three years, if you're thinking about it, maybe you've thought about, “hey, I want to do a podcast myself,” I encourage you just go out and do it. When I first started doing this, I think I've said this before, I had never done it before. I didn't know what tools to use, but the ecosystem that's out there now has made it so easy to do podcasting, and really, if you have an idea, and you're just curious, that's the best way to get started. Anyway, I hope you enjoy the interview that I have with Daniel from Palo Alto Networks, and as I've asked before, if you love the podcast, please give us a five-star review in your podcast app. It makes a huge difference in terms of our outreach and the visibility that we're given on different podcast platforms. Enjoy the show.

Daniel, thank you for joining us today.

[02:24] Daniel Krivelevich: Thank you, it's great to be here.

[02:26] Matt: This is going to be awesome. I'm excited about this conversation. I was looking over just the last couple months of topics, and I think the one we're going to go in today is going to be really exciting because we haven't covered it before. So, thanks for being here.

Let's just jump kind of right into it now. I thought this was interesting. Typically, when I have guests on, they've usually been in, I call it one side of security or another. Either they're on the offensive side or they've been on the defensive side. You're unique, because you've been on both sides of that game - offensive and some hacker-type roles, and also, defensive. Tell us just a little bit about how those roles and those experiences throughout your career have shaped your views around application security.

[03:15] Daniel: Sure. So, yeah, my career in security began when I was 18, joining the IDF, the Israeli army, 8200, the Israeli NSA. So, that was my first taste of the cyber domain, although not in great depth, but then when I was discharged from the army, I began doing some penetration testing, mainly on web application security. So, that was the first glimpse I had at the challenge of securing web applications, but the only thing I did was find flaws in applications and hand the report to someone to fix, and then I went to the other side and worked with a SaaS company called LivePerson, taking the role of the person that handles the requests, so I lead application security. I was responsible for working with the developers on secure design, secure development, implementing various controls, measures, knowledge education. So, that was a really good experience in understanding the complexity of being an enabling function in security and experiencing what it is to scale up as one AppSec practitioner to hundreds of developers.

I then worked with an incident response company that had all of its methodologies based on analysis against the attacker’s perspective and understanding how to build an organization's posture in relation to the attacker’s perspective, and scenario-based analysis, and over there, everything we did was is around taking the knowledge we gained in real incidents with real attackers, and understanding how to build an organization's posture in light of this. My focus was on application security and cloud security. So, basically, everything I did was around how to identify organizations’ Crown Jewels, most critical applications, and then understand, together with the organization, what are the development and deployment processes that relate to those applications, and the ways with which attacker is going to be used those development and deployment processes, and what posture measures are relevant for being effective against those types of risks and scenarios?

But with a very deep focus on not doing security just because a specific benchmark, or control, or compliance, or regulations dictates it, but rather understanding exactly what types of attacks and attack scenarios and attacker TTPs those controls will be effective against. Over there, I got to experience working with various types of organizations of different sizes, different levels of security, maturity, different verticals, different domains, and I learned a lot about CI/CD security and learned about the attackers and the opportunities that they have in abusing the engineering ecosystem, and I also learned about a lot of things that are common to every single organization, no matter how far they are along the digital transformation journey, or the size of the security team, or how mature they are.

I saw, consistently, that there's a gap around understanding what posture measures are required in the engineering ecosystem and understanding what is the attacker’s perspective of it? Those experiences were pivotal in what later-on went on to become Cidersecurity, the startup that I had founded together with Guy Fletcher, who was a CISO in his previous role, was recently acquired by Palo Alto Networks, and going back to your question, I think, having the perspective of both the person that breaks the applications and the person that receives the report from the person who breaks the application, and the person who works with CISOs on implementing apps and programs, and then the person who builds products that are meant to be suited and tailored for the needs of the practitioner, has helped me a lot in informing my understandings as an AppSec practitioner, understanding the domain understanding what the practitioner needs, and understanding the importance of adopting the attacker’s perspective in scenario-based analysis, and I think it's super relevant in today's world where we're finally seeing that the attacks that abuse the engineering ecosystem, they're not theory anymore, they're not based on science fiction.

They're based on real hacks with real attackers that are happening pretty much on a bi-weekly or monthly basis, where we're seeing the most sensitive environments in the world, being exploited by the most skilled hackers in the world, with everything focusing on abusing security flaws in the engineering ecosystem, and so AppSec as a whole becomes driven a lot less by controls, and a lot more by realistic threats, and so just to sum it up, having that perspective of both the attacker and the defender, and the builder, has really been helpful in understanding what it takes to bring AppSec to where it needs to be to meet the challenges of today.

[09:05] Matt: I think that's interesting, because again, I don't think a lot of practitioners have that kind of diverse skillset where they've seen it from both sides, and I think it was interesting, because I was looking at the blog you did back on May 18. It was titled, AppSec for the modern engineering ecosystem. Our listeners can find that on Palo Alto Networks website. In the blog, you talked about a paradigm shift that’s happened in software engineering. Can you talk a little bit more about what that shift entails and why it's happening now?

[09:41] Daniel: I think what happened, let's say with the rise of DevOps, and as soon as DevOps started becoming a commodity and everything started to become codified, engineering started moving a lot faster, in parallel to organizations realizing that digital transformations can help to do business better, and investment in software engineering, and enabling good, fast software engineering is something that is super helpful for the needs of the business. So, as organizations invested more in software engineering, as software engineering became a bigger and bigger part of what makes more and more organizations tick, obviously, there was a rise in the technologies that support effective engineering, fast engineering, security started also being in the role of an enabler of another function in the organization that supports fast engineering and that paradigm shift is organizations investing and engineering organizations realizing that engineering is super helpful in making the business tick and wanting to bring the best engineers on board. The best engineers want to work with the most modern technologies, want to be as flexible and agile as required to build the best applications in the world, and so, software development is much faster, much more agile today, much more reliant on third parties, much quicker to adopt new technologies to replace existing technologies if they don't work anymore.

So, the entropy of the engineering ecosystem has grown so much, and obviously with very, very good impact on the business, the fact that engineering is faster, and the fact that engineers have more independence, and more freedom creates more motivation to invest in software engineering, because it helps making businesses more successful. Obviously, there's a security angle at all, but in general, this is a very positive trend for businesses.

[12:01] Matt: I think it's interesting, you talk about the shift, and I was thinking about some of the things that you said, that DevOps is something we've been talking now about in the industry for probably a decade or more, and then I feel like that the business term that grew very buzzworthy, over the last five years was digital transformation. DevOps preceded that. But the bottom line for all this is that businesses are going faster because of those things. I agree with you that the article was written probably 15 years ago now about software eating the world, that's now become a reality. When it was originally written, it was more of a “this is coming.” That’s here. It's been here, and I think you said that the business recognized the value of engineering because it could create better apps. So, I guess the question is, you know, where does that leave security in all that? Because the engineering is moving faster, the business is recognizing it, there's not probably a single board member anywhere out there that would say that cybersecurity isn't important. But where's that? Where's that gap? Where does that leave us?

[13:14] Daniel: So, I think the role of security in the organization, the expectation from the security function, is to be an enabler, just like any other function. The investment in software engineering, and the expectation from software engineering is to move as fast as possible, and to ship applications to production as fast as possible, and every other function needs to support that and become an enabler. So, the role of security, that's completely different to what it was, let's say, when I was the AppSec practitioner, some eight nine years ago. I was not an enabler in terms of my positioning in the organization, security was kind of a blocking function, security was a function that dictates what technology should be used, what should not be used, and security was some sort of block or gate before release to production, and that was probably okay for the world of monolithic applications written in Java, or Dot Net, and released to production once every few weeks, once every few months, but today, in Agile development, with CI/CD, with multiple releases a day or, in some organizations, multiple releases an hour, with so many technologies and frameworks that the organization wants engineering to use, the role of security is to be an enabler to that, to become a guardrail, and that completely changes the MO of the security practitioner.

Once Security stops being the entity that dictates the pace and becomes the entity that needs to follow up and keep up with the pace of engineering, it requires a completely different mindset, a completely different set of technologies and processes to understand what engineers are doing, what technologies they're using, what frameworks, visualizing the full path of how code makes its way all the way from the engineer’s workstation to production, and understanding on a continuous manner, what security measures and controls are required to identify when something is wrong, when a technology is adopted, that might have a negative impact on security, and then identifying, again, on a continuous manner. We said the entropy is high. It changes all the time. So, having the visibility and the knowledge to understand which controls are suitable in which places, and what is going to ensure that all these changes that are happening in the engineering ecosystem, whether it relates to the code that is being sent within the pipeline, or the security of the pipeline itself, the systems and the processes in the engineering ecosystem, making sure that all these changes that engineers are introducing don't have a negative impact on security, without creating friction, without disrupting or slowing down engineering. That's the big challenge of security today, and it relates both to technology and products, but also to processes and knowledge and the softer side of things.

[16:41] Matt: You mentioned that there's the need for security to move at the speed of engineering, but I guess to play, be a little bit, maybe, devil's advocate, do you think it's realistic for security to keep up with the pace of the rapid developments in engineering? Because, like you said, I think, one of the things we'll talk about more is getting to a little bit with frameworks, but the pace of software development is so fast. I mean, is it realistic for security to keep up with that rapid pace? What does that even look like?

[17:17] Daniel: Yeah, so first of all, the answer is yes, and the answer is yes, one, because there is no other choice, but mainly, two, because the technology and the knowledge is there to understand how this should be done and to develop processes and products accordingly. I think this is part, for me, the way I understand this, this is part of the natural trajectory of any domain. Builders are always the first to adopt new technologies, attackers are always before security in identifying all these opportunities, and then defenders and product builders are behind the attackers in understanding the attacker opportunities and building processes and technologies to adopt to the reality, and it happened with Active Directory security. It happened with endpoint security. It is happening today with cloud security that builders started building and adopting new technologies and completely changing the attack surface. The attacker has started realizing this, like Active Directory security, it was so easy 10/15 years ago, given access to a specific workstation or any sort of foothold in a domain, to become domain admin within minutes.

Today, it's very far from being realistic in the majority of organizations, and that's because we have really good technologies and processes, and understandings, on how to be at a level playing field with the attackers, and it happened the same with endpoint security, and it is happening today in cloud security, and it will happen with application security. That's part of the natural trajectory of things, and I think now, with the pace of development, and the pace at which product builders are able to build really good, easy to adopt, quick to value products, then yes, it is definitely possible. I think the challenge is helping defenders focus on what matters. Not all repos in a source control system are alike. Not all of them should be treated equally in terms of the controls, the measures, the priority of a specific issue or risk that is identified, and having that context, having the ability to say “deal with this before you deal with this” in any sort of risk pertaining to engineering ecosystem, that I think, is the main challenge that all product builders in AppSec are trying to solve today. The noise reduction or the noise filtering. But, in my view, it is achievable, and it will happen within the course of the coming few years.

[20:24] Matt: I think from a defenders perspective, one of the things I often hear the most is that engineers, they have the freedom to choose their technologies and their frameworks, and they choose not just one, but multiple, oftentimes. How does that freedom of choice that the engineers have, how have you seen that impact security efforts, and is there a way to allow, let's call that this creativity on that side, but at the same time, doing it in a certain way that it doesn't negatively impact security efforts? Is that possible?

[21:02] Daniel: So yeah, I think, going back to some of the topics we discussed earlier, it all begins with visibility. Let's take CodeCov, for example, one of the biggest supply chain attacks in history. Just to give a bit of context, CodeCov is a tool used by engineers to collect metrics about testing and code coverage, and one of the most common ways of using CodeCov was by introducing a step in the CI, in the build process, that collects metrics and sends them to the code called back end, and what had happened is that the CodeCov infrastructure was compromised and any organization using CodeCov as part of their CI had their secrets, or anything that was stored as an environment variable, compromised and exfiltrated and sent to the attacker’s cloud. So, that was a very high magnitude attack, and the simplicity of the attack, or the ratio between how simple it was and how widespread it was, what was shocking, because all it takes to use CodeCov is one simple line in a CI file. This is the effort required by engineers to adopt a specific third-party technology in the CI, and at any given moment, any single organization would have dozens and dozens of these third parties that they've implemented as part of the build process, which is one subset of this massive attack surface, and the ease of adoption is amazing. It's one line of code that completely changes the attack surface and introduces an organization into the attack surface in a way that if that organization is compromised, then my own data is at risk.

At any given point in time, each organization that has a heavy reliance on software engineering, and has what's considered to be a modern engineering ecosystem, they would have hundreds of these third parties that are implemented using various ways, whereby each one of these third parties, if it were to be compromised by an attacker, the organization's own organic assets and secrets, and credentials, and code, would be at risk, and obviously, the reality is not going to be such that security is going to go back to be a blocker and start dictating or enforcing controls around which third parties should or should not be used. What will happen is that there will be technologies and products which detect usage of every one of these third parties across the entire engineering ecosystem, and basically, have a very good understanding of what the attack surface looks like at any given point in time, and defenders will have much better governance capabilities and start having very good visibility into overly-permissive third parties or stale third parties, or any third party that has more impact on the attack surface than it should, and gradually, we will see the attack surface being reduced, and what we will also see is measures taken to ensure that if a third party is indeed compromised, and if it has a negative effect on my organization, the blast radius is as small as possible, the next phase, the damage which an attacker can do, is minimal. So, these are two trends that should happen, and are actually happening, minimizing and reducing the attack surface, and minimizing the potential damage that an attacker could do should they already have some sort of foothold inside any subset of the engineering ecosystem, whether it's the source control, the CI, the artifact repository, the container registry, and so on.

[25:25] Ad Prisma cloud secures infrastructure, applications, data, and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider API's, and a unified agent framework, users gain unmatched visibility and protection. Prisma cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan Infrastructure As Code templates, container images, serverless functions, and more, while gaining powerful full stack runtime protection. This is Unified Security for DevOps and security teams. To find out more, go to Prismacloud.io.

[26:14] Matt: One of the things you talked about in the blog that I mentioned earlier, is the whole concept of codification. This transition towards Infrastructure As Code, Policy As Code, really Everything As Code. Where does that come in? Because I know there's obviously this wide gamut of organizations that are doing maybe some Infrastructure As Code, you've got organizations like Netflix that are elevating the other side, or they've probably been doing Everything As Code for a long time. There are organizations that are just starting to do it. In fact, I speak to very few organizations, even in the highly regulated industries now, who are not doing something with, Infrastructure As Code. I guess the question is, what role does this codification of everything, or what role could it play in helping organizations to reduce the attack surface? If you're putting everything in someplace where it is defined, that should mean that then it can be inspected more easily than if it's something that's just being done variably down the road in some type of runtime. Where does this whole Everything As Code fit in with reducing the attack surface?

[27:28] Daniel: Yeah, like you said, I think it introduces a lot of opportunities to enforce policies much easier and to be much more consistent with a policy enforcement and to even validate that you're consistent, and that the policy is actually enforced in every single place that it should be. The reality, prior to Infrastructure As Code, where people managed data centers with logging into to vSphere, logging into whichever virtualization web console was used, and try to manage that across the entire organization is one where it was very hard to enforce policies, it was very hard to even think about policies, definitely not in a way that's reliant on technology.

But the fact that the traditional role of the system engineer has been replaced by a DevOps engineer, which manages entire data centers, with JSON files managed inside repos and source control systems, that creates an amazing opportunity to create this one choke point, one place where I can visualize or understand what my infrastructure looks like, what my applications look like, what everything that is codified looks like, and make sure that I have the right controls in the right places and be able to effectively detect where I don't, and that has only become possible, because everything is codified, because everything is stored in source control, because people are thinking about drifts, people are thinking about it's sensible and reasonable for defenders and for engineers to say, “okay, I can look at my runtime, I can look at my data center, and I can cross reference it to what I'm seeing in the code.”

And then there's this concept of drift. I can see where the runtime is not aligned with the code, and I'm happy and motivated to fix it. That concept of drifts never existed before infrastructure started becoming codified and for everything started becoming codified. So, on the one hand, it's expanding the attack surface. On the other hand, and it's creating opportunities that never existed before in governance, visibility, and creating policies and enforcing policies, and that's also a trend that we're seeing happening more and more with many of the organizations that we work with.

[30:20] Matt: So, in order to do all these things, and maybe we'll go back to a point you made earlier, in order to codify everything, to use Infrastructure As Code, an organization has to have a fairly robust CI/CD pipeline. You mentioned before that that pipeline itself, all that engineering telemetry, has become a major target for attackers. Now, this tooling, it's existed. Obviously, there's a constant evolution, but it's not like these tools, tools like Jenkins and whatnot, have not been around for a while, but I think the orchestration of all of these tools coming together, the third-party ecosystem, all these tools, that has become such a target for attackers. Do you think that this could possibly be a reflection of security teams just focusing too much on the application layer and really neglecting the other potential attack factors, like the pipeline itself? Is this just something that you think, before we've talked placidly just about AppSec itself, which was focusing on the code of the app, not all of the systems behind it, that created it?

[31:34] Daniel: So, it's a great question. I think it's a reflection on several things. One, is that there's a lot more engineering, and a lot more engineering systems and processes being used. The investment in engineering is much greater, and also, the pace at which organization third parties in the engineering ecosystem are adopted, or the pace at which changes that might have potentially a negative impact on security and engineering ecosystem has grown, and this is all a result of the fact that engineers have much more independence and freedom to choose which technologies and frameworks they want to use, plus the providers of these technologies and frameworks to make it much, much easier to adopt them. So, that's one thing that's happening.

Another thing that's happening, and this has nothing to do with engineers, it has to do with attackers, is that attackers always choose the path of least resistance, and the reality of today is that, in many ways, the engineering ecosystem is becoming the path of least resistance, and we talked about how security technologies mature, builders adopt, attackers identify potential, capitalize on the potential, and then defenders close the gap, and while other areas might have previously been the path of least resistance, this is not happening anymore. When you take the engineering ecosystem, and again, the ease at which changes with negative impact potentially on the attack surface happen, it is creating so many opportunities for attackers.

Think about dependency confusion, for example. Dependency confusion, all it takes for a successful dependency and confusion attack to happen is for an attacker to upload one package to NPM or to any other package repository, and that's it. From that point forward, potentially 1000s, or millions of workstations or endpoints, developer workstation, CI systems are infected. The attacker just uploads one package, they don't need access to any one of their target systems, and then their malicious code is fetched and executed on millions of clients. That's the ease at which attackers can execute malicious code with an engineering ecosystem, and dependency confusion is just one factor.

So, yeah, I think it's a combination of builders changing the way they build, plus attackers just going for the easiest targets that has created this reality of today.

[34:44] Matt: Well, we've talked about the problem quite a bit, but let's talk about how does an organization begin to mitigate all these different types of threats? Let's talk about, maybe, some practical steps that organizations can take to mitigate the risks that we've talked about with an increasingly complex engineering ecosystem. What have you seen work well? I don't know if there's any stories you can tell, but what are some practical steps organizations can take to begin to mitigate these risks of this, really, just a increasingly complex engineering ecosystem? 

[35:21] Daniel: Sure. I think first and foremost, and far, far above all, is visibility. It's understanding that securing the engineering ecosystem, in a reality where security is a guardrail, an enabler, and not a blocker, requires visibility. You cannot just buy the best AppSec technologies on the shelf and retrofit them to your stack and do that on a continuous manner. It can only be done if you understand what it is that you're protecting, and if you're capable of understanding the changes in your attack surface on a continuous manner, and that pertains not just to the risk of attackers hacking your CI or source control system, or whatever it may be. It pertains both to the posture of the systems and processes in your engineering ecosystem, and it also pertains to the controls you're applying against the code and the artifacts that you're shipping through the engineering system to production, because they, too, have negative impact on security.

When a developer adopts a new Infrastructure As Code framework, or chooses to use any other new technology that could cause security flaws or security misconfigurations to be shipped to production, we as defenders need to be able to detect that and understand whether this change has negative impact or has controls that are appropriate to that specific technologies that have been adopted, that we should implement, and the only way of achieving this understanding of what are the changes that engineers are making, and deriving the security ramifications of it, is having very comprehensive visibility, and being able to achieve that on a continuous manner, because we said, the entropy is high.

The way we like to describe it is understanding what the engineering ecosystem looks like under the hood, just like when you open the hood of a vehicle, and you see so many different moving parts. Some are visible, some are partially visible, some are not visible at all, but they all have a very significant impact on the vehicle moving forward and they all need to work well, and you need to make sure that nothing bad is happening at any one of them, and understanding what the engineering system looks like under the hood is the first set of measures I would implement, and the first set of controls or questions I would recommend organizations asking: how good is my understanding of what the engineering ecosystem looks like under the hood, and how strong are my capabilities to detect changes that have a potential negative impact on the attack surface? Once you've achieved that, then I think there's a lot of controls and measures having to do with assessing the posture of the supply chain of the third parties that you're introducing into the engineering ecosystem.

In taking those proactive controls and measures to reduce the attack surface, from my experience, with the gain in that visibility, there are a lot of quick wins that can be adopted in any organization that, with relatively low effort, can have a very significant impact on reducing the attack surface.

[39:20] Matt: So, you mentioned getting visibility being that critical first step, and then you kind of have a little teaser there at the end that there are things you can do to get some quick wins. So, it sounds like getting visibility, you've got to have the right process and products to be able to do that. Certainly, process is a big part of it. Products are a part of it. Now, if I do that, if I Institute the right processes so that the security team is regularly liaising with the engineering team, so obviously people are a huge part of it. Let's say I've got a tool in place, something that's giving me visibility into that, what's next? What do you go to next once you're like, “Oh crap. Now, I see the mess that maybe exists because I've never had that visibility to go that deep into the engineering ecosystem. Now I have it.” What's next?

[40:13] Daniel: Yeah, like I began to describe earlier, I think, once you have that visibility, you are usually capable of significantly reducing your attack surface by removing all these stale, or overly permissive, or redundant, third parties by removing systems which are no longer in use, or upgrading self-hosted systems, which are not up to date. It's so often the case, for example, that, let's take Jenkins, for example. Jenkins is famous for being the most widely used CI system in the world, by far. It’s infamous for being the one that's hardest to secure, and the one that potentially has the most security flaws. Everybody uses Jenkins. It's very popular, for many, many years amongst engineers, and it's so often the case where Jenkins, to me as a security practitioner, is no different than the organization's vault, for example, or the PIM/PAM solution. From the attacker’s perspective, it's the same. It's a system that stores the credentials to the most critical systems in the estate. Just because it has to deploy artifacts to them. It has permissions to the cloud environment and has permissions to any environment running sensitive workloads, just because it needs to deploy artifacts or code to them on a day-to-day basis.

So, it’ll very often will be the case that from an attacker’s perspective, the importance of the CI solution, Jenkins, for example, and the importance of the domain controllers, in the Active Directory, the vault solution, will be the same. But even though it is the case, it is very often the case where organizations aren't aware of all the Jenkins instances that exist in the environment, or even if they're aware, they're not even shipping logs from Jenkins to the sim. They wouldn't be able to detect an incident that is happening or investigate it properly. They would be completely blind to the incident and might only be able to detect it after the damage has already been done. So, yeah, I think the majority of my time spent in Insider, and also with Prisma Cloud today is using that visibility to then identify those low hanging fruits that have a massive impact on posture and can be implemented easily.

Now, it takes a long time, it's a long journey to bring security posture of the engineering ecosystem from nothing, or from something minimal, to perfect, and that's not the challenge that the majority of organizations are facing. The majority of organizations I work with aren't working to get the posture of their engineering ecosystem from good to great. They are working on getting it from nothing, or something minimal, to something adequate, and that can usually be done with a very simple set of steps and controls that can be implemented in a relatively short amount of time, and the challenge is identifying that set of high impact, low effort set of controls and measures that could really bring posture up to an adequate level within a few months. Yeah, that's a big part of what I spend my day-to-day doing today.

[44:40] Matt: It seems like, and I've been doing cybersecurity for about 23 years now, and it seems like things change, but when you really drill into it, the technology changes, but where organizations are struggling, it still seems like it's almost always what I would consider cybersecurity 101. Asset Management, keeping things up to date, that itself seems like something that many organizations universally struggle with. It is the low hanging fruit. It's not usually the zero days that are what's leading. It's that security 101 that, for some reason, seems so pervasive, and yet, so, so difficult to just achieve those very basic and maybe even somewhat boring things in cybersecurity that end up being in an 80/20 model - those 20% of the things that cause 80% of your problems.

[45:39] Daniel: I agree. I agree. I think it's proven that, I think, these high magnitude cyber events, like Log4j, even SolarWinds, they are becoming top of mind, not just for CISOs, but for CEOs. They are discussed in board meetings because they achieve such a high level of exposure, and the investment in security grows. I think there are more organizations that undergo digital transformation and that realize that the investment in security is essential, and so, when the economy is not in a big financial downturn, we're seeing security budgets grow, we're seeing more executives that realize that investment in security must be made, and, I agree with that notion that the Pareto law still is very relevant to security programs today, but I think it has improved over the last two, three years.

[47:00] Matt: Daniel, I love this. This has been a great conversation. The last question I have for you, and I ask all my guests this, is how do you personally stay sharp? What are you reading? What are you listening to? There's so much happening in the in the field of AppSec and DevOps. How do you stay sharp?

[47:18] Daniel: Yes, I think one of the main advantages of working in Palo Alto is that you get to talk to a lot of clients, you get to be exposed to a lot of environments, and you have a lot of smart people that spend their time distilling and dissecting the pains across so many different organizations. So, I do spend a lot of time talking to clients, talking to people, talking to clients across different levels of maturity across many domains and verticals, and that I think, for me, is better than any specific reading material because it focuses on the real pains of the practitioner more than it does focus on fears. I think, other than that, LinkedIn, for me, has become really good source for keeping track of notable publications, notable trends in the industry. I had a startup up until a few months ago, and startups tend to stay at the peak of innovation and also, at the peak of being motivated to publish good materials to pretty much any platform on which materials can be published, so if you follow the right people on LinkedIn, if you follow the entrepreneurs and the VCs, and that ecosystem of innovation, LinkedIn will make sure all these things that have to do with staying sharp and being knowledgeable or informed about everything that's important that's happening in the industry. So, I guess for me, those would be the main sources of staying up to date.

[49:36] Matt: I love it, and it seems like for most people I've interviewed in the last year, LinkedIn, it has become that source, and if our listeners want to connect with you, I assume LinkedIn is probably the best way to do that as well. Is that right?

[49:48] Daniel: Yeah, definitely.

[49:49] Matt: I love it. Alright, well, this has been a great conversation, and this has been just fun, and I think something that our listeners will really enjoy. Daniel, thank you so much for coming on the show.

[20:01] Daniel: Thank you. It was great to be here.

Outro: Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.