[MUSIC PLAYING] Welcome. Today's topic is extended visibility beyond the Identity perimeter. I'm Bruce Esposito, a strategist here at One Identity. And I'll be the presenter for this session. So we're going to be talking about, as the abstract mentioned, about several different technologies that, when combined, will help enhance your security.
We'll talk about identity governance. When it's in place, it gives you visibility inside, what we refer to as the identity perimeter. But by adding a universal log management platform, we can extend that visibility to additional applications, systems, and infrastructure to strengthen your security posture throughout your entire enterprise. That'll be the focus of today's discussion.
So let's start with the basic premise. Security starts with visibility. It's hard to secure what we can't see, isn't it? We need to be able to answer the questions of who, what, when, where, how, why. In order to secure something, you have to be able to see it and who's accessing it.
In my enterprise, who are the people in my enterprise that access the systems. What are the systems they're are accessing, the data they're accessing? And other things, when do they access it? Where do they access it from? How are they accessing it? And even the question of why. Who gave them that access? Why do they need that access? How long do they need to access? All these questions are key to be able to understand and answer in order to properly secure an environment.
So we have to have visibility. We've got to be able to see, as it were, in our environment from many different angles in order to be able to set up effective security. Now, this is illustrated by this concept of dwell time. This term, dwell time, refers to the time an adversary has unfettered access to compromised systems.
Now, there's an interesting, this recent study here done by Crowdstrike, show the average dwell time of attackers over the past several years in environments for published hacks, when we know organizations have been hacked. And it's kind of scary. You can see that, while since 2019 to 2020, it's slightly down from 95 days on average dwell time to 79 days. But 75 days is still high. If the average attack when it occurs, the attacker has an average of 79 days in the environment before they leave or before they're caught. That's huge. That's the big risks.
It's interesting to note that while it is a decline for 2019 to 2020, Crowdstrike observed a slight increase in the percentage of cases where dwell times are greater than 6 months. So while they were catching people quicker, the ones that were lasting longer were lasting in there longer.
A prime example of dwell time and the effect of security was a 2020, the huge hack of the SolarWinds attack. That dwell time began, it started around September of 2019 when the attackers put a tiny strip of code in there, kind of a proof of concept, to see what was possible, what they could do, what they could accomplish. They did some initial testing and then the forensics showed they actually came back in February, the following year of 2020. And they were able to reside and work within that environment, and it wasn't caught until December of 2020.
So that gave them 15 months of dwell time, as it were, to be able to carry out whatever it was that they were trying to carry out. They carried out quite a few different attacks through what they were able to do. So that's the risk, is how long could someone exist? I don't see them. I don't have that visibility. That's what we're trying to be able to overcome, to be able to not allow someone to be in my environment that shouldn't be there, doing things they shouldn't do. I should be able to see that and have someone look into that when that occurs.
But that's often easier said than done because even the one, the SolarWinds attack, the initial access they gained and what they did, there was nothing that was glaringly obvious they gave it away that they were hackers, that they were doing something nefarious. It was only after time looking back that it began to be obvious what they were doing.
So how do we solve things like this? Well, again it's visibility. The one question we need to be able to do is we have to have visibility into who has access to what. We need to start with who are the people in my enterprise that I know about and are allowed to be there? We can't just allow anybody in there. We have to define a group set of people that we allow in there.
And then not only is just to say, well, I know who they are my environment. I have to understand what access they have. No two people necessarily always have the exact same access. It'll vary from person to person by many factors. What's their job title or role? What applications need access to? When do they need that access? Is it conditional? Is it approval based? These are all the questions we need to be able to answer to begin to set the security of defining and seeing who is in my environment and what can they access.
Now of course, there's technology that helps us to get this visibility. And this is often referred to as IGA, Identity Governance and Administration. This kind of helps us to set up what we often refer to as an Identity perimeter, where we set security instead of just being physical security, we now allow security to be Identity based security based on who someone is and what they're accessing. And so that's what an IGA solution does. An IGA solution, like One Identity's Identity Manager, will ensure that the right people get access to the right resources at the right and for the right reasons. Or why are they accessing this? And is it appropriate for when they're accessing it and doing that?
So putting an IGA solution in place, helps give us that initial visibility into seeing what my population of users are and to define accurately if their access is correct. And what it does is typically it knows that this is ever evolving, so provides capabilities to re-certify or test to this, to audit this on a regular basis. So we don't just assume that we hire someone, we just give them access and they're fine. We can regularly, annually, monthly, quarterly analyze that access, to look at a user and say, OK this is the current access that a user has. Is it still accurate is it appropriate for what they need to do?
We can also, with an IGA solution, make it ad hoc type of certification, where we could say if an event occurs, an alert, an anomaly, we can immediately require someone to certify or audit that access. If something's unusual here, I would like someone to go and review a person to make sure that their access matches what we see them doing right now. Is it accurate or not? So that's real powerful of this IGA security visibility provides us, that Identity perimeter of truly being able to understand access based on people and what they should be able to do, and to be able to continually provide that the certification process.
But that's not enough visibility. There's more visibility than we need than just that. We also need the visibility into how access is being used. That's the limitation of IGA. IGA is somewhat static in the sense it's telling me well here's a person Bruce, and he works in this department and this is what he should be able to do. But IGA, in and of itself, doesn't know what Bruce is doing right at this moment. That's the challenge because while I may think that security set up properly for this user, do I really know what they're doing? And are they doing things that they're supposed to be doing?
So we need to be able to answer the how in addition to the who and what, because the how becomes critical to be able to look for anomalies, to look for breaches, to make sure things are being done accurately. Well how do we get the answer to how? Well there are solutions that provide that.
Typically, the how is addressed through a SIEM solution, an event management system. An example is Splunk, probably the biggest one the leader in this space. So an event management system, a SIEM solution, gives us that how because it's designed to collect and aggregate all the log data and real time events from all the different systems we have out there and analyze that data.
So it's connecting to my devices, the firewalls, the perimeter devices, as well as the applications, the databases, all the information. Anything that generates a log, pretty much can be sent to a SIEM. And at that point it can then take that data and analyze it. And SIEM solutions are really good at that. They have the ability to look for anomalies, identify vulnerabilities, to clearly alert on incidents as a season coming in there.
And they can be either taught over time or with the advent of AI and machine learning, they can learn over time to be smarter than what humans can identify. If they can identify things that aren't quickly seen by the human eye in an environment by looking and analyzing how access is being used. So they're really good at that. So that's why, oftentimes, a SIEM is a first line of defense to put in place to really pull the information we're gathering in and give me that analysis for the alerting and security that I need. So that helps us answer the how.
But having an IGA solution, having a SIEM solution, going out and getting Identity Manager and Splunk is great. And a lot of organizations have that type of environment. But a problem still exists when it comes to security, even though you have these two implemented.
That problem is what we just talked about. IGA solutions know the who and what, but they don't know how. I mentioned it before, IGA knows Bruce and what his job is, but doesn't necessarily know what Bruce is doing right now, how he's using it. SIEM solutions have the opposite problem. They know how. They can pull in log data and they can see, but they don't necessarily have the depth of the who and what. I can see that a user login has come in here. I could see the IP address, the login ID, maybe some other information. The ports that's being used, the application that's being addressed, what's actually being done in the application.
So I can look at the information being done, but I don't necessarily see and know that this is Bruce Esposito, and that this is his job title. He's a strategist and he works in North America. This is what he should and shouldn't be able to do based on the things of where he works, he reports to, his job title. So that information typically is not in a SIEM. A SIEM solution is just saying, well, this is the user, coming from this IP address, and this is the function of what it's doing. And that, at surface value, may look accurate.
So I can have an IGA solution that's in place that says, yeah my users all seem to have the appropriate access. And I can have a SIEM solution analyzing how access is being used in a surface value. It looks like everything is being done, what's expected. But it isn't until you combine the who and what with the how, that you could see unique anomalies. You can see some things begin to creep in place, of vulnerabilities that aren't necessarily obvious if they're looked at separately.
And so that's a problem we look to solve. Well, how do we solve that? Well a simple way is the obvious, connect them. For example, One Identity's Identity Manager has the ability to connect and feed identity enriched log data into a SIEM solution like Splunk. So now by doing that, we really gain more visibility because now we're adding Identity enriched information into the SIEM solution they can use for its correlation.
So as information comes in, it's getting fed these logs. It has the ability to say, OK, well, I see Bruce is accessing SAP and I'm looking at his job. Well OK that looks correct. This is his job, this is his role, his role is correct, he's accessing it. Based on what his role is, all this seems to fit. It works. Or I can identify that something's wrong here, that based on the information we have about Bruce, and we analyze it, it looks like something's wrong and maybe we need to investigate this incident.
So adding an IGA solutions logs to a SIEM solution really enhances the ability for correlation. It provides Identity rich access information into all the data showing how the access is being used. So that's the solution, but I put a note here, it's almost the solution. Because that, in and of itself, that we're looking at here, tying the two together is a partial solution. It still has a weakness. It still has a problem.
The problem is that IGA is really limited to its managed applications. So if you've deployed an IGA solution, you quickly learn that a lot of times when organizations first look at IGA, they look at it. This is great. I can automate connect, analyze, certify the data and access across all my systems. And that becomes great until you begin to look at your environment and realize you have hundreds of systems. And it can often become impractical to try to implement an IGA solution to connect and manage all of the systems within an organization.
So typically what happens is-- and it's often because of time and money and the return on investment some aren't worth it-- it just doesn't seem practical to go for everything. So most IGA implementations focus on the key applications. They typically will go after the directory stores, like Active Directory, the HR information or the other information is a record for the contractors or user systems. It goes for the big systems, the ERP like SAP, perhaps a Salesforce CRM type system.
So these are the big ones that have the most value, the bang for the buck when it comes to automation and auditing. These fit the requirements, the regulatory requirements, and may need to be looked at. So they get the focus. And IGA is really good at providing Identity rich data on that. But typically an organization will have hundreds of other systems that are not part, not directly managed by IGA.
Now typically the way that gets done a large organization is they're done manually. A lot of times, that's really the key role of an ITSM system, like a ServiceNow, a ticketing system. And that can be tied in with IGA, like Identity Manager has the ability to connect to and integrate with ServiceNow.
So by doing that, IGA can focus or identity manager can focus on its managed applications. And when a user needs access to an application that isn't part of the connected systems, it can create a ticket over in the ServiceNow, the ITSM, and then someone manually can go and create and provide that access information there. And that kind of-- combining the two, a manually managed ones and the IGA, we can provide the automation we want.
The problem is is the identity and rich data that we want the so valuable to enhance the SIEM application, is really based for the vast majority on the managed applications. IGA will have very little information on the unmanaged applications because it's not the one, obviously, that manages it.
So that's a problem. So I'm getting visibility, rich visibility, but only to a subset of all the systems that exist out there. I need more than that. I want entire visibility. So how do we address that? Well a simple way is, dummy, just have the same system collect the logs from the unmanned systems. That solves it. Well it does it?
That, in and of itself, at face value will solve it. So if the SIEM pulls in all the logs from all the unmanaged system, plus we're adding all the information from the IGA system, now we can enrich the data. The SIEM can do what it's designed to do, correlate this information coming in from its logs with the Identity information that the IGA system is feeding, and give me rich, valuable data.
I can see the access Bruce has and how he's doing it across all systems, not just looking at systems managed by IGA. And so that really becomes key. So problem solved, just connect it. Well again, almost. There still is a problem with doing this. And what is that?
The problem is for a lot of organizations if we took all the unmanned systems that collect all the logs and feed them into the SIEM, it becomes too large, too much data. As it were, we're making that haystack bigger and bigger, and making it harder to find that needle. And that, oftentimes, is really the problem when it comes-- that's why those dwell times can be months, 15 months that a hacker can resign environment is because of this.
The log data is coming in there. The information's there if someone's able to see it and catch the anomaly, to do the correlation. But if there's too much information, it becomes difficult to really see the important information. So just simply dumping all logs into a SIEM can become impractical. Many times it's too expensive. SIEMs are often charge based on the amount of data that they consume. So just dumping everything in there isn't always practical as well.
So it leaves a hole that we've got the data we want. It's just too much data to provide in there. So it seems like each step of the way we kind of almost get there. We have the Identity information. We have the logs. We're trying to correlate this. We have the SIEM in place, but there still seems to be some holes in place that we need to solve.
So that's where we really lead to what is the real solution, the complete solution to address this, to give me the visibility that I want. That's where we add syslog-ng. One Identity syslog-ng is designed to handle this specific type of problem. The syslog-ng collect the logs from all the unmanned systems so they don't all get dumped directly into the SIEM, like Splunk.
Instead, it all goes into syslog-ng, which what it's really good at, is handling tons of logs from different systems. That's really what it is. And then it forwards the relevant information into the SIEM. It goes through that giant haystack, gets out the key information, and provides that into the SIEM system.
So the SIEM could do what it's designed to do. If it only has the key information it needs, then the correlation that it does, looking for incidents, looking for anomalies, it's much easier because its focus on just the key information that we need, not trying to wade through mountains, of huge amounts of real time data that almost becomes too cumbersome for the SIEM to handle.
So again, syslog-ng, that's the key component to help me take that identity enriched data and apply it to the unmanaged application, which are often the larger group of applications, to give me that true, as it were, stereo visibility. Because if I'm just looking at SIEM or I'm just looking at IGA, I'm only getting part of the picture. I need to really pull those together to get the big picture of who, what, and how of data is being used.
So that's really the key. Syslog-ng is key to that component. Now if you've looked at other sessions or syslog-ng, you realize there's many capabilities it provides. I'm just focusing on one here, as it relates to Identity information and security. But one of the key capabilities of syslog-ng is this real time transformation. It's designed to be able to, again, grab huge amounts of log data, and go through and classify that data, parse it out.
It could actually rewrite it and normalize it, so the data is consistent that gets provided to the SIEM. And then the key thing is it provides the filter capabilities. So whereas I'm getting tons of data, not all of it is relevant to my security, to my identity information that I want. I can then define for each application what is the key information I need from here, that I need to provide to the SIEM application, like Splunk, so that it can do the key correlation for security.
Yeah in short, syslog-ng makes log data easier to process by the SIEM, by Splunk. That becomes a key benefit. And that, in and of itself-- I mean you can use syslog-ng in and of itself just to help make your SIEM application run better. But when you take this capability and add into it what you're also going to do with Identity Manager and IGA and use those together and leverage this Identity rich information, now you're really increasing your security posture in your environment.
And that's the heart of what we're talking about. That's the key thing here. It all starts with one, our security platform. We have a SIEM, which is designed as a security platform for your environment. Likely you have this in place today. That gives you excellent ability to analyze your environment, to see what's out there.
But at the heart of it, a SIEM solution like Splunk is only as good as the data we feed it. If we feed it too much, it becomes bogged down. It doesn't become useful. If we feed it to little, if we're just giving it a partial amount of data, it doesn't have the ability to do what it does well. It doesn't have the ability to correlate and analyze information as well as it could if it's limited all the information we have.
So how do we solve that? Well Identity Manager IGA provides that identity enriched data to the SIEM, giving it key information of what it needs to enhance its correlation, its anomaly detection. And we use something like syslog-ng, which is the ability to just limit the key information to the SIEM and not overwhelm it with too much data.
Yes, by taking these three components together, yes, by combining one Identity Manager with syslog-ng, you can extend the visibility of your SIEM beyond the Identity perimeter to the entire enterprise you have. That's at the heart of it. By doing this, you will enhance your visibility. And in the end, you will greatly increase the security for your enterprise.
So I want to thank you for your time that you've given me here today to learn about this, and combining some One Identity solutions together for security. If you have any questions about what we've talked about, you can add them to the chat in the link provided. Or if you like, later, you can reach out to me at Bruce.Esposito@oneidentity.com, and I'll be glad to help provide the answers you're looking for. Again, thanks for your time today.
[MUSIC PLAYING]