Good afternoon, and welcome to the Serious Security Seminar for Spring Semester 2008.
We're in the process of getting a connection set up here to display from the laptop, so it may be just a moment.
I'll say a few words about the seminar.
This has been going on on a continuous basis now for well over a dozen years, as a series of invited speakers once a week coming in to the university to talk on a variety of topics.
Over the last five years, six years, we have been videotaping the presentations and then digitizing them and making them available for upload, either as flash video that you can access through the Serious website, or many of them are available as downloads to a portable player,
like an iPod, from a number of different sources, including not only the Serious website, but also from the iTunes University site.
So if you miss any of the lectures, or there are some in the past that you think you might be interested in seeing, then please visit the archive and see what we have available.
We have some older ones that we're still in the process of digitizing and putting up, so they'll be more added as time goes on.
Today's speaker, who has the laptop going, but now we don't quite have the display yet, is Dr.
Eric Cole.
And Eric has a long history of working in information security.
He's authored a number of books on security.
He's currently a Lockheed Martin Fellow and working in the area of information assurance and security.
He's worked in networking, intrusion detection, intelligence, and a number of other areas.
And we're very pleased to have him visiting here today to give us a talk on security in a changing world.
And part of the change is in getting the display to come up and be visible on the screens.
So as soon as we get that up, we'll turn it over to Eric.
I was asked to remind each of you that if you are going to ask questions at the end, to please turn on your microphone.
The microphone on your desk has a button that you need to press, and if you're successful, the red light will come on, and that indicates that your microphone is live.
There it is.
It's up there.
And when you're done asking your questions, turn the microphone off.
The reason for that is otherwise your question will not make it onto the recording so other people can hear, all they'll get is the answer.
So without further ado, Eric.
Great, thank you.
It's a pleasure to be here.
We look at the world and how it's changed over the last 10 or 15 years, and it's changed rapidly.
It's funny to think that when I was in college, which, believe it or not, was not that long ago, I actually did one of my first papers on a typewriter, which, if any of you ask what a typewriter is, I'm going to make you leave the room, and you used to go in and do your programs on punch cards,
and you look at now that my kids at school in first and second grade start doing their homework assignments on computers, you have information accessible anywhere.
From that perspective, technology has changed drastically over the last 15 or 20 years, but the real question is, has security really changed that much, or are we just making it much harder than it needs to be?
If you go in and look, for example...
Let's just go back to the Morris Worm.
If you look at the Morris Worm, it came out in 1989.
That was before there was the World Wide Web, before there were computers on everybody's desktop, and most people were using floppy disks.
And back when the Morris Worm came out, if you had Internet access, that meant that you had a CompuServe account, or you worked at a major university.
So things have drastically changed.
But let's look at what allowed the Morris Worm to cause such havoc on the Internet.
What caused it was everybody was running the same operating systems, they had known vulnerabilities, and it was able to propagate very, very quickly.
Now let's fast forward to today.
Pick any of your favorite worms that are out there today.
SoBig, Notchy, any of those.
And what is the reason on why they were able to wreak such havoc on the Internet?
Everybody's running the same operating systems, we have known vulnerabilities, and the worm's able to propagate very, very much.
So if you look at it, have we really learned that much from a security and technology perspective over the last 10 or 15 years?
If we go in and we harden our boxes, we turn off services, we remove things that are not needed, and we patch our boxes on a regular basis, which, by the way, I think patching's a whole bunch of crap, but we'll talk about that later.
But if you go in and do those basic things, what you'll realize is most of those worms would not be able to cause damage to your system.
Most of the worms, when they came out, they either had patches or they had ways to fix it.
There's very few what we call zero-day exploit worms out there, and the reason is a zero-day worm is almost a contradiction because a zero-day exploit is an exploit in which very few people know about it, it's not publicized, and therefore the vendors don't know how to fix it,
and there's no patch available for it.
So the second that you take a zero-day exploit and you put it in a worm, where it's now openly breaking into systems across the Internet, that exploit is now public, people will know about it, people can identify it, and therefore patches and other solutions can be put out there.
So therefore, while you might see a few of these early adopters, zero-day worms, most of the worms out there and most of the worms that have wreaked havoc, from CodeRed to Nimda to any of those, if you kept your system up-to-date and fully patched, you would not be vulnerable.
Yet if you look at the sheer number of systems that have been exploited, even something as simple as patching your box, organizations are not doing, and not doing on a regular basis.
We also go in and look at USBs.
There's, by the way, one of the new trends, it was just publicly released so I could talk about it, I knew about it several weeks earlier, but what's happening now is you go to trade shows, or you go to these different events, and they love giving out these little USB drives.
You can get USB drives from anybody now for 5, 12, or even a gig, they're giving them out like candy.
And the problem is, what if you go in and you start putting worms, viruses, or malicious code on those?
You plug those into a system, and they get exploited.
One of my favorite stories is doing a work for a client, and they knew, and this has been replicated many times, but they knew they were having an authorized pen test with social engineering against their organization starting on Monday.
They went in on Friday, had an all-hands meeting and told every one of their employees, somebody's going to try to manipulate you.
Somebody's going to try to get information out of you and cause harm.
Personally, I think that made the test bogus because you're not testing a real condition if you warn everybody to be on their best behavior for Monday and Tuesday, and then they go back to their bad patterns of behavior.
But the bottom line is, even with everybody being warned, you go in and you take 50 USB sticks, and you just drop them around the parking garage, outside where people like to go smoke, where people like to eat lunch.
And with the experiment I did, dropped 50 USB drives, and within four days, 35 of them were plugged into computers.
How did I know?
Because it was an authorized test, there was a backdoor program on it, and when I scanned for that backdoor program across the company's IP addresses, I found 35 systems infected.
So if you look at a simple problem like that, you go in and tell people, don't plug in the USB drive.
And this isn't new.
I remember back in the 80s when I worked at the agency, and I headed up the virus infection team, how did viruses spread in the 80s?
Floppy disks.
The good old five and a quarter ones.
So if somebody got a virus, what did you do?
You said, what floppies did you put in your computer?
You then figured out what the floppies were, you found the virus, you figured out what other people they gave it to, you went in and cleaned up those systems, and then when nobody was looking, you beat the user to make sure they didn't do it again.
But the problem is, the way we solved that was scanning any media before we put it into our system.
I remember companies had special computers, you would have to go with your floppy drives, put them in, and get them scanned.
How are USBs any different?
USBs is just a higher-end portable media than a floppy, but the same things we had to do to protect our systems then work now.
The problem is we lose common sense when it comes to the internet.
If when we were walking over to this building, if Spaff and I were walking through campus, and I saw a half-eaten candy bar on the ground, and I picked it up and started eating it, he would probably look at me and say, Eric, that's so past the three-second rule.
I have three kids, so the three-second rule always applies.
I remember my friends were over, and something fell on the floor, and I gave it to my kid to eat.
They're like, what are you doing?
I'm like, hey, two seconds, that's good food.
We'd be throwing out a whole lot of food if you didn't have the three-second rule.
That would be gross.
You would never go in, see a half-eaten candy bar on the ground, and start eating it.
Why?
You don't know where it's been, you don't know what somebody did to it, and you don't know what germs or other things are there, so it can cause severe harm to your body.
But why would you go in and take a USB stick and put it into your computer?
It's eating a virtual candy bar.
You would never do it in real life, but some reason when we get to the internet, that common sense component fails.
Once again, you wouldn't go in and walk in a bad street of New York City at two in the morning with $500 in your hand, and if you did, and you got mugged, you probably wouldn't be surprised.
Yeah, I sort of knew that was happening.
So why is it when you walk on the bad parts of the internet, and somebody steals your credit card number or your social security number, why are we surprised?
Same exact issue.
One other big thing that I push, and many of you are sort of in between this, but I still want to pass it on because you probably have friends, nieces and nephews, or brothers and sisters that are younger, but you look at the average 14 or 15 year old,
and I go to PTA meetings and I ask parents, how many of you have talked to your kids about talking with strangers?
Oh, every one of them.
What do you tell them?
Oh, don't talk to a stranger.
If they're walking home and a van pulls up and says, hey, get in, we have some ice cream for you, what do you teach your kids to do?
Scream and run.
Right?
Get away from that.
We've trained them very well on that.
Then I ask those same set of parents, how many of you have talked to your children about not talking to strangers on the internet?
And less than 5% of the hands go up.
How is that any different?
Kids and people are being targeted on the internet, just like they are in everyday life, but why is it that we talk to our children about stay away from bad people in real life, but on the internet it's okay, and the problem on the internet, it's worse.
Because at least in real life, I can see that when somebody pulls up, they're creepy looking.
On the internet, you can pretend to be anybody you want.
You want to be a 15 year old?
Boom!
It's one of the country music songs out there, I love it.
The main chorus of it is, I look much better online.
And the idea is online, I can be 5 foot 9 and 150 pounds, with big muscles and blue eyes and blonde hair.
You can be whatever you want online.
So we have to remember that, and make sure that we instill the same common sense in everyday life that we do on the internet, and that's what I do when I train a lot of users.
Step back.
If you wouldn't do it in the real world, then don't do it online.
And the problem is we tend to lose sight of what security really means.
When you go to the average company, or if I asked you, what does it mean to have a secure system?
I'd probably get answers like, oh, you have to install a firewall.
Or, oh, you must have an IDS system in place.
Oh, you must monitor the logs on a regular basis.
Or you even said it earlier, Eric, you have to patch your box on a system.
The problem with those is, security is not about a firewall, an IDS, or patching a system.
Why?
Go in over the last 12 months, and pick your top 5 companies that have been broken into.
Your choice points.
Your TJ Maxx's.
Your Veterans Affairs.
Name all of them, and research them.
What do they all have in common?
Every single one of them had firewalls.
Every single one of them had IDSs.
Every single one of them had some form of encryption.
Every single one of them did some form of patch management.
Every one of them had a security department.
And every one of them had a security budget.
And they still got broken into.
They still got compromised.
Which means just going in and deploying a product is not going to get you there.
Security is all about mitigating or controlling risk to your critical assets.
If you work in security, every minute you spend on your job, every dollar you spend as part of your company's budget, you should be reducing a risk.
If you're not reducing a risk to a critical asset, then you're not focusing on the key areas of security.
And even though some people say security is hopeless, it's not.
There's actually one industry that's very similar to security, and they're very, very successful.
The insurance industry.
The insurance industry is all about risk mitigation.
They have no idea if you're going to get into a car accident tomorrow.
They have no idea if you're going to die or get sick tomorrow.
But what do they do?
They go in and they normalize the data.
They understand what are the things that could potentially happen.
They determine what are the chances of that happening, and that's where your premium comes from.
The next time you go in and get a cost for your insurance on your car, ask that insurance agent, where did you come up with that number from?
They'll tell you, oh, well, we went through based on your driving history, based on other people in your categories, and other factors.
They determine what is the risk or likelihood of you getting into an accident.
And the trick is they bring in more that they pay out, and that's why they're very successful.
If you don't believe me that that's the case, the next time they predict that they're going to get a major hurricane in Florida, call up and try to get insurance.
You can't.
Why?
Because if it's guaranteed that a hurricane is going to hit Florida, that's not risk, and therefore insurance companies won't play that game.
So it's got to have a risk component in it, and that's what we're doing with security.
I'll tell you right now, bad things will happen.
I tell this to CEOs when I talk to them.
They say, Eric, we want you to come and make us 100% secure.
I could take your money, but I'd be lying to you.
Bad things are going to happen to you.
Bad things are going to happen to your company.
But your goal is to go in, let's identify what your critical assets are, let's identify what the high-risk items are, and let's remove or reduce that risk to an acceptable level.
I was talking with one of the professors this morning, and we were talking about the insider threat.
When you have an insider threat, as long as you have employees at your company, there's going to be people that are going to cause harm.
The goal is not to stop the insider threat.
The goal is to catch or reduce them before they cause major damage.
An example is if you look at Robert Hanson at the FBI.
He was doing espionage for about 7 years.
Now, there's probably other Robert Hansons out there.
The trick is not to stop them, but catch the next Robert Hanson in 2 years instead of 7.
Because if you catch him in the 2 years instead of 7, you're reducing the risk, you're greatly reducing the damage, and greatly reducing the impact.
One of the things I always say is prevention is ideal, but detection is a must.
You try to prevent things as much as possible, but you realize that bad things can and will happen, and the goal is to try to stop and reduce that risk to an acceptable level.
It's the same thing with driving a car.
You can't always control whether you're going to get into a car accident.
You can always stop at red lights.
You can always stop at the stop signs.
You can always go your speed limit.
But what stops some crazy maniac on the highway from running into the back of you?
What stops somebody from pulling in front of you and hitting into the side of your car?
You have absolutely no control over that, but by driving a safe automobile that's inspected, that has airbags and other protection mechanisms, you're reducing your risk of harm or death, and increasing your chances of being the walk away.
We need to do the same thing with our corporate assets.
Instead of focusing just on a component like a firewall or an IDS, we have to focus in on solutions that will reduce our risk.
Now there's a paradigm shift that's occurring.
If you look at risk, risk is broken up into two components.
Threats and vulnerabilities.
Threat is the potential for harm, and vulnerability is a weakness that allows that threat to manifest itself against your organization.
When we go in and do risk analysis, when we calculate the risk, we always start with threat.
What are the bad things that can happen?
The problem with this is, this is how most organizations approach security, is they take a threat-based approach.
Just listen to the average company.
When a new virus comes out, what happens to the antivirus websites?
They get bombarded.
Why?
Because everybody's trying to download the latest patch.
When a new worm comes out, what happens to the vendor site?
They get bombarded because everybody tries to patch their system.
So if you go in and you focus your security from a threat perspective, which is what most organizations do today, what does it lead to?
It leads to reactive security.
You're waiting for a new threat, and you react to it by patching, removing a service, or updating your antivirus software.
That worked many years ago, when you had a long runway in order to secure your systems.
If you look at worms like CodeRed and Nimda, from when the vulnerability was released to when the worm came out, was about 365 days.
That means you had a year to patch your system.
If you look at many of the worms today, they're sometimes within 8 or 12 hours.
One of the things that I like to say, which we see occurring, is you have Patch Tuesday, the second Tuesday of every month Microsoft comes out with their patches, you see Patch Tuesday and Exploit Thursday.
Why?
Because what happens?
Microsoft releases all their patches.
What is a patch?
A vulnerability.
A patch is fixing a vulnerability in the software.
So when a vendor comes out with a patch, they're telling the whole world, here are vulnerabilities in our software, so what do the attackers do?
They spend Tuesday evening and Wednesday reverse engineering the patch, figuring out what the vulnerability is.
They then go in and write exploit code, and then Thursday they start exploiting at the systems.
Which means if you don't patch your box within 48 hours, there's a good chance by the time you patch it, the fox is already in the hen house.
So what we need to do is, instead of doing threat-based security, we need to do this paradigm shift, where we go in and do vulnerability-based.
We identify our weaknesses and we fix them.
By going in and identifying our weaknesses and fixing them, what are we now doing?
We're doing proactive security.
Because I'm finding a weakness and I'm fixing it before an attacker comes along, so by the time a threat manifests itself, the vulnerability is already fixed, and I'm staying one step ahead of the attacker.
The other nice thing about vulnerability-based security is, many threats take advantage of the same vulnerability.
So if I'm constantly reacting to the threats, I might be going in and taking action on 15 different threats.
Yet if all 15 of those threats are taking advantage of the same weakness or vulnerability, if I fix that one vulnerability, all 15 of those threats go away or disappear.
So that's one of the big paradigm shifts I'm seeing, where we need to go in and change our mindset of how we're approaching security and start being more proactive as opposed to reactive.
This is one of the debates I get into periodically, which is, can you prevent zero-day attacks or unknown or unpublished attacks?
And I say, absolutely.
People are like, no way.
If you don't know about it, how can you prevent it?
That's a threat-based mindset.
If you don't know the threat, how can you fix it?
Here's my example.
If I have a web server and it's running port 80443, which is HTTP and SSL, and it's also running port 25, what if I go in and say, a web server should not be running mail, especially on a DMZ, you should separate it out.
So what we do is we turn off that service, which therefore closes the port, so now it's no longer open.
Now if a zero-day exploit on port 25 send mail comes out, and my port is closed, didn't I just go in and prevent that exploit?
Absolutely.
I didn't know I was doing it, but I was still able to go in and turn that off, because it's real simple.
If we're talking about external attacks, people make it a lot more complicated than it needs to be.
If I'm going in from the internet and breaking into your system externally, there's four conditions that need to occur.
First, your system needs to be visible.
You need to have a public address that somebody can see and get access to.
Therefore, if your system has a private address and is not publicly accessible, if I can't get to your system, I can't exploit it.
That's one of those ones I'm actually finishing up a paper right now on the new security issues presented with IPv6.
Everybody's going in and talking about how IPv6 is solving all these problems and doing all these great things, but it's also opening up a new series of issues and problems.
Even though private addresses and network address translation was never meant as a security feature, if somebody can't see your IP address, they can't break in.
Well, IPv6, the address space is so large, there are no private addresses.
Everything's a public address.
So now you're relying on the fact that people are probably filtering those public IPs correctly, which, if history is any indication of the future, I can guarantee you that many companies are going to make mistakes with that.
So first is visibility.
Second is if once I see your system, if I need to break in, I need to connect to your system, and how do I do that?
Via a port.
The more ports that are open, the more ports of exploitation.
You shut down ports, you shut down the visibility.
Once I connect to a port, what am I connecting to?
A service.
So therefore you have a service running on the back end of the system, and therefore, what do I do when I exploit your system?
I find a vulnerability in that service.
If the service is not vulnerable, I can't get in.
If the service is vulnerable, I can.
So if we go in and look at protecting and preventing external attacks from occurring, you limit visibility, you close ports, and you turn off unnecessary components and services, and yes, I am oversimplifying it, but it really is that easy in terms of scalability.
The problem is if you have 50,000 systems, that's where it starts to get fairly complex.
One of my friends came up to me and said, Eric, I keep getting speeding tickets.
This is so frustrating.
Every time I drive, I get a speeding ticket.
It just seems impossible.
The cops are out to get me.
I just can't go anywhere without getting a ticket.
And I said, you know something, there's sort of a simple solution to this.
Really tell me.
It's called the speed limit.
They post it on every road.
They tell you what the rules are.
My friend was acting like it's some magical formula that you have to fill out on the fly like a differential equation problem in order to figure out whether you're going to get a speeding ticket or not.
No, it's pretty simple.
Look at the sign on the side of the road and make sure your speedometer needle is less than the number on the sign.
If you follow the speed limit, you won't get a speeding ticket.
It's the rules of the road.
They're clearly published.
The problem is if you speed all the time and you're a reckless driver and you always go over the speed limit, you have many bad habits.
So trying to break those bad habits is really, really difficult.
And that's what happens with a lot of organizations and corporations is they've done things in a bad way for so long it's very hard to break those habits.
Once again, based on what I just talked about with external attacks, I actually developed a very straightforward network architecture that if you follow these three rules, the chances of your system getting broken into is greatly reduced and the chances of sensitive data being exploited is reduced.
And I've used these three rules for a company that has 50 employees and I've done it for large government organizations that had 500,000 employees.
And what it comes down to is you start with a basic three-tier architecture, you have your DMZ, you have your middleware, and you have your private network.
The way it works is people from the internet can only get to your DMZ.
The DMZ can only get to the middleware and the middleware can only get to your private interface.
So that's the first setup.
Go in and set up a three-tier architecture where the middleware bridges the gap.
Then any system on your DMZ is accessible from the internet.
So if a system doesn't need to be accessible from the internet, don't put it on your DMZ.
If it does need to be accessible from the internet, you put it on your DMZ following one caveat.
You assume it's compromisable.
You assume that anything on that DMZ can be compromised.
Because the trick with security, if you assume worst-case scenario, if it occurs, you're well prepared.
If it doesn't occur, it's better than you thought and you're still in good shape.
So you assume anything on your DMZ is compromisable, no sensitive data on your DMZ.
Anything with sensitive data goes on your private network and anything on your private network is not accessible from the internet.
You follow those rules.
They scale to organizations of any size and you've just gone in and followed the rules of the road to prevent most of the major attacks from occurring.
Now the problem is this.
I have a mail server.
My mail server needs to be accessible from the internet so I can get inbound and outbound email from the internet.
So what do most organizations do?
They put the email server on their private network and they allow it to be accessible from the internet and then they're shocked and surprised when they get broken into.
But wait a second, Eric.
I can't put my mail server on the DMZ because it has sensitive data that's not compromisable, but if I put it on my internal private network and it can't be accessible from the internet, then how do I get mail?
Very simple.
I put a mail front end on my DMZ.
I then go in and put a mail sandbox program like an iron port on my middleware and then I put my mail server on my private network.
Now my mail server is visible from the internet but if it's compromised, there's really nothing stored there.
That's the front end interface.
It then goes to the middleware server.
It gets scanned and filtered and then it gets forwarded to your back end private server.
And then the last rule is if that's not good enough, add additional tiers.
Add a fourth or a fifth level tier between your DMZ and your private network.
Now am I saying if you do that, it's going to be guaranteed that you don't get broken into?
No.
That's like guaranteeing that you're not going to get into a car accident or guaranteeing you're not going to die.
There's no guarantees, but what it's doing is it's reducing your risk to an acceptable level so you can manage and control what's happening across your organization.
One of the other key things is desktop lockdown.
This is one of my big pet peeves and I might get on a soapbox for a minute is would you go in and give all of your users access to your servers in your data center?
Of course not.
That's our most critical data.
Are you crazy?
We have physical level of protection.
We have special card readers, biometrics, cards, all this great stuff.
We limit and control who can go in and access our server.
But what is it about that server that makes it so important?
It's not the hard drive.
It's not the CPU.
It's the data that's on it.
Well, the problem is this laptop that I have has a six or seven hundred gig hard drive in it.
That's a lot of information and a lot of data and the same information that's on your server is on this portable server.
I don't like the term laptop because it gives this mentality in people's mind that it doesn't have high value.
It's a portable server.
That portable server has the same data as what's in your data center yet you give people full access to this but you restrict it there.
So we have to go in.
If you're not going to give them full access to the regular server, they shouldn't have full admin access to their portable server.
We have to go in and do desktop lockdown because as long as users can go in, install, remove, or modify settings on their system, we're never going to be in a secure state.
So you've got to start locking down these servers very tightly because the other problem is you have this great network architecture with firewalls, IDS's, encryption, all this money you've spent on this robust architecture to protect your data.
You put your data on this device, you walk out the front door of the corporation and you plug it in an airport, a hotel, or somewhere else and your entire network architecture is out of play.
And all that information and data that's on here is now exposed.
So we have to rethink of how we protect and control these desktops and one of the big things we have to get away from is what I call painkiller security.
I see this all the time with organizations.
If you've ever taken painkillers, you can see why some people get addicted to them.
Why?
What does a painkiller do?
It makes you feel good.
It makes you feel really good.
Because it takes away the pain.
But the problem is a painkiller treats the symptom, not the problem.
If all of a sudden I have a sharp pain in my leg and it keeps throbbing and hurting, if I take painkillers, I'm going to feel great.
The pain is going to go away.
I'm going to feel great.
I'm going to be smiling and real happy.
But whatever was wrong with my leg is going to keep getting worse and worse and worse.
Painkillers treat the symptom.
They don't fix the problem.
So that's why painkillers only work if it's done usually with an operation or a medical procedure.
So they treat the symptom.
They get rid of the problem and then they give you painkillers while your body heals.
The problem is people that get addicted to painkillers don't recognize the real problems and that's why they sometimes get really sick and potentially die.
Same thing with an organization.
If you do painkiller security, you feel good, the executives sleep well at night, but the real problem is that real issue is still there and still compromising your organization and that's the issue I have where companies say, Eric, we're secure because we have a firewall.
That's painkiller security.
Does a box labeled a firewall make you secure?
No.
What makes you secure about a firewall?
One, that all connections go through the firewall and two, that the rule set is the most restrictive it can be and limited control traffic.
I can have a firewall that has a cable that goes around it.
I can have a firewall that has a rule set that says any, any, allow all, and that firewall is really doing nothing to protect my organization or my data, but many executives say, oh, we have a firewall and we're spending money on security, we're in good shape.
One of the best examples of that, and don't get me wrong, I'm a crypto guy and I think if it's properly implemented, full disk encryption has value, but full disk encryption is probably one of the new painkillers of choice.
I call it the percocet of cyber security.
It's what everybody loves.
Give me that stuff, it'll make me feel good.
Everybody's going in and saying, let's go in and deploy full disk encryption.
And if it's done correctly, it helps.
Here was one organization.
They went in, deployed full disk encryption, and they went in and their logins were set up to auto log in when people booted up the laptop.
So now you booted up the laptop, it automatically started up, logged the user in, and gave them an active screen.
Value of that full disk encryption solution?
Zero.
Why?
Because here's how full disk encryption works.
Full disk encryption goes in and it encrypts your entire hard drive with a symmetric key, or uses multiple symmetric keys, but we'll talk at a high level.
So all your data on your hard drive gets encrypted with a symmetric key.
Your user account then generates a public private key, and that private key gets locked in a virtual safe that's protected with your password.
So that means with full disk encryption, it's only as strong as your password policy.
So the first comment I always make to my clients is, if you're going to do full disk encryption, you better have a strong, robust password policy, because without a password policy, full disk doesn't do anything.
So in my client's example, the fact that they had auto login meant that if somebody stole your laptop, they booted it up, it automatically unlocked the safe, and gave them access to the private key, so they can read anything on your system, and the full disk encryption did absolutely nothing.
If I go in and leave my laptop on, and I walk out of this room, and you walk up to it, full disk encryption isn't going to do anything.
Why?
Because the virtual safe is unlocked.
Full disk encryption works if your laptop is fully turned off, you have a robust password policy, and the keys are properly protected, so if somebody steals it, they can't read your data.
But because of the VA affair incident, where the laptops and the data were stolen, all executives are now, oh, gotta have full disk encryption.
Like I said earlier, I'm a huge proponent of it, I recommend it, but it's gotta be implemented correctly.
If you don't have good passwords and robust protection, it doesn't do a whole lot of good.
And remember what we're talking about with security.
Security is all about reducing and controlling risk to your critical data.
Therefore, it's all about data access.
You need to make sure you give people the least amount of access they need to do their job.
You go in and do proper data classification.
That's my other favorite one.
I'll talk about it on the next slide, but companies go in and say, oh, we're going least privileged, we're giving people the least amount of access they need to do their job.
Do you have data classification?
Nope.
Then how do you know what data they need to do their job?
There's foundational things that need to be put in place, and RBAC or Role-Based Access Control is another way where you can limit and control that access.
Some methods on sort of creative security that I found, and this is where I think the future is going, is one of my best clients for security and one of my best test beds for determining whether I'm finding the right balance between security and functionality is my wife.
Why ?
Because if I go in, and if you haven't figured out, I'm a paranoid security geek, if I go in and stop her from using her computer at home, that's a bad thing.
And if you're not married, you can do the math and figure out why that's a bad thing.
So, you go in, and I went in, and my wife's system would always get infected with spyware and malware because she likes to go to all these sites, so I went in and took away her administrative access and didn't allow her to surf any of those sites.
So, I took away something from her, she took away something from me.
Not a good thing.
So, a couple of you are awake, come on, it's a college campus, I gotta make sure you're awake at 5 o'clock in the afternoon.
So, we go in and I said, how do we fix this?
So then I came up with this great scenario.
I now go in and she double clicks on her browser and it starts up just like it did before.
She sees no difference.
Except I'm now running it in a virtual machine.
It's running its own mini virtual machine.
What I do is I preload the virtual machine at boot up so this way when the browser starts it runs right in that virtual machine so there's no startup impact.
And now she can surf, she can get impacted, she can get malware, malicious code, she can get whatever she wants.
And what happens when she turns off her browser?
That computer goes away and the rest of her system is still fine.
So I think one of the future areas is you go in and you run every one of your applications in its own virtual machine.
Now, people can go in and they can do bad things.
That's not great.
We still want user awareness.
But now if they do, it's contained and limited to a smaller area as opposed to spread across your entire system.
It's going in and starting to reduce or limit the data points.
The other one that works well is with social engineering.
This is one I get a lot at my house where I recently moved.
So usually when you move, you're targeted for this.
And a credit card company will call the house and say, uh, sir, we're watching out for your credit and we noticed that you always pay your credit card on time, but recently you didn't pay this credit card bill.
Did you recently move?
Yes, we did.
Oh, well, we probably sent the bill to the wrong address.
To prevent you from having a bad credit, we need to take payment over the phone.
Well, a lot, some of those are legit, some of those are scams, because what they do is if you give them your check number over the phone, they can now use that to make withdrawals from your account.
So what do I always say?
Listen, I'm in the other room and I have to get my checkbook.
Give me your direct line and I'll call you back.
Now, what can I do?
I can go in and check that that phone number is a legitimate credit card company.
I could call the general number, make sure it really is Master, Visa, or American Express, and by me not giving them data over the same line it's requested, I'm now reducing my exposure of being impacted by social engineering.
So that's what I train a lot of my clients, that if somebody ever calls up and says, hey, we need you to change our password, I always go in and say, fine, but I'll give you the new password in your voicemail, or I'll email it to your boss.
By sending it over a different channel, you're now reducing your risk.
Question?
And then they ask why it wouldn't work, or why a flash wouldn't work.
Yeah, excellent question.
The question was, what if somebody in that browser example tries to go in and install additional components or other factors and it won't work?
You're right, so what do I do there is, and this seems counterintuitive, but I go in and all the possible plug-ins or things you should need, I put them in ahead of time.
So now, it's sort of fully loaded, but the other benefit about that is, and once again, this is where the wife example breaks down, because my wife can do whatever she wants, but your average employee, you don't necessarily want them to install or make modifications or do things.
So now, you give them the browser the way it should be configured to perform job functions, and now if they try to install or do other stuff, it's not going to work.
And here's the million dollar question.
When they go in and try to install new components and it doesn't work and they call up the help desk and say, I'm trying to install this and it doesn't work, here's what you have the help desk say.
What is the business function or the business job you're trying to accomplish?
Oh, well, I'm trying to go to ESPN.
That's fine, you're going to ESPN.com to find out the score of last night's game, but where's the business job?
If I'm stopping you from performing your job, we will fix it.
But if we're stopping you from doing things that can harm the company, then that's not our problem.
Or, so you're not the bad person, say, just get your supervisor and your executive's approval to get that installed and we'd be happy to take care of that.
So that's sort of a double win by working that way .
The question is whether you care whether your employees know they're in a virtual machine or not.
At the end of the day, if it's configured correctly , I don't see the benefit in telling them because it's transparent, but even if they knew, it doesn't have any negative side effect.
If they can go in, run their applications, do what they're supposed to and it's working fine, it doesn't really matter how it's set up.
And to me, that's really a quality of a security professional of the future that's going to be successful.
Fifteen or twenty years ago, a lot of security people, how were they trained?
To always say no.
Can we do that?
No.
Is it secure?
No.
Should you do it?
No.
But what you quickly find out is, if somebody asks you a question and you say no, it means they're going to do it anyway.
They're just not going to ask you anymore.
One of the things I want to write a book on is, because I swear it's true, I haven't found an exception, but everything you need to know about network security you can learn from a five year old.
If your five year old comes up and asks you for a cookie at four in the afternoon and you say no, what are they going to do?
They're going to find your wife, somebody else in the house and say, can I have a cookie?
And then you come downstairs and they're eating a cookie and you say, why did you have a cookie?
Mommy said okay.
Well, did mommy know that daddy just said no 20 minutes ago?
And then you see the long look on the face.
So, the whole trick is, what I do now is if my five year old asks for a cookie, I say, well why do you want a cookie?
It's probably because she's either bored or she's hungry.
If she's bored, then let's go play the Wii, which by the way I'm determined to beat my children at.
We got it for Christmas and we're playing on it and my wife walks up and says, hon, you don't have to let them win every game.
And I'm like, fine, if you want to think I'm letting them win, that's okay, but they're kicking my butt.
I'm trying my hardest.
And they're winning, so let's either play the Wii or if you're really hungry, you would take a banana or something more healthy as an option.
So, with security, you don't say no, you say yes in a creative manner.
And that's really what that virtual machine is.
You're going in and saying fine, you want to do this, but here's the secure way of accomplishing it.
Then Worms is another one.
If you have a traditional web server on your DMZ, should it be sending inbound SYN packets?
Yes, because it's a client-server architecture, the clients are on the internet, this is a server , they send SYN, you send SYNAC and act a three-way handshake for TCP IP.
That works fine.
Should your web server be sending outbound SYN packets by itself?
No.
Unless it's doing updates or something else, but a traditional, normal web server should be receiving SYN and sending SYNAC, but it should never be sending outbound SYN.
When was the last time you put a sniffer on your DMZ and looked for outbound SYN packets?
I do this even today when I do pen tests and security assessments, and I still find organizations that are spending thousands of outbound SYN packets, which is indicative of CodeRed and Nimda from eight or nine years ago.
That means you have sites that were infected for nine years and nobody ever bothered to look.
Nobody ever bothered to see that there was a problem or an issue.
So go in and start using some devices like sniffers or others to be able to see what the problems and issues are.
So to the future, data loss prevention or this whole space of DLP, I think it's the right idea, but I think right now once again, there's so much hype around it, it's sort of a painkiller security thing, because the key thing with data loss prevention is,
is it really effectively reducing the risk of your data or is it just making you feel good that hey, we deployed something on our network.
So I think you got, once again, you can't ever make a general statement about the space, but I still think the DLP space has sort of some forward momentum to go to really become a mature technology.
Wireless.
Whatever happened with wireless?
Three or four years ago, that was the hot thing.
There were books everywhere, there were articles everywhere, everyone's talking about wireless, wireless, wireless, wireless, and we still, I do a lot of teaching for SANS, and at SANS, we still teach the wireless course and go through a lot of the methods for securing it.
The problem is, many organizations still have unsecured, open, vulnerable wireless networks, but it's not the cool thing anymore.
So nobody focuses on it.
But wireless is the same issue it was three or four years ago, so we need to go in and make sure we're protecting those wireless systems.
Patching, as I talked about, is a reactive measure, so I think there needs to be significant research in going in and being able to do self-healing or reduce those vulnerabilities beforehand , because if you're relying on the operating system vendor or the software vendor to identify a vulnerability,
come up with a fix, test it, and go out there, you're three weeks behind the curve.
You're three weeks behind the curve from when attackers know about vulnerability before you do.
In summary, it's one of those things where you can cut corners and you can speed.
If I speed, can you guarantee me that I'm going to get a ticket today?
No!
I might get lucky today or tomorrow, but I can tell you, if you constantly speed over the course of the next 20 years, the chances of you getting a ticket are extremely high.
So you can cut corners in security and you might not get broken into today or tomorrow, but the chances over the next five or ten years is you will.
And what I found is sort of the four ways that you don't cut corners, and sort of the four, what I call Eric's general principles of security, is you've got to know your systems.
If you don't know what it is that you're trying to secure, how are you ever going to secure it?
Great experiment.
Many people say, oh, my laptop or my home computer is secure.
Can you tell me without looking at that system, what ports and what services are running on that laptop?
If you don't and ports and services are the way that people breaks in, how do you know you're secure and how do you know if you've been broken into?
You don't.
You have to know what you're trying to secure.
Only give someone the least amount of access you need to do their job.
Multiple levels of protection.
One of my favorite t-shirts, but it's a little raggedy now, so I don't wear it anymore, but if you remember Coors Light, it's a long thin silver can, and their whole marketing campaign was the silver bullet, it won't slow you down.
So one of my favorite t-shirts, and it has a can of Coors Light, the silver bullet, it says when it comes to network security, this is the only silver bullet.
And one of the jokes I always like to say is, if you're not going to go in and do defense in depth, if you drink a lot of the silver bullets, at least you'll feel better about the problem.
Alright, so that's your other solution.
And prevention is ideal, but detection is a must.
You can't go in and prevent all attacks, and in cases where you can't prevent an attack, you must detect it in a timely manner.
And if you don't want to follow those four rules, there's a much simpler rule you can do.
The simpler rule is drink and pray.
If you don't want to do it correctly, drink a lot and pray and hope bad things don't happen.
But knowing your system, taking away access, multiple levels of defense, and prevention and detection together will keep you secure.
That's my contact information.
And how's that for finishing right on time at 520?
Are there any other questions?
I think we have a few minutes for questions, otherwise I can take some afterwards, or feel free to email me if you have any questions or comments.