Welcome, everyone, to, to our presentation on secrets in finance of risk risk compliance gaps and what to do now. I'm Miriam Brand, and I'm going to take you through a, a a, series of we're gonna look at kind of the credential breaches in the search of machine identities. We're look going to look at a breach and what it means for finance. So the breach we're gonna be looking at is actually, a relevant breach for, financial institutions. We're gonna talk about why it's important for financial institutions in particular, what this means for regulations, and then what the steps you need to take in order to make sure that you are safe. Now, before we dive into the presentation, some house, some housekeeping issues. If you have a question at any point to the presentation, please put it in the q and a box, and we will address them at the end of the presentation. If we don't get to your question at the end of the presentation, we will be in touch with you. Also, if you have a specific a question about a specific regulation, I might want to look it up and not just kind of wing it. So in that case, I will look I will delve into it and give you a a more more extensive explanation later. So please feel free to ask whatever you like, and, and we will we will address it in one way or another. So let's, let's begin. Okay. So as you probably know, credentialed breaches have been certain. They are but, but what is their source? Where where are we getting all these? What what's happening with these breaches? We actually see the number one cause of breaches is compromised identities and credentials. Now those identities, we're used to thinking in terms of human identities. I'm gonna be talking about that in a little in in in a little bit. But, really, a lot of these breaches and the breaches that you see on the screen here are all happening because of breach machine identities. K? Machines can be workloads and applications. They can be applications. They can be databases. They can be any sort of nonhuman entity. And these hacked machine identities, account for eighty five percent of identity related breaches. And the average cost of a financial services breach is nine point five million dollars. That's the average cost. And as we can see with the Bank of America and the, Department of the Treasury, breaches here at the end, there's no one who's really safe. Now why have we been seeing this rise of credential breaches and not just credential breaches, but machine credential breaches? Part of this is because we just have so many more machine identities than we used to have. Again, we're used to thinking of human users. Right? Engineers, employees, all the people who have to access things on a daily basis. The problem is machines have to access things second by second, not just on a daily basis, and we have more and more of them. We have, containers, microservices, servers, databases, virtual machines. Even automated processes can each be a machine identity, and now we have AI agents, which are causing a whole other slew of problems. And so at this point, we have at least forty five machine identities per human in your average organization. There's been a rise of two hundred forty percent year over year. This is rising number of identities in two in two thousand twenty three. One year, and it's only going up from there. Now I want to just remind you, so when we need to authenticate or authorize these identities, what we use are what we call secrets. So those include things like, SSH certificates, database credentials, regular certificates, API keys, passwords, SSH keys. Okay? Now the the Akeyless heel with these secrets are hard coded secrets. Secrets that are hardcoded either into, into, you know, encode scripts or today into AI agents. That's something that we also need to be aware of, and we need to we need to start, combating. Long lived API keys, orphan credentials. These are easy targets for hackers. Hackers know it. This is what they target. You'll frequently hear of hacks that start with an API key or let's say an AWS key, let's say a a cloud key. Those are frequently they're not rotated as often as they should be, and they're long lived and they can grab them or hard coded secrets to type that leak in in, when we see in in in encoder config or config files. Now secrets power financial sectors also. Right? So you have API keys for payment gateways. You have database passwords for financial records, TLS keys for customer encryption, SSH keys for admin access. Now these secrets, if if a hacker gets even one of them, they're frequently getting the keys to kingdom. They have a way to get to all your customer data or your financial data. And that's why these are so, are so important to secure. Let's take a look at at what happened to Bank of America. Not really the Bank of America. What happened to the third party that then affected Bank of America? And that shows just how how careful we need to be with secrets. Okay? So in twenty twenty three, okay, there was the initial compromise. What happened? And you can see on the screen I'm I'm gonna go over it. You don't have to read all the script. Right? So hackers accessed a third party service provider, IMS, and they did it through compromised credentials and open SSH ports. Now once they got in there, they were able to exfiltrate the personal information of over six million individuals, and IMS had to inform Bank of America, of course. And then Bank of America had to notify their fifty seven thousand affected customers. And they in in terms of their mitigation, they said, well, here's a membership to Experian, so it'll protect you from identity theft. However, you have the feeling where, like, okay. You're closing the window after they got in through the barn door. Right? You let them in through this this third party access. The reason is because, frequently, third parties are given privileged access and no one closes it. Okay? This is something we're going to discuss in a bit. What was the result you had? Personal information over six million individuals stolen and for Bank of America, the personal information of over fifty seven thousand of their customers. Okay? So you have that exposed, and then you have the risk of further identity theft and fraud because if you haven't mitigated, mitigated it well enough, some of these keys, some of these things may be open. You also have stories where they're not just getting customer data. They're getting other keys that they can lead them to even more and more information. So what do we learn from this? Okay. We learn that you need to implement ephemeral access. What do we make what do I mean by ephemeral access? That third party should never have had standing access to anything at Bank of America. Right? All they should have had was a window that closed automatically, in which case, even if the hacker had breached IMS, they would not have been able to breach or have any access to Bank of America. There should be zero standing privileges, particularly when dealing with third parties. Okay? And, also and and I don't have this here, but another thing is encryption. All of this data should have been encrypted. Why were they able to decrypt all this personal information? Perhaps they also accessed an encryption key. That also must be very, very secured. Right? So, what do we need to do? We need to do robust credential data encryption. We have to have access controls. They have to be ephemeral. Right? They have to close after a certain amount of time, and we have to continuously monitor access. Now it's not a surprise that that's exactly what regulations want us to do. Right? If we're looking at what's going on in regulations, the regulations are getting more specific in terms of, hey. We're not just talking about human access. We're talking about machine access. Now American regulations tend to speak in very broad terms. Some of the Europe more your, recent European regulations are actually mentioning sequence management more specifically because they're coming becoming more and more aware of this as an issue. So here we have, some just an overview of some of the regulations. PCI DSS requires secure storage of your system credentials, encryption key management. Now this is very this is very important. And encrypt the encryption key management has a special status because if someone has your encryption key and gets the data, they can decrypt it. If they don't have the encryption key, even if they have the data, at least you can say, well, it's all encrypted data, so it's gobbledygook. Now you still have to inform. You still have to notify, but it's very important. So for example, GLBA requires both encryption and effective key key management in terms of secrets. FTC safeguards actually counts a compromised key as unencrypted data. In other words, if you are there, FTC requires notification, within, I believe, thirty days for unencrypted data, Also for compromised encryption key. From a point the point of the OEFTC, if your encryption key was was compromised, it is as if you leaked decrypted data. NYDFS, as, requires you to limit and monitor privileged accounts. Now that's not just human privileged accounts. Right? And we'd be wrong to consider it just humans. It's any sort of privileged account. Remember all the different types of machines that I talked about earlier. K? SOX, GLBA, SCC, they all mandate different access controls. Right? Now, also, something that we see across regulations and I because it's so frequent in regulations, I didn't really mention it in in this particular slide, is the require requirement for a plan for mitigation after a hack. Right? Let's say, hey. You did everything you could. There was a breach, though. What do you do the day the second half? Right? What do you do to close access? Of course, you have to notify, and that tracking is part of that. You have notification requirements. But, also, what do you do to stop to to to to stop this gap in your in your security? So what do regulators want to see? What what's going to keep your data secure when we're talking about machine identities and machine secrets? First, we're talking about access control. Who has access when for how long? Okay? You need your the idea is that you know this, that you're controlling this, and that no one has more access than they need to have. The other is encryption. All data should be encrypted encrypted in in, both, you know, in transit as in transit as well. Right? So, at rest and in transit. Auditing and tracking, you need to be tracking everything that's going on with your secrets, and we'll talk about that a little later. Mitigation and recovery. You need to have a plan, but not just you need to have a plan. You have to have something that could help you automatically mitigate a breach if it happens. Let's go into each one of these categories. Okay. Access control. You want to enforce least privilege by design. So you want to have just in time secrets on demand. What does that mean? A just in time secret, we we we kind of use it as, we when you say just in time secret, we kind of use it as a shorthand to say, oh, you get it because it sounds like, oh, we just get it right when we need it. It isn't just you get it right when we need it. Really, we're talking about usually temporary secrets. What you want is a secret that the only is only provided when needed and expires when it's not needed. So for example, if you have a third party, they need access to your database. They need access to your database. They don't need access to your database for the next month. The truth is you should have it set up so every time they need access to your database, their identity is checked. Do they still need this access? And then they get the access. Then they get the secret and the secret expires. That is the ideal way to set it up, and that's how you should be setting. RBAC and ABAC, so a a role based and and, an attribute based access automated policies. Right? You want to say, hey. You know, so I, for example, in my company, I have no access to development environments. Why should I? Right? Based on my role. Okay? So so everyone has a role, but also that role is going to be again, it's tied into the identity. And and that goes for for machines as well. And when now that we have AI agents, we have to start talking about the role of an AI agent. What does this AI agent belong to? You're not gonna give it the keys to the castle. If the AI agent is only supposed to do, you know, work on customer support, it only has access to those systems. Right? And it can't create another agent that has access to different systems. Right? Those are things that we need to control. Now for that identity based temporary access, we need to integrate with IAM and IDP systems. Right? So we want to to be able to check against these identity providers. Is this someone who needs access and then give them the temporary access. And, again, of course, we're tracking all of this. Now encryption. We wanna protect our data at all times. We wanna encrypt our secrets both in transit and at rest. We wanna secure the encryption key. So, for example, at a keyless or we should say, if you use a keyless, you are actually splitting the encryption key across environments with our patented distributed fragments cryptography. So the encryption key never exists in its entirety. It is nearly impossible to hack. We never say impossible to hack, but it's nearly impossible to hack. It's every fragment's rotated. It's very, very difficult. You want to secure your encryption key as much as possible. The encryption key really is the key to your task. Zero knowledge. You wanna make sure that even the secret platform you use should not be able to read your data or your secrets. Remember that these are very important. You don't want a malicious actor to have access. As much as possible, you want to keep control. Auditing and tracking, you want to, prove compliance, of course, but you also wanna detect threats. So on the one hand, you need to audit and track. Otherwise, you can't comply with all these regulations. That's that's a basic. Right? But you also wanna detect threats. You want something that's going to notify you. Right? You want logs of every secret access and modification. You want a record of who access what, when, and from where. Right? And that, again, secret access, you want to know. And if someone shared, like, if someone has their their or if you're using a system like Akeyless, you can do a temporary share of a secret to someone. Like, they have an hour to use it. Right? And you wanna know, did they use it? What happened with it? Like, you need to know what what they did with that with that secret with their temporary access. Right? Now you can integrate with SIM for for analysis for sort for the, for the mid for the mitigation plan afterwards. You wanna you wanna have integration with your systems, between and your and your sequence management. Mitigation and recovery. This is important, and you can build it in to your sequence management. This is important. There are steps that you can only take when you you wanna do an incident response plan. These are things that are company wide, but there are things you can build in to your sequence management that will make your life in terms of mitigation so so much easier. Okay? You want to have, again, just in time temporary sequence with built in expiration. That means that if one of these, if a just in time secret somehow leaks, goes to a person it shouldn't have gone to, After it's expired, it's useless. It's literally useless. Nothing has been now, of course, you wanna make sure that nothing happened, whatever, but they had a very limited time when they could have used that secret. You wanna automate credential rotation across the infrastructure. This is super important. In a case if credentials are leaked, you wanna be able to rotate them as quickly as possible so they're no longer useful. You wanna revoke secrets instantly upon compromise that that requires central management and requires the ability to automatically revoke, and you wanna trigger, of course, predefined recovery workflows and alert security tools. You wanna have different notifications, you want different alerts, and, of course, this is part of your overall instant instant response plan. Okay. So what's the solution? How do you do this? You do it with effective sequence management. Now, of course, you know, I'm I'm a little biased here. We're talking about Akeyless here, but what you need to expect from a sequence management is what you do is you have automated processes and you draw the secrets when they are needed from sequence management. Your sequence management is a central repository. You draw the secrets and inject them only when needed at in the best and and then you use them for access to different to different third party services, see your databases, applications, etcetera. Okay? And it should be integrated with your entire pipeline, everything that your developers need to do. It should be very easy to draw and inject secrets. It should be easy to rotate them. It should be easy to get temporary secrets. That's very important because, again, you want security to be simple and easy. Otherwise, it won't be used. If it's not used, you're not secure. So what is your secrets management checklist? What do you need to do when you're saying, okay. This is what I need to make sure happens. You wanna make sure all your machine credentials are stored centrally. You wanna make sure your secrets are encrypted at rest and in transit. You want role based and time based access controls. Again, role based, what are they? And time based, not just I mean, there's also attribute based, which you should also have, but time based in terms of it should yeah. Window should be closing. Right? You don't have a window that stays open. It's again, especially with third parties, but with anyone. You wanna have rotation and revocation workflows in place, and you wanna make sure all access, all secret access, all machine access is logged and reviewable. Now, before we get to the questions, of course, I wanna talk about Akeyless. Akeyless is secrets management that is a deal for regulated financial environments. With Akhiles, you can secure all your machine secrets across cloud and hybrid environments. And that means that using Akhiles and using our technology, you're actually able to rotate secrets in legacy systems, in your on prem legacy systems. We've had customers that switched to us from other leading secrets managers who were not able to do it without a complex workaround. They started using Akeyless, and they started rotating all of their secrets to their on prem machines, on prem servers. You can enforce our back role based access control and ABAC, attribute based access control. You can have temporary just in time credentials across the board and sequence authentication. Sequence authentication is perfect because it ties that temporary access to your machine identity. So it makes sure it's integrated into your machine identity. It identifies it according to your all your IAM, your IDP, however whatever you're using for your federation of your of machine identities. And through that, it creates a just in time secret. There's no secret to hack because it's only getting secrets that then simply essentially disappear into the ether. They're they they they're simply automatically revoked. Your automatic key and secret rotation at whatever interval you set, full audit logs and SIM integration, and zero trust, zero knowledge architecture. As I mentioned before, we have a special technology in terms of how we encrypt your secrets. It is based on standards. It's it's FIPS one forty two certified, so it's based on encryption standards. But it essentially splits your encryption key across different environments, and you have a piece of it in your environment. So a keyless also cannot decrypt your secrets, and that's very important. Only you can decrypt your secrets, and it also creates a tremendous tremendously secure layer of security around your encryption key, making it nearly unhackable. And you have full support for international regulations and standards. I invite you to visit our trust center and see all our, you know, certifications, etcetera. We're built for security and we're designed for simplicity. Again, simple security is not security because it won't be used. Okay? You want to have, we have hybrid SaaS deployment. There's no infrastructure to manage. What do I mean by hybrid SaaS? If you look on the on the right here, you'll see this is this is very this is a very kind of abstract, image. You have Akeyless is in, in is the SAS, but the Akeyless gateway sits in your environment. So there's a a a a light stateless gateway. It sits in your a light, it sits in your environment. It handles things like caching, and it also makes sure it it makes sure that Akeyless can't reach into your environment. The gateway is only outbound. You can reach into Akeyless for the secret, and it keeps you secure. And, again, that's where you keep your piece of the encryption key so that Akeyless cannot decrypt your secret. We work across on prem, AWS, Azure, GCP. We integrate with your existing IAM, CICD, and cloud stack. We've been proven in large financial services and fintech environments. And, again, we have patented FIPS one forty two certified DFC encryption to ensure zero knowledge. And, so I went through that more quickly than I expected to. And now I will be happy to take your questions. So, again, please, please put that into your into the, q and a. Let me let me stop my share. Hold on to the moment. Stop share. Okay. Alright. So, so, please, as I as I answer some I see there are a couple questions that have come in, and feel free to add more as I answer them. If I don't have time, I will, I will be sure to be in touch with you and address them after after the talk. So, let's see. So one question that came in here is how do regulations how do regulators how do, let's see. How how do regulators view the use of cloud based secrets managers? Are they considered compliant for storing encryption keys or credentials? Okay. I'm gonna repeat that. How do regulators view the use of cloud based secrets managers? Are they considered compliant for storing encryption keys or credentials? Okay. I assume that what you're talking about is a CSP, a cloud service provider. Now the problem with cloud service providers is that a lot of regulators want you to keep your encryption key at out, apart from your data. And if your data is in the cloud and your encryption in the cloud, you need it as you know, give give, give the cloud service provider your encryption key, and it is not in fact separate from the data. That's a big problem for regulators with CSPs, with cloud service providers. In terms of SaaS providers, that's one of the reasons why we use a gateway architecture. So it would we we are fine. We're we are, using a SaaS like specifically like Akeyless where it's a hybrid SaaS where you you have a gateway in your environment. That in general is has been fine for regulators. In terms of cloud service providers, it's the the problem becomes when you have the encryption key together with your data. I see I have one more question here. Just a second. Let me see. We already use a PAM tool. What's the added value of a separate secrets management solution? Okay. So PAM tools are created for human users. They've been used for many years. They're they're designed for human users. Human users join, not they don't join that quickly, and they stay around for a while. You're not usually going to fire, a hundred thousands of people in a minute and you're not gonna fire a thousand people in a minute and hire new a a thousand new people in a minute. That can happen with machines, though. Because when we're talking about machines, we're including things like a Kubernetes cluster. Right? You can spin it up and then you can delete it. So those the the identities themselves are what we call ephemeral. They're they're they're they're temporary identities. Right? So these temporary identities, mean that if you're using a secrets manager, you have to have something that in an automated way can handle thousands of identities a day and thousands of secrets a day or hundreds of thousand or who knows how many secrets a day. Not only that, but if you, if the secrets manager isn't working, it's not giving you the secret or there's a problem with the rotation, something like that, your business can can break down. Right? Because you need the access for your business to run. Right? That payment gateway has to work. So you can't you don't have the same, so so PAM and so PAM, solutions are generally not built for the scale you need in the sequence management. It's not built for the that level of automation either, and it's not built for developers. Because the people who use sequence management most, let's face it, are developers. Right? Because they are the ones who are injecting secrets into the code, into the application, into wherever whatever it is that needs access, and that's running all the time. Right? So those developers need something that that works the way they do. It needs to integrate with their tools. It needs to, work the way they do, and that is why you need to look at a secrets manager where your developers can say, oh, yeah. I'm gonna use this. Right? This is this is this is, simple to use. And I I do wanna do one more plug for Kielis that we actually, there's someone who switched to us for from a competing secrets manager, and they saw adoption go up two hundred seventy percent in, I think, three quarters, because, again, it was easy to use. And that's what you need for security. You need people to use it. Okay. I'm just gonna do one more check to see if we have any more questions coming in. Anything? Not that I can not that I can see. No. Okay. So thank you for joining me, and, and please feel free to contact me after the webinar if you have a question that you didn't think of during the talk. And we'll and, of course, anyone who registered for the the webinar will get a recording. So take care, everyone. Be well.