Security Unfiltered
Security Unfiltered
Balancing Speed and Security in the Tech World with Idan Plotnik CEO of Apiiro
Journey into the world of cybersecurity with Idan Plotnik, a true pioneer in the field, as he revisits the path that led him to become a leading figure in tech innovation. Starting with a childhood fascination for computers, Idan advanced to play a pivotal role in the Israeli cyber security unit, eventually founding Erato, which caught the eye of Microsoft. He shares insights from his tenure as General Manager for Software Engineering at #Microsoft and how his encounters with Satya Nadella ignited his passion to launch his first company in 2019. This episode unravels the stark differences between nimble startups and the often sluggish corporate giants, offering a compelling narrative for aspiring entrepreneurs and industry veterans alike.
Explore the sophisticated challenges of ensuring software and cloud security in today's fast-paced tech environments. With cloud platforms like AWS, Azure, and GCP enabling swift deployments, safeguarding software architecture before cloud deployment becomes crucial. Dive into the intricacies of Apiiro's ASPM platform, which revolutionizes the detection and management of code changes for enhanced security measures. The conversation expands into the realm of AI, highlighting emerging threats and innovative risk-management strategies employed by companies like Apiiro. This episode promises essential insights into balancing development speed with security needs, preparing listeners for the future trajectory of AI in software security.
Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today
how's it going? Don it's uh really great to finally get you on the podcast, or? I guess, uh, maybe again right, because we tried this before and a couple weeks ago and israel became under attack and the internet, uh, was not cooperating very much yeah, so yeah, thanks, joe, for having me for the for the second time. Yeah, yeah, absolutely. Not many people come on a second time.
Speaker 2:Yeah it is, it is, but this is our life. You know, life of a startup is active, so you know we're used to it.
Speaker 1:Yeah, yeah, it's like it's that mentality of, well, I don't know what, I don't know, but I also won't know until I start. Like it's that mentality of, well, I don't know what, I don't know, but I also won't know until I start. Like it's a, it's like a vicious circle. Yeah, Well, you know you done. Why don't we start with? You know how? How you got into tech? Right? So you're, you're from Israel, right? So obviously you probably made your way into the israeli military, as everyone from israel does. Yeah, but I'm wondering about before that time period, were you already interested in tech? Were you already inclined to go? You know a technical route? Um, what was that looking like?
Speaker 2:it's an interesting question, by the way, joe. No, no one asked me this, that question, before and I'm getting uh into a lot of you know interviews lately, tldr. I started programming, uh, when I was, I think, six, when my father back then bought me a computer and, um, and I think it came over like from that moment I fall in love in a computer and I was a technical person from from the beginning, from the early days, and, yes, I served in a cyber security unit at the idea called matzo, and I was there around four and a half years plus. After that I had my own consulting services company, so I did a lot of penetration testing, security code review, risk assessments, custom development for large enterprises, you on the security side and, as part of you know, a casual pen test which was so you were talking to me about how you figured out how to steal the ntlm hash of a device and then you were able to use that to escalate and pivot throughout the environment.
Speaker 1:So if we want to start there, and then also you know why don't we take maybe just a step back? What's the NTLM hash right? Why is it important? Why does it matter in Windows systems?
Speaker 2:So NTLM hash or Kerberos token is actually the identity of the user or the machine is actually the identity of the user or the machine. If you're able to steal that, you don't need to know the password of the user or the password of the computer to be able to move laterally across the organization. And this was a very, very back then sophisticated attack. We all know, you know, know mimikatz and all apt attacks the mimikatz tool, of course, and the amazing person behind it and tldr. This led me to a research and a patent back then to identify, profile and identify abnormal behavior of users and machines inside the network. Back then, we founded a company called Erato. We were pioneers in the UEBA space, sold it to Microsoft in December 2014.
Speaker 2:January 15, we were in at microsoft. Um was amazing, amazing ride. Microsoft. I was the gm for software engineering, running product research, development and data science. I was running the Defender for Identity business. So that's it.
Speaker 2:It was, like you know, from zero to not zero, from $1 million to $416 in three years. It was an amazing growth. You know, microsoft sounds easy but it's not. But I think that now you know, microsoft and CrowdStrike are the biggest companies, cybersecurity companies in the world that are leading the abnormal behavior identity stuff. They also like CrowdStrike also acquired a company back then and I was fortunate enough, to you know, to meet satya in person. I I reported to two people under satya nadela so I had two one-on-one-on-ones with him. I learned a lot about the business and it like moving forward at microsoft.
Speaker 2:I felt kind of a very interesting challenge or pain where, you know, from a startup where you used to deliver code to production on a daily, weekly basis, and now you need to fill out risk assessment questionnaires, you need to go through 10 different scanning tools on your code, go through 10 different scanning tools on your code, you need to go through threat model, pen tests, security reviews, compliance reviews before you ship code to production, and this was a huge pain. Another pain that we faced is when we found risks in production or in runtime, it was very, very hard to attribute it back to the code owner or the code component in our code base and TLDR. This is what led us to leave Microsoft and found Purell back then in 2019, 2020. And back then no one knew what we were talking about. What does it mean?
Speaker 2:Aspm, application Security, password Management? Why do you need another technology to scan, code and protect or understand your software architecture and then expand it to software supply chain and provide a comprehensive platform that allows you to secure your software from design, development and delivery in one risk engine or one platform. So this is my story in a like, in a nutshell, hmm.
Speaker 1:Yeah, I'm sure you know, one of the biggest challenges probably at Microsoft, at any level that you're at within the company, is just the red tape and the processes and the procedures that you have to follow.
Speaker 1:You know, I'm I'm, uh, I'm currently at a at a pretty large company and I mean it takes you, it takes you a year just to decide what you're going to buy, and there's other divisions right Of this same company that takes them three years minimum, like if they go three years of testing products and whatnot, like that's them moving quick, right, and it's, it's weird, right, like I, I feel like I feel like you're not even a technologist to some extent anymore, right, because by the time you make a decision on the product, maybe the players in that space change. Right, maybe the products that you were testing had major issues with. Now, because this process is so, you know, regimented, you know you have to start over, you have to start completely over. You can't just plug one in and move forward. You know, and I'm sure that's probably like one of the internal, you know downfalls at microsoft too.
Speaker 1:Right is where it's like you, you really only move forward.
Speaker 2:I think that, on the security side, microsoft is more. You know, build versus buy and and I don't think this is the issue we solve that in Appiro because we serve around 10% of Fortune 500 companies. We solve this problem by one, providing a seamless integration. You need read-only API to your source control manager. That's it. Read-only API to your source control manager, that's it, and you can do it. You can deploy it fully on-prem in an AirGap environment or hybrid, or use our SaaS offering, whatever, but from the moment you connect us to your source control manager in one hour, and this is the core intellectual property that we've built.
Speaker 2:We developed a technology called DCA, deep code analysis, where we scan the entire history of your code base and then we translate code into entities Like, for example, we know, I would say, components, like we know all your APIs in the code, all your Gen AI usage, all your you know technologies, security controls, exit points, and then we map it on a graph and the aha moment is where you can tell me hey, dan, no way I didn't approve my developers to use a bouncy castle from this version, or I didn't approve my developers to use a bouncy castle from this version, or I didn't approve them to use Spring Security for input validation or authentication. And then you get visibility to your software architecture for the first time. All the other scanning tools out there will scan for all of us. We developed a completely new technology that fully understands your software architecture. And now if you want to connect all your existing tools into Appiro and contextualize their findings, or their noisy findings, and match it to your software architecture and say, okay, it's great that I have sql injection or log4j or secret in code or whatever, but you know what? It's not in a code module with pii, or it's not deployed, or it's not a high business impact application or stuff like that.
Speaker 2:And I think I think this is how we overcome all the barriers of going through very, very large enterprises that are paying multi-million dollar deals to a Puro today. But we did it in small chunks. We did it in small chunks. You can start small and grow with the pure old, but the unique value prop is just to tell you hey, joe, this is your software architecture and the only way to know that is questionnaires or manual security reviews or other self-based attestation processes. That will you like? You say x, yes, I do, I don't have pii and tomorrow you do have pii in your code base and no one will actually identify that in a continuous manner. So I think the value prop plus a very seamless, easy, with short time to value, this is how we overcome and, of course, all the security controls that we have and the regulations that we put in place, and on and on. But this is how we overcome the burden of going through a one-year evaluation process with large enterprises.
Speaker 1:Yeah, a lot of people don't understand or they don't realize how big of a problem this actually is, right, and you know. I'll give you an example. You know, in my environment right now, right, and I've been in other environments where this is the exact situation where you really don't know the third-party libraries, for instance, that are being used in an application, unless your developer specifically tells you or you have a way to call them out on it. Right, there's no way for you to know, you don't know if they're outdated, if they're vulnerable to something. Right that you're opening yourself up to a new attack that you don't even know about. Right, and with how cloud applications are nowadays, you need you know four or five different tool to actually secure your pipeline and your code and make sure that we're not using uh ai models and ways that make us, you know, vulnerable to different, different attacks and whatnot. These are, these are huge, huge problems. One real world.
Speaker 2:Sorry, Joe, no, no, I just wanted to say before we move on, I think that the problem is much more complex than that, because everyone are looking at their text surface in silo. You are now telling me on open source, but if I will tell you, listen, this open source is actually using a secret and in the same code module you have API that expose BI data or an API that sends data to open AI surface. Without understanding your software architecture, you will continue to fight the siloed alerts and you cannot win the battle. You cannot win because you have so many alerts and so many vulnerabilities. You need to contextualize them. You need to first understand your software architecture and only then connect these siloed alerts on top of your software architecture to make sense of them and to understand if they're impacting your business or not. Or you have a toxic combination that you need to handle before you need to handle any log4j or any vulnerable dependency, because you need to look at it as a whole and not as one simple alert and another like this is problem. Another problem is how you identify these combinations early in the development lifecycle before you deploy to production. This is the key, because if you have three, you know, I'm so many years in the cybersecurity industry. The AppSec exists for 20 years.
Speaker 2:And then everyone said shift left, shift left, shift left. And what happened is they blocked developers on every CVSS score eight and above. But who cares about CVSS score if CVSS does not understand your software architecture? And then what happened? You stop developers and they are frustrated from security. So what we decided to do is to build our own risk graph engine. Okay, the risk graph engine actually takes from the DCA the deep code analysis, the software architecture, and then from your CMDB, from your five different SaaS SCA Secrets you know CSPM, whatever tools that you are using and combine them together on a graph and say you know, now Joe opened a pull request and it touches a sensitive data with the sensitive business logic in this code module that transfer money, for example, Plus an open source dependency with vulnerability that is reachable in the code. This is why it's a risk to the business. Let's stop Joe at the pull request and providing remediation guidance or automatically try to fix that. And when you have this context now you can actually shift left. So again, it's not only detecting these types of risks, it's correlating the data, it's understanding the software architecture, and only then you can actually block and prevent risks early at the pull request, before you start the build process, or after, or at the deployment, whatever. It's too late from my point of view. But I'm just saying everyone are missing the point. They are missing the software architecture they need to understand and siloed tools. Care about CVSS core or EPSS core, and it's meaningless and then it's just bombarding developers. And again, I don't want to complicate stuff, but you touched on software supply chain.
Speaker 2:Yes, you need to look at the attack vector. It's a multidimensional attack vector. Someone can breach into your source, Someone can breach into your CICD pipeline or inject malicious code, like in the solar wind attack that actually you know they breached one cidcd pipeline and managed to breach all their, the customers of solar. So it's looking at your code and your code is very complex because it's assembled from first party code code, third-party code, secrets, open-source dependencies, third-party technologies, SDKs and then secure. Make sure that you have all the application security platform from the design phase which we will talk about in a second to the development, to the deliver makes sense yeah, yeah, it makes sense.
Speaker 1:You, uh, I was going to get there, you know where, where we're diving into the actual architecture, right, because actually I've experienced this. You know personally, right, where there was a potential. You know event, right, and we were looking at an application I didn't even know how it was designed, right, where is it pulling the data from? What is it actually doing on the back end? Why is this? You know, a critical production application, right, and there's literally one person at the company that is able to tell me that God forbid, they go on vacation or something, right, like, that's how it was, you know. And now, you know, I'm over here creating the first like architecture diagram of how this application runs, especially in the cloud, right, yeah?
Speaker 1:like especially in the cloud, where people can, you know, just so easily deploy new applications, new architectures, new patterns right using new services in AWS, azure, gcp than are what are you know, even previously approved and whatnot. Like they can do those things and you'll have a sprawling infrastructure that's well beyond what you even think that it is Totally agree, but I want to differentiate between software architecture to infrastructure or cloud architecture.
Speaker 2:Okay, these are totally different inventories, totally different inventories, totally different relationships, totally different components, totally different diagrams. Now, yes, my, if, let's say, an application in java, okay, is it? You developed your restful apis in string and one of the APIs is reading or storing data in a storage bucket. Yes, you want to know that and you can know that today with our DCA, with our deep code analysis, only from scanning the code, okay, without scanning your cloud architecture. Okay. But what I'm trying to say is that the software architecture looks totally different from your cloud architecture and you need to secure that before you deploy to the cloud. And the challenge is you said you are building the diagram, but the diagram will change tomorrow. How do you keep update, updating the diagram for every code commit? That is material, like I don't care if my developer changed the background color of the login page, but I do care if he exposed a new data model in the API of the login page. Yes, absolutely, immediately, I need to trigger a pen test or a security code review if the data model contains sensitive data. And I think this is what the industry is missing because I wouldn't say it's easy, but it's more structured. When you open or enable a new service in aws or a new storage bucket or a new firewall rule, also, you know, prevent that or have segregation of duties with two approvals. But if you're a software developer, we'll add the data model to the API that is responsible for the login page in the UI. No one will know, no one, I promise you.
Speaker 2:And this is the gap that we are solving in Appiro. You know, with our ASPM platform that is powered by the deep code analysis technology. We are telling you that developer all committed the code to your code repo. It's a material change that require a pen test, automatically trigger it without asking anyone. The policy is defined in Apiro with your risk threshold and risk appetite and if you pass this threshold you have gates. At the design phase. We scan JIRA tickets or feature requests Okay, and then we stop you from going to the development phase without Joe doing a threat model on this feature. If you open a pull request or commit code to your feature branch, we will stop you because you committed a material change or a risk based on your software architecture. If you're going to release your artifacts. We will stop you and say, joe, you pass these and these and these policies, which are a graph-based policies across multi, multi-data stores, from code, cmdb and runtime data and more and more. And this is where you know you put the gates before you ship to the cloud.
Speaker 2:Now to your point. If you already you know what. If you ship Log4j three years ago it wasn't vulnerable and today we found the zero day Then you need to attribute this to which pipeline when it was deployed, who approved it. Is it went through a pen test or not? And with the cold owner that actually imported the package, who did the review on the pull request and automatically opened to this developer if he's still in the company, open a pull request to fix it. And this is exactly what we're doing with call-to-runtime matching attributing code components like APIs, open source dependencies, pii fields, authorization logic and others to the code owner.
Speaker 1:Yeah, all of those are. It's like it's close to impossible right now without that stuff, without that sort of technology, and it's a it's a situation that I encounter very often, actually, of where you know someone builds something that maybe throws a vulnerability scanner alarm right and now we got to add context around it. You have to have someone. You know, really it's a couple people getting on a call and talking about why it matters and why we should care about this one module or this one snippet of code right and explaining that to the dev, and then going through the whole process again and hopefully it passes this time right, like without that sort of singular solution.
Speaker 2:Yeah, we have like four different tools to tell us different things yeah so again two problems one, how you consolidate all the findings and contextualizing them and you know who you should talk to. And and the second problem is, again, just aggregating the data and finding the code owner will not be effective if you don't know your software architecture, because you have so many alerts and without understanding the software architecture, you don't know how and what to prioritize. I do want to say just one step back. You said something interesting. I don't know when you're going to publish it, but next week we are announcing unfortunately in an anonymous way.
Speaker 2:We closed the largest deal in the ASPM market ever with Fortune 10 company. I can't say which one, but it's, it's, it's a one of the biggest companies in the world. Why? Because they manage to quantify what you just said. We manage to quantify how many man hours they're investing on every alert in runtime, how how many hours they invest by the way, invest when they find it in runtime, how much time they invest to triage, prioritize and then find the code owner to fix it, because the security team cannot do that. And then how much time they invest on risk assessment questionnaires before releasing to production.
Speaker 2:We actually and I'm going to share, not I, my marketing team are going to share the metrics and the data behind it so you will be able and your audience can go and see exactly the parameter of how we calculated it with the customer and what is the total cost of the cost reduction that we managed to prove to the customer. So I feel, like I feel I felt the pain that you are talking about at Microsoft so I can connect to your day by day, joe and and yes, it's a painful problem and I'm sorry I'm, I'm like a broken record and without understanding your software architecture, you literally cannot do that you literally cannot do that.
Speaker 1:Yeah, yeah, I mean, without even, you know, being able to put numbers to it. Like you mentioned, right, you can't. You can't even really start to like quantify how much work goes into just this section of your business. That's probably not even noticed by upper management, you know, and, like you said, said when they, when they start seeing how much they're actually putting into it, it's like, wait a minute, like we're, we're blowing money right now. This solution over here is cheap compared to what we're actually putting into it. We need to, you know, refocus and refactor and you know free up some time for these. You know highly paid engineers, highly paid developers, to go and do the work that we need them to actually do to make us a Fortune 10 company right To make us the best in the space. When you start quantifying it like that, it speaks volumes that you wouldn't be able to do without it.
Speaker 2:Yes, and think about an AppSec engineer which needs to understand code, which needs to understand a developer's mentality and processes. You need a cloud security engineer that deeply understands AWS architecture and you need the developers to care about because they have strengths. And the developers to care about because they have strengths. And the developers you need to understand them. They want to hit their target and their target is to deliver high-quality features to increase the business, so the business will grow. To increase the business, so the business will grow. If you will keep dealing with security issues again and again and again, you will not deliver value to the business and it's a vicious cycle. So you need to prove as a security, as an application security engineer. I'm telling you I am in.
Speaker 2:We as a company, you know we are a big company. We are involved in the smart, with the smartest AppSec engineers and developers in the world, and we built, I think, the most, I would say, sophisticated AppSec program in the market at the moment. And the reason why we did it? Because we proved in a quantified manner how much effort you need to invest in every sprint in security and if it passes the 5% you're done, go out. You will impact the business in a negative way. So because of the risk-based prioritization, because of the understanding of software architecture.
Speaker 2:Now you compare ASPM platforms. You say, hey, this ASPM platform reduce it by I don't know 25%, and Apiro managed to reduce it by 85% Pure business outcome. And this is why developers love eventually they're not using the Apiro UI, but they're getting the Apiro bot into their toolchain prioritize and fix their risks with simple explanation of why this will impact the business. So, tldr, we have a built-in business outcome report where we show to your upper management two metrics Development velocity goes up, risk goes down before releasing to the cloud and that's it. And this makes sense because finding, as you said a minute ago, to find talent of security engineers it's so hard. Security engineers it's so hard. To find a partner on the software development side, it's so hard. They are very logical people and they're focused on delivering value, high quality software with less bugs, functional bugs and with less security bugs. And this is how we bridge the gap between these teams.
Speaker 1:Yeah, it is. It's an interesting challenge, but from what you described it sounds like the old term, like shift left, right. You can't get any farther left than where you're sitting right, when you're able to inject yourself into the process.
Speaker 2:Exactly, and we just released two at Blackett when Blackett, I don't remember August yeah, two months ago we released, after working with so many customers as design partners, we released our risk detection at the design phase.
Speaker 2:So think about this your product managers are requesting features day in, day out and no one actually like you, have so many product managers and you cannot hire more AppSec engineers and they cannot go and search in JIRA or whatever, wherever you open the feature request, like based on keywords.
Speaker 2:So we developed our own LLM model it's a private model, not based on OpenAI or Hugging Phase or others that can actually, based on understanding of your software architecture, scans the text and say, hey, joe, this is a risky feature request and why, and automatically generate threat model stories based on stride, with contextual mitigations, because we know which authentication framework you use in your software architecture and we know which encryption framework and input validation. So if you requested an integration I don't know with Facebook and send through the API these fields, we will tell you hey, use Spring Security for input validation because the threat can be spoofing, or information disclosure as part of stride, and we do that automatically. This saves tons of time and detect risks that without this automated process you would never identify. So we cover our customers at the design phase, at the feature request phase, at the development phase commit pull request and at the build and deploy phases before you release to the cloud.
Speaker 1:So these are the intersection points where we put our guardrails, our risk-based guardrails, in the development labs. Yeah, that is really fascinating. You know, if you were to project out you know, say five years, where do you think this space is going in five years, with the, you know, heavy use of AI growing right, the usage of these LLMs and whatnot, it's only going to grow from here. It's probably going to grow exponentially quicker than what we expect, it's already growing exponentially.
Speaker 2:We just released internally a report that proves that every customer that started and again, there are two sides of the coin in AI, in a second I will describe, but we looked at the numbers and every customer that enabled Copilot or any other AI-based code assistant, their code, the amount of group, exponentially in the last six months. This is a report that we generated internally. We are thinking about how to anonymize it and maybe publish it externally, but it's not an assumption anymore. It's the fact that the data is showing it so. But there are two sides of this coin. Why? One is you using ai for faster development? Two, it's you as a developer, same developer using ai to make your software more or smarter and more efficient. Like, if you now go and embed OpenAI framework inside your Java application, someone needs to identify it, someone needs to govern it, someone needs to make sure you comply with all the requirements and someone needs to trigger a pen test or a security review or a compliance review in an automatic, proactive way. And this is goes back to our dca, the deep code analysis that identify the software architecture automatically, map all your gen ai usage in code and then trigger a process based on the policy.
Speaker 2:Now, I do think that both will introduce complete new attack vector. Complete new attack vector. Why? Because if you're, if you enable, if you're a vp engineer, okay, vp software engineer. Now, jo Joe wakes up tomorrow and enabled a copilot on your GitHub repo. Who knows that you enforce two reviewers on the pull request? Who knows that your code changes are now growing exponentially, growing exponentially? And maybe you will not introduce foreign abilities, but you will introduce major material changes to the architecture and no one will know that, because the Gen AI, or, sorry, copilot, decided to use a different serialization framework. And new serialization framework will open you to a completely new attack and your SaaS tool will do literally zero because there is no SQL injection in this serialization framework. But it's a material change and no one knows about it. So what I'm trying to say again, to make it shorter, it will open in the next, not three to five years, in the next year, completely new attack vector.
Speaker 2:We will see totally different types of attacks and you need to automate everything. Automate everything Without the automation, without without the automation, without the. And when I say automation, it's not just yes, you know, workflow in an orchestration tool, it's actually, sorry, broken record. It's actually understanding your software architecture, the changes of your software architecture early in the development lifecycle and then trigger a contextual process. It can be a contextual threat model or a pen test or a security review, but also a training, because if Joe did the same mistake again and again and again five times, I don't need to wait for the you know the one year training which is so boring and everyone press next, next, next, next, next, just to comply with PCI or whatever. I need to train. I need to trigger a contextual training to reduce the risk before delivering to production to production.
Speaker 1:Yeah, yeah, absolutely. We're moving into a really fascinating time where, you know, new threats are going to be creating new attack vectors and it'll be really interesting. So I'll definitely have to have you back on, you know, sometime in 2025, and we'll talk about the new ones that are coming up. But you know, idan, unfortunately we're at the end of our time here, but you know, I really enjoyed our conversation.
Speaker 2:Likewise, likewise. Thank you for having me, joe. It was an interesting conversation. I would love to talk more in 2025, when we see the new attacks that are raising.
Speaker 1:Yeah, yeah, absolutely. Well, you know, Idan, before I let you go, how about you tell my audience where they could find you if they wanted to connect with you and where they could find your company if they wanted to learn more? Sure.
Speaker 2:So LinkedIn, Twitter, you know, or Xcom, just add me and send me a message, or just go to apiro A-P-I-I-R. Apirocom and reach out.
Speaker 1:Awesome. Well, thanks everyone. I hope you enjoyed this episode.
