Hello and welcome to our webinar. I'm Miriam Brand. I'm Director of Product Marketing at Akeyless. I'm very pleased to introduce Fami Khadiri. He's the Customer Success Director at Akeyless and he will be speaking on Secrets at Risk. Why legacy secrets management is failing your security strategy. So some housekeeping items before we start. If you have questions at any point in the presentation, please enter them in the question box, and we will address them in the q and a section at the end of the talk. If we don't have time for your question, don't worry. We will get back to you with an answer by email. Also, this webinar is recorded and you will automatically all registrants will automatically get a link to the on demand webinar, when it is finished and processed. So with no further ado, Tommy, please take it away. Sounds great. Miriam, can you hear me okay? Am I coming through? Yes. Hear you fine. Alright. Fantastic. Hello and good afternoon, everyone. My name is Fahmy Kadiri. I'm, director of customer success here at Akeyless. And, the topic today is gonna be secrets at risk and why legacy secrets management is failing, your security strategy. So, let's start by making sure we're all on the same page here and define what it is that we mean when we talk about secrets. So, think of secrets as, think of them as digital keys to the kingdom. Right? And if they fall into the wrong hands, it could lead to all sorts of trouble. It's like having the keys to your entire business, just laying around if it's not safely protected. And so in today's, digital world, secrets are used pretty much in every application, every service, every interaction, and this brings us to the proliferation of secrets. Right? And so think about how much more interconnected everything is now compared to even a decade ago. Right? So, you know, we've got cloud services, microservices, all of these different, applications that need to communicate securely. Each one of them comes with its own set of secrets. So the sheer volume of secrets that, we have to manage is, has exploded. And it's not just a few passwords anymore. It's thousands, maybe even millions. And and this is where the distinction between human and nonhuman identities becomes crucial. As humans, we use, usernames username and passwords, but increasingly, you know, you have machines, applications, services that all need to talk to one another. And so these nonhuman identities rely on things like API keys, encryption keys, and certificates. And the number of these nonhuman identities is growing exponentially. So for every one human identity, you have over forty five times more nonhuman identities, under the surface. So you've got this massive increase in secrets, and, what what happens is if these secrets aren't managed properly, that's where you get into, business risk and where risk comes in. Unmanaged secrets create huge vulnerabilities. So if you don't know where your secrets are, who has access to those secrets, and, when they were last rotated, you know, then, you can have a massive attack surface, and it's like having countless of, doors unlocked, in your digital infrastructure, and the consequences can be severe. So, you know, this is why it's important to understand the evolution of secrets management and and help us, paint a clear picture of why these old ways of handling secrets just, isn't cutting it anymore, especially with the way technology is moving so fast. You know, it's kind of amazing how much things have changed, just in the last decade, even, when it comes to this. So in the nineteen nineties, picture this. The standard practice was, writing stuff down in plain text, maybe sending it in, documents or even locking it away in a filing cabinet or, in some cases, physical safes. And most businesses didn't really see security as a central concern, you know, that it is now, especially when it came to all of those internal passwords and keys. It was more of a necessary evil kind of thing. If you have regulation forcing you to do it, you did. Otherwise, it wasn't really top of mind. And so, you know, security was more of a cost center. And, the very first password manager called Password Safe was released in nineteen ninety seven for Windows ninety five. And, you know, the crucial thing about it was that it actually used encryption, which means that for the first time, you know, you had you had the ability to securely store and and manage your passwords. And so gradually over, you know, the next few years, we started to see more and more personal and, you know, personal security tools, focusing on encryption and protecting sensitive data. But fast forward to the two thousands and the twenty tens, you know, we see this massive shift, in how businesses approach, security for their secrets, both in human and, nonhuman identities. And the big wake up call for us was, you know, the the the growing understanding of, what the financial risks and implications are, as it relates to, data breaches, resulting from compromised credentials. And we had some really high profile breaches. The t j x company hacked in in two thousand three, ended up costing them around two hundred and sixty million dollars, so more than a quarter of a billion dollars as a result of, exposed customer data. And it wasn't just about the money. So, it it was the realization that the fallout from the compromised credentials wasn't, you know, not just a technical problem. It was more of a business risk now with real financial consequences. And so you had at the backs of that, you had regulations come in making, executive personnel more accountable for, data security, and the proper handling of sensitive data. Plus, you have the average cost of, data breaches, you know, steadily climbing. And so all of this financial pressure forced the organizations to get serious about how they manage all of their sensitive information. And that's when we started seeing the rise of on premise vaulting solutions. So in twenty fifteen, HashiCorp Vault, comes onto the scene, and it was a pretty big deal in the world of secrets. And what made it, different from anything else that came before was that, it helped to modernize how, we thought about, secrets, specifically, you know, handling, the complexities of secrets management for both human and not nonhuman, nonhuman identities. So while it was, you know, predominantly an on premise type, solution, it offered key advantages around centralizing, controls for secrets management combined with, an API driven approach. And so, basically, it meant that organizations can start to automate more of their secrets management workflows. But fast forward to the twenty twenties, and we start to see this massive growth in cloud and multi cloud sprawl. You know, the pandemic, lockdown in twenty twenty through twenty twenty one accelerated this. Systems grew more and more complicated, and the applications, that we use, became more interconnected. So so now while, you know, we've improved security in some ways, we've also increased the operational overhead and and complexity. So, really, what we've done is we've traded one set of problems related to manually managing secrets for another set of problems related to managing complex on premise, systems. And, you know, now you're and and then with the adoption of, cloud and multi cloud, what you have is your infrastructure isn't just sitting in your data center anymore. It's distributed. It's, constantly changing, and it's, you know, available across multiple pro providers. And so the traditional on premise, vaults, you know, they weren't designed for this. They were they were designed for more static and and, static internal and cloud networks, not the dynamic environment that we have now. And so in the twenty twenties, the driving force is now speed and agility, you know, the speed of digital transformations. Businesses needed to be able to move quickly to roll out, new features and services and to leverage, the cloud, to stay competitive. And so what are some of the legacy pitfalls of, like or what what are some of the pitfalls of those legacy solutions? At a high level, it, boils down to scalability, cost, and, developer friction. So from a scalability standpoint, these vaults were built they were built for data centers, not for dynamic cloud environments. And so as we expanded globally and adopted multi cloud providers, the systems just couldn't keep up, and this leads to delays, blind spots, inconsistencies in security. And then from a cost standpoint, you know, running secrets infrastructure takes more than just software. It's people, it's hardware, it's, security audits, it's constant patching. And so as cloud native services scale, you know, the legacy secrets management, tools are, you know, they they look extremely wasteful. And then finally, from a developer friction standpoint, developers are, you know, the engines of our innovation. So when secret infrastructure becomes a blocker, business philosophy suffers. And, it's not just annoying, it's also costly. So let's dig into a little bit about the, around the scalability, scalability challenges. So when you look at, traditional vaults, because they were designed for, on premise or, you know, static, in environments, they have a hard time scaling to adapt to growth. So imagine you are a retailer, and as a retailer, you have, times of the season that are, you know, that, you know, that where you have heavy loads. So you scale up your applications, and then other times of the season, you scale down the the applications you have. But because legacy solutions aren't designed for this, you know, this type of elastic environment, what you'd have to do is you'd have to overprovision. And so it it it it becomes wasteful from that standpoint. Additionally, because they're designed for for static environments, when you get into multi cloud, you now have to reproduce these systems in other in other environments. And now we have to think about how are you going to sync secrets from one vault to, the next vault. How do you rotate them and keep them updated? And so now we have, you know, enclaves of secrets, in in in in different environments that aren't necessarily, synchronized with, with, one another. And this contributes to the scalability challenges, regarding, legacy, legacy systems. So from a, cost standpoint, you know, before we get into the the technical limitations of legacy systems, this is important to understand, you know, what's the full weight of, resource overhead tied to those, systems. You know, these older on premise solutions come with a heavy and, underestimated financial, burden. You know, they require specialized people to operate. They create significant drag, on, you know, your day to day operations. You know, they demand inefficient infrastructure investment, that, you know, simply don't align with the modern cloud native, environments. So from a people cost, standpoint, you know, managing legacy secrets infrastructure is labor intensive and expensive, requires specialized skill sets, not necessarily always easy to find. You need, dedicated teams. The expertise is very niche. And, and so often it's it's, costly, hard to find, and, hard to retain, those those type of roles. And when you do have those roles open, they often stay open for, considerable amount of time. From an operational standpoint, these legacy systems introduce, other efficiencies that slow down the team. So think about, maintenance, upgrades, compliance requirements or tasks that eat into the, engineering hours. You know, you're spending a lot of time managing these platforms as opposed to you using the, the, platforms. And then we've already covered the infrastructure waste, component of it. You know, if you need to scale up, you're gonna need to over provision your your environment so that it's, it's able to handle those loads even in, you know, times of the year where it's it's not needed. Alright. And so then we get into the, developer, friction, effort and and friction. Legacy secrets management solutions, you know, it's it's not just a burden on security team teams, it also slows down, developers, especially when, they were never designed for fast moving cloud native, development. And so as a result, they introduce obstacles, at every stage of the software development cycle. And so, you know, from an innovation standpoint, developers can face long delays getting access to secrets, due to manual approval processes, complex integrations with outdated systems, and then provisioning new new credentials can be slow and and require workarounds or or custom, custom code, in order in order to handle. Then you have, the operations burnout. And so every hour spent manually rotating a secret or troubleshooting failures is an hour you're not spending building, your your, you know, software or code. And this takes a toll. It takes a toll on productivity, on morale, on retention. You know, developers didn't sign up to babysit secrets management and and vaults, and organizations are paying the price in slower output and and and rising turnover. And so, you know, one of the common things that you see in these type of environments is, the workarounds. Right? So the the intended so intended solution doesn't really solve the problem the developer's facing, and therefore, they they have to resort to other workarounds. Maybe, keeping secrets in other type of environments that aren't sanctioned. You you know, and, and so they bypass best practices. They bypass the controls that that were put in place in order to be able to do to do their jobs effectively. And so that creates, opportunities for increased the tax surface and credential, compromise, and ultimately either breaches or, you know, compliance, violations. So, what is the solution? So there's a better path forward. We wanna say goodbye to secrets. You know, this whole concept of secretless or, ephemeral. And so, you know, when you embrace, ephemeral credentials, when you embrace workload identity and developer first approach, you can start to eliminate the friction points, we discussed earlier. You can start to optimize costs, and also, have the ability to to scale, accordingly. So, what are ephemeral credentials? So, they essentially, allow us to create secrets on demand as needed. They, have a predetermined amount of time that they last for, and then they auto expire. So you don't need to waste time, trying to figure out, you know, is the secret still out there? Who's using it? Has it been rotated? All of those problems go away because, it's ephemeral. It spins up as as it's needed, and when it's no longer needed, it, it terminates and can no longer be used. And if you need another secret, you just create it on demand, you know, sort of a a credential or secrets factory, if you will. And then with workload identities, this brings cloud native principles to, authentication. So instead of relying on stored secrets or hard coded secrets, machines can prove who they are using verifiable identity signals. And in, environments where you don't have, you know, where where cloud identity, isn't a viable option, then you have other other mechanisms, to, be able to provide identity to to those systems that are are not tied to, the cloud environments. And so, from a developer first standpoint, it creates the, a an environment that is fast, that is simple, security access, without friction. You know, it doesn't require constant maintenance and and, management. And, you know, this is the approach that is is needed for, you know, kind of where we're going today in terms of, you know, secretless, cloud native, and so on. So one of the things that, we looked at internally here, you know, as we work with customers, you know, we meet we meet clients at various stages of their security journey. And so we put together a, modern solutions framework, for secrets management. And, you know, if you do request this, at the end of this presentation, we'd be happy to send it to you. Essentially, it goes through four four stages. The first stage is, you know, kind of ad hoc, exposed secrets. There's a questionnaire that that, walks you through to see which stage, you're at, and then recommendations for what you can do to move on to to the next stage. Second stage is siloed vaulting. So this is your traditional vaults for your traditional data centers. That may be sufficient for for for for what you need. But, again, depending on where your business is going, whether you need to be in, not just a single cloud environment, but multi cloud or even hybrid cloud, then you can start to look at, other approaches for effectively managing secrets across those those different, environments. And then the third, stage of that is, unified and, and, automated, which is, you know, the, recommended approach is, you know, because you have many different, components that don't necessarily talk to one another. And, rather than managing them sep separately, you can manage all of it in a in a in a single unified environment. And then finally, we go into the secret list and zero knowledge. So this is where you no longer rely on, static secrets. You're using, federated authentication. You're using dynamic secrets. You're consistently rotating secrets. So, you know, if you don't have any, long lived credentials to manage, then you're you're effectively creating a secret list and and zero knowledge. You're operating in that type of framework. So, let's talk about, Akeyless. Right? That's the solution that we, are, known for, which is our unified secrets management and, a machine identity platform. So from a unified standpoint, it's one system for all types of environments. It doesn't matter whether you're on premise or hybrid, multi cloud, sync single cloud. It doesn't matter whether you have infrastructure or not. You know, we can, essentially deploy our service to meet all those, all of those requirements, through our stateless Docker gateway. So, essentially, the gateway becomes a proxy to our global SaaS, and you can deploy the gateway anywhere you need secrets. So if you need a secret on prem, you deploy an Akeyless gateway there. If you need a secret in the cloud, you deploy gateway there. And the really nice thing is that all of those gateways talk to one another by default. Of course, you can add access controls and and restrictions to to, segregate and isolate, environments as needed, but you no longer need to worry about, you know, how do I sync my secrets? How do I get a secret from the cloud to a workload on premise. And then when you need to migrate that that that workload from on premise to to cloud, there's nothing extra that that you need to do because, the the environment is unified or sequence management's unified across the board. With regards to, zero knowledge, security, one of the key differentiators that Akeyless has is what we call our distributed fragments cryptography. So, essentially, with distributed, fragments cryptography, you are operating in an environment where not you know, the vendor, Akeyless, in this in this case, doesn't know your secrets. Right? So, kind of the best of both worlds. You have, the ability to use a SaaS solution that allows you to manage, manage your your secrets without having to dedicate time and resources and infrastructure to, while at the same time, the vendor can't access your your your secrets. And then, all of the capabilities around what is required for modern, solutions, you know, things like dynamic secrets, just in time access, integration with cloud native tools, you know, you know, disaster recovery. It's all built into the platform. So rather than spending time, managing a secret, you're you know, from day one, you're, yeah, you utilizing the platform, with all of those capabilities built in. So that's, that's pretty much it for, for my presentation today. I'd like to stop here and, open it up to q and a if anyone has questions. So thank you, Fahmy. That was a great presentation. And I do have a few questions that have come in. Please, if you have questions, you can still enter them in the question box. So, here sorry about that. So do you see any risks with using a femoral credentials like traceability issues for incident response? That's a good question. You know, traceability is important for security, for incident response. And, you know, while, ephemeral and dynamic secrets generated by Akeyless are short lived by design in order to minimize risk, you know, we ensure full traceability through, you know, our our our, auditing system as an example. So, you're able to trace every single trans transaction, every item is logged. And even those dynamic secrets that are generated are tied to who generated them. Right? So whether it's a human, individual or if it's a if it's if it's a nonhuman identity that's that's generating those, those dynamic secrets. So, ultimately, there's no, issue with traceability, because all of the transactions across the boards are are are logged and audited, and there's a centralized record for all of those, transactions. Additionally, while we log it ourselves in our platform and make it available for the customer, we also have the ability to log forward. Right? So if you if you have an environment where you need to ingest, those sig signals in your, you know, specific tools, then, we we can send you the, both the log data, and, you know, metrics, you know, around, you know, things like, you know, Grafana and Prometheus, type metrics that you can ingest as well. So so if you share a an ephemeral credential with, let's say, a third party, provider, you will know if and when they used it. Is that right? Correct. Yeah. So you do have access roles. You have RBAC. We tie into things like SAML, you know, if you're using Okta or Azure AD. So you can tie that in to what your third party provider is using. Right? And so based on that, you can grant them scope down, custom secrets, that they can generate only for the specific systems that they're allowed to access. And all of that, again, is audited and tracked so you know exactly who requested it and and where that secret is going and, how long it's used for and so on. Okay. And another question that just came in. If it's so seamless to provision and deprov clients using ephemeral accounts and so on, why are the licensing most of the time so restrictive? Prices in HashiCorp, Contra, etcetera, are insanely expensive. So can you speak to that, Fami? Speaking about, well, I can't really speak to pricing from other vendors. You know, I I I I think what we're doing is we have a legacy approach that we're trying to adapt to, modern environments. And so there are You mean you mean in HashiCorp and, like, you mean in in this in those price pricing models? Yeah. Yeah. From an from an overall standpoint. And that's what's causing the pricing to be crazy in those, in the in those other, sequence managers? I mean, that's that's what I'm hearing, but, you know, I don't have any direct, you know, experience with those other with with with those other vendors, so I I really can't speak. I mean Authoritatively This person who's asking, I won't say your name because I'm assuming you wanna stay anonymous, but, this person who's asking seems to have some experience, but who knows? K. Yeah. Okay. So That's a great question. Yeah. Let's see. I believe we have another question here. How do you deal with developers hard coding credentials into containers or CI pipelines before adopting a platform like this? Yeah. So, there's a couple of things you can do. So if you know, if you know kind of your workflow and and how secrets are are being used, you can, adopt a platform, you know, you know, train may maybe a smaller subset of your of of your developers and start to onboard them onto onto the new system. Another approach is you can look at detecting secrets. Right? So you can scan for where those secrets are used and who's using them, and then you could use that as kind of your baseline to understand where your secrets are being used or hard coded in a way that they shouldn't be. And then you start to develop a plan for how to get those secrets off of, you know, hard coded, type environments. I think at the end of the day, developers want something easy and they don't want complexity. Right? So if you can give them something that is easier than what they're doing, you know, you don't have to hard code. Why would you hard code if all if if you can give them access in a path and they can just put put the path to to the secret and they can request it on demand? That's much easier than than, you know, having to hard code secrets. So I think there's part of it is understanding where your secrets are. Another part part of it is, educating and and showing them a better way. And I think let's try and reason, another question that's come in here. What would be your red flags during a secret audit that suggests the current system is a liability? What would be my red flag to suggest the current system is a liability? During during an audit. Yeah. Yeah. So, a couple of things. One, is, is your is your environment you know, again, there's there there there's different audit, requirements. Right? So if you are a retailer, if you have to be compliant to PCI, you know, compliant to PCI, you know, as an example, there there there are different considerations there around, segregating net networks and so on. There's also the risk of, secret sprawl. Right? So do you know where your secrets are? Do you know how how secrets are are heart are are are, you know, set set up in your environment? For example, I can think of one one, you know, prospect I was speaking to last year, who has a multimillion dollar application, and they're hard coding their secrets into that application. Right? That that that's an immediate red flag. Another red flag is, if you have if you don't know where your secrets are. Right? So imagine, here here's a real real life, scenario. I was, speaking with a security auditor, you know, pen tester. And one of the most successful engagements that they've had from their organization was a pen test that they've done where, they were able to completely breach that that, that environment through a credential that they found that was available since twenty twenty. You know, this this conversation happened last year. So that credential was sitting in the customer's environment for four years, and no one knew what the service account was used for, it's difficult to try to remove a a a a a legacy account or or cred if you don't have any way to tell whether it's being used or not, whether it's gonna break some something or not. So the safe thing to do is to just leave it, in, you know, in in that type of framework. But with a solution like Akeyless as an example, you can see you can audit and see when a secret was first created, when it was last used, and when it was updated. Right? So you can very easily see, you know, I have this this many secrets out there with these type of permissions that have not been used for the last x days or x months. Right? And then very quickly start to remove those out of out of your environment. So from a security risk standpoint, I would say that's probably your biggest red flag is having, secrets that are, you know, you know, sprawled and, no one knows what they're used for or what permissions they have. Okay. Great. Thanks. So we're a little over time, so thank you everyone for sticking with us. And if we didn't get you to your question, we will be in touch after the talk. Again, you will all receive links to the on demand webinar as soon as it's available. So thank you again, and thank you so much, Fami, for for this really, really, great talk. My pleasure. Thanks, everyone. Take care.