Good morning.
Good morning, everybody. So we've heard over the last day or so that we need to build an identity and privilege program tools, controls. What if I were to suggest to you that we should just trust everyone instead of doing all those controls and identity, I hope this is your reaction. If anybody ever suggests that you should just trust someone instead of doing your job as an information security professional, I have been asked this a lot either at Charles Schwab, PayPal, all the other companies that I previously worked, because trust is a big part of both identity people doing their job. People having privilege, as we've heard before, people sometimes rate their existence at a, at work based on how much privilege they have, how much information they can access.
Why can't we trust people? Well, we can, we can trust people as people, but I would also suggest that most of your enterprise environments look like this patchwork quilt of applications, connected to each other. Companies join to each other. And nobody except your most senior architect can figure out where anything is ever. Some people might know how to connect to it because they have a button. But when you look at this, there's really almost no way to trust somebody to get it right every time. So yes, of course you need to trust them because you hired them. They have a job to touch your most critical data. They have to process the credit cards. They have to touch the banking information. They have to make configurations. But what I think we need to do is security people, business owners, CEOs, COOs, whatever our job is, we have to control what we can control as we can opportunistic security. What I want to talk to you about here in the next 15 minutes is five things that I think are non-optional. When it comes to doing a security program in controlling identity and privilege. In my opinion, there is no company on the planet that should not do these five things.
So what do you do? You hire an architect and you build an information security plan, right? This is the simple way I hope in your career. Everybody has seen a plan that looks like this. If your plan looks like this, throw it away because you will never do anything useful with a plan that looks like this. Oops, over there, I think this is actually the states budget approval process. To give you an idea of how simple things are, whether this is attributed to Einstein or not. That's, you know, everything attributed to somebody's true, cuz it came from the internet, but everything should be made simple but not simpler. So what do we do? Here's the five things communicate in the right language. And I don't mean in German. I mean, in the language of the person, you are communicating this to, we all know that our architects speak different language than our executives. The companies we purchase have a different language than the one who does the acquisition. And what's really important about this. No matter in what style you choose to communicate in, you must tell the truth. This is 2017. Gone are the days of plausible deniability. Having somebody say, oh, I didn't know we would get breached. Everybody already knows all of this. So it is our job to give the person the information that they can use to help us solve the problem. So we need to tell the truth. We have to speak in business language, not in technology, speak in controls, speak in use cases.
The way that I take a look at this. When I architect things is you think about company use cases, which map into a control you need. And then at some point you buy or build a tool. Very few companies on the planet actually need to build a tool. Nowadays I happen to work for beyond. Trust are out there. You can stop and talk to us, but there's a lot of enterprise class vendors whose product is fit to use. In most major corporations. You don't need to figure out how to put something together. You need to implement something in the way that works for you. People talk about risk based security, risk based privilege, risk based identity. But what's important about that is you identify your crown jewels. I don't know what your company is, but it might have healthcare information. It might have credit cards. It might have people's information. It might have wills. It might have insurance. It might be an auto parts store. But the important thing is that you identify what's important to you. And what I don't mean is I don't mean you first run a CMDB project before you do information security. I think we may, all at this point in our careers have run a failed inventory project or CMDB project where we have said, as soon as we are done finding all of the things, we will protect them and you never quite get done finding all the things.
So I have a different way. How about you find the board of directors, 10 VPs, 10 database people and 10 architects. And you say, please tell me where the 10 most important things are. You take those 40 answers. You union them together. And I bet you'll have 90% of the important stuff at your company. You don't need to finish finding all of the things because your executives already know what they are. When they talk to the street, your network operations team already monitors for their availability. You mostly know what the important systems are. And quite often the most important systems have the most important data in them. So when you start applying identity and privilege controls to your most important things, start with the ones people can name right away, because they're very likely the most important. I'm not sure what you do to fix them. You might need to encrypt it. You might need to move it. You might need to turn it off. If we've been at our company for a long time or our company is old, we might have that system that just needs to stay around for five more years because it's got something important on it.
If that executive wants to accept the risk of that, staying there protect it, but maybe it's time to turn it off, protect those CR jewels because that is what's important. If someone breaks in and compromises one machine, maybe nobody cares. If somebody steals your source code, maybe that's not important to you. If somebody steals your customer database, you now need to disclose it right away all the time, full stop. I currently work for a privilege access company. So we're all about privilege access, but this is probably the most important thing you can do in protecting your company. If you look at every single third party, independent report out there, you will see that the vast majority of successful insider or ex external attacks have abused a privilege. They either stole it. They broke in and took it. They misused it. They colluded it. They guessed it. It's all privilege. Maybe you need to simply change the passwords cuz you've never done it. There are actually some companies who don't need a tool. They have five servers and one CIS admin, maybe their CIS admin just needs to go change the password cuz it's been the same thing for 12 years.
What you need to do here is make it harder to get in. We all are very, very, very busy as security people. And one of the things we shouldn't do is we shouldn't chase the stuff that's easy to do today. It's very easy to rotate the red password. It's very easy to manage active directory accounts. We are really good at it. Microsoft has gotten really good at active directory. Don't spend your time doing the easy stuff.
There's about 95% of privilege that boils down to a person mapping to a privilege account. And having that be in the right place, change the password, record what they do, turn it off. If you don't need it, spend your time on the things that matter to your business. Use a tool or a process to do the things that are automatable. Whether you use my tool or someone else's tool, the common things that every single standard regulation on the planet say, do it rotate. 'em put multifactor on it doesn't matter what it is. People will tell you. SMS validation is not secure. It's a lot more secure than not having it at all from a continuous improvement go from, I never changed the password to I did it give a SMS? If that's all you get, if you can only do a soft token, do a soft token. If you need hard tokens or private keys or biometrics, whatever your scale is, do it stop thinking about it and do it. I've spent 19 years being the operations doer at big companies in fortune 500, too many people get stuck in analysis paralysis with this stuff.
Unfortunately, even though we've been doing patching and vulnerability management for ever, it seems people still aren't very good at it. I think it was the 2014. Verizon report said that 96% of successful vulnerability exploits used a vulnerability that had been fixed for more than one year. So if you simply patch once a year, you're good. Well, no, but come on. We can patch, right? Our business upgrades, their most critical processing system at least once a year with new business logic, why can't we as security and infrastructure people open a change ticket, follow the business process and patch the thing we don't want to lose to a bot. It, I don't wanna lose to a script kitty from whatever country he happens to be running it from or whatever Amazon region he happened to start it from a minute ago. One of the NSA guys yesterday said that most attackers compromise your network. Within one minute to one hour, they've probably done that through a privilege exploitation or compromising a vulnerability on a host. Maybe it was fishing, but it probably broke into something or installed something. If you can get rid of that surface area through both privilege access and vulnerability, you can remove high 90%. Microsoft has even released numbers that says, if you remove administrative rights from their machines, you stop 98% of the successful successful exploits.
So it's no longer whether you should do this. I really wanna challenge you to why haven't you yet, if your answer is because my developers can't work anymore, we fixed that years ago, the endpoint privilege management vendors, we've worked that out. There are policies for developers. We know what they do. We know about executives and hotels. We know about CIS admins who reimage their own machine. We know about customer service, people who should never mess with their machine. If you're still thinking about the edge cases, put it as an edge case and solve the other 98%. When you get back to work me as a security professional, I do not want you to lose to a botnet. When you think about vulnerability management, I also want you to not shoot the criticals. If anybody has ever seen a list of all the vulnerabilities in your company, let's pretend you have 20,000 machines and Microsoft releases some new patches. This week you'll have 2 million new criticals. So you'll patch 'em and then they'll release more. And next week you'll have 4 million new criticals and you have successfully gone backwards. Congratulations. So instead maybe your vulnerability management program should focus on your critical assets. You identify those before. Maybe you should look at the ones that are most risky to you that have a known exploit.
I've had this argument with people a few times. Here's a use case for you. If you have an Oracle database buried in the core of your company, that's behind 20 firewalls or a web server on the internet. Let's pretend that web server on the internet has a low, but your Oracle database has a critical, which one should you think about patching first? Should you do an emergency change ticket patch? The Oracle thing I would suggest it has almost no risk buried at the core of your data center. If an attacker is at the core of your data center, he is not gonna exploit Oracle to get in. He already has that database account. He already has the admin account. He got that far. You should patch the thing, hanging out on the edge that can lose to the botnet. So when you think about vulnerability management, yes, you need to do it. Scan all of the things, identify all of the things, run it through cognitive noncognitive, machine learning, non machine learning, or an Excel spreadsheet, sort it by what's risky, what's critical, but what's exploitable so that you can patch what's important to you.
And then what do you do about it? The industry metrics show that your average SOC Analyst spends 23 minutes on a ticket. If they do full research on it, that means your person can do three tickets an hour or about 20 tickets a day. When you get better, better at detecting things, they need to be the right things. They need to focus on the things that have had abused privilege. The areas where your crown jewels are your important information. They should not react to. So and so might have a virus. So, and so might have X. Nobody has time for that. There's a lot of tools out there and cooperation vendors working together is running rampant today, which is awesome. Close loop remediation is becoming a thing. Again, you can detect malware and trigger a privilege change. You can detect misbehavior and trigger a react attestation with sticks and taxi with APIs, with Sims, with UVAs, with privilege, things like the product we have, you can in real time react. So when you look at how to detect and respond, yes, you have to do the basics. Turn on the logging for sure do. 'em on the critical things. We talked about
Log the really important people, you know, as some of the standards say today, PCI three, two, your CIS admin is in scope. Now I dunno if you've thought about that, but they have MFA access into your CDE. So you should log them. You should know when their privileges are misused, your system, DBA, your application DBA
Of of course you should have a SIM. You should have something that helps you organize this information. So you can respond to what's important to you, but you can respond to what's critical. What's abused. That will help you respond as quickly as possible. Layered security is still a thing. I think we've forgotten the build a layered security strategy buzzword, but you still need something to protect people from breaking in. You need to protect your endpoint from antivirus, Annie malware privilege abuse. You should have a gateway between your people and your data center and inside your data center, you should log, detect and control. If you don't do those four areas of things do them now. That's it. Thank you very much.
Thank you, Scott. There's one question.
What's my view on cognitive security with regard to threat detection. So one of the great things about tools like Watson, I liked that one because it's really good. Any sort of security system that uses machine learning or cognitive to enhance what you should go look at is amazing. If I can take that 23 minutes of my sock Analyst down to five, down to one down to maybe it automatically pulled something. I, I think that's amazing. We we've been quarantining machines with viruses for 10 or 12 years now, why don't we do it with everything else? Like we need to be ready. There will be an acceptance curve. Of course everything has an acceptance curve, but we should be ready to pull the trigger on some of this stuff because it will be in every product very soon.
Very
Good. Thank you. Thank you.
Thanks.
