Vulnerability and Attack Surfaces

0:06Hello and welcome.

0:08My name is Keith Barker.

0:09And in this set of videos, you and I

0:11get to chat about vulnerabilities, or weaknesses,

0:14and attack surfaces where vulnerabilities

0:16could be compromised.

0:17So an attack surface is, pretty much,

0:19if we boil it down, any time we have data, information that's

0:23moving into or out of the system, over a wired network

0:26or a wireless network, through an app or what have you,

0:28that's a potential attack surface

0:30if we have a vulnerability.

0:31And if an attacker finds that vulnerability or discovers it,

0:35they could leverage an exploit and compromise us with that.

0:38So in this set of videos, I'd like

0:40to talk about vulnerabilities and attack surfaces

0:42and also where we should look for him.

0:44Because it's not just for breakfast anymore, meaning,

0:46it's not just on-prem at our facilities.

0:48If we have cloud services, we're not

0:50exempt from attack surfaces.

0:52We need to be aware of that as well.

0:53I also want to share with you some techniques and programs

0:56that we could follow that help reduce our vulnerability,

0:59reduce our risk, and make us more secure overall.

1:02So I look forward to this journey together with you.

1:04And in the next video, I'd like to continue

1:06by taking a look at vulnerabilities that are not

1:08just on-prem, but also vulnerabilities as they exist

1:11in cloud services as well.

1:13And we'll tackle that in the next video.

1:15So I'll see you there in just a moment.

0:00A lot has changed over the years.

0:03That's absolutely true.

0:04But the concept of vulnerabilities and threats,

0:07they're still there.

0:08They're just getting more and more prevalent.

0:10In the old days, we had to buy a physical server,

0:12put it on the operating system, install the applications,

0:16then set them up either locally or in a rack in a data center.

0:20Now, today, we have more options now,

0:22including cloud-based services and on-prem,

0:25meaning, having our gear in a local data center.

0:28And a vulnerability, when we boil all down,

0:30it's just really a weakness that could be, again,

0:34those "could be" compromised.

0:35And an exploit is the thing that's

0:38going to take advantage of the weakness.

0:40And the risk is the likelihood that it's all going

0:42to happen, resulting in a loss.

0:44An example would be this.

0:45Let's say we have an application that interacts with a SQL

0:49database on the back end.

0:50And there's no input validation on the data that's

0:53provided by the users, such as their username and password.

0:57So the application is not doing any checking whatsoever,

1:00looking for wacky characters or slashes

1:02or less than or greater than symbols or dashes

1:04or anything else.

1:05It's not checking any of that.

1:06Now, the vulnerability is that an unauthorized person,

1:10if they do a SQL injection attack,

1:12they could view or modify or even

1:15delete the entire database.

1:17And the exploit would be the attacker using a tool that--

1:20first of all, they discover the vulnerability.

1:22That it exists.

1:23And then they use some tool to compromise our data.

1:27And what I'd love to do is demonstrate

1:28how easy it would be for a hacker

1:30to compromise a system if the application that they

1:33were using is vulnerable to an injection attack.

1:36Now, this web page here is courtesy

1:38of OWASP and their Broken Web Application Project.

1:42Every year they come up with a whole list of the top 10 web

1:45application vulnerabilities and how to prevent them

1:48as you're writing code.

1:49But this application and this set of applications

1:52is intentionally weak and has problems.

1:55So if we wanted to log in, now, normally,

1:57if you want to log into something,

1:58you'd click on Login.

2:00You'd supply a username, like, Keith or whatever.

2:03Let me take off the caps lock there.

2:05I'm yelling.

2:05Like, Keith, and then I'll put in my password.

2:09Press Enter.

2:09And oh, bummer.

2:11The account doesn't exist.

2:12Now, just that alone, by saying the account doesn't exist,

2:17that's not good because an attacker, if they're

2:19doing an attack against this application,

2:21could just go over and over again

2:22just looking for valid usernames,

2:25let alone whether or not the password is correct.

2:27And then if they have a valid username,

2:29then they can further go ahead and try

2:31to attack the password with a password cracking attempt.

2:33Or if they've done some reconnaissance

2:36and they know that there is an injection flaw based

2:40on input validation or the lack of input validation,

2:43it's possible to log in without even

2:45providing a valid username.

2:46Check this out.

2:47If we go to OWASP here and go to Injection SQL,

2:51and then bypass authentication, here it's

2:53going to give us tips on how we could go ahead and do

2:56a bypass of the authentication.

2:58So we click on Help Me!

2:59It talks about SQL injection and how some of their attacks work.

3:02I'll go ahead and close that.

3:04And then over here, if we click on Hints,

3:06and we click on SQL Injection, here it

3:08talks about one way of bypassing authentication.

3:11And that's by taking a single open quote, space, or space 1

3:15equals 1, which is--

3:17does 1 equal 1?

3:18Yes.

3:19And then a space and then two dashes.

3:21And I'm going to just copy that.

3:22And I'm going to put it in Notepad.

3:24So I'll go ahead and paste there, and make

3:26that a little bit bigger, too.

3:27And then I'm going to take that because I want it

3:29without any kind of special formatting

3:31that the HTML may have given me.

3:32I'm going to right-click on that, copy it.

3:34And let's go back and log in.

3:36So on the login page here, instead

3:38of putting in a username, I'll just

3:40go ahead and right-click, paste in the password field.

3:43And basically, because of lack of input validation,

3:46this application is going to be basically tricked

3:49into allowing me to log in.

3:51Even though I didn't supply a username,

3:52it's going to have me log in.

3:54So I'll click on Login.

3:55My browser says, do you want to save your password?

3:59Doesn't matter.

3:59I can use that injection attack again.

4:01And check it out.

4:02We're now logged in as admin on this application.

4:06So an attacker could discover, based on this application,

4:10that it has a flaw, and then exploit it

4:12by actually logging in with that flaw

4:14or using an application that logs in.

4:16And then once they're logged in as admin, who probably

4:19has full access to the system, this application

4:22has now been compromised by the attacker based on an injection

4:26flaw that the hacker took advantage of.

4:28So as we consider vulnerabilities,

4:30a weak application that doesn't do the proper checks

4:34is absolutely an attack surface.

4:35And so if you want to put a pretty broad stroke on it,

4:38an attack surface is the sum of all paths for data

4:42in or out of our system or application.

4:45And as a result, we need to consider that when

4:48our systems are running on other people's gear

4:50as well, as in the case of cloud services.

4:52So a server may have network connectivity, as I mentioned,

4:55either via wireless or wired.

4:57That same server may have physical ports,

5:00such as USB ports.

5:01And the server may interact with many other systems

5:04and back-end servers using APIs or application programming

5:07interfaces.

5:08So all of these paths into and out of the server

5:11are potential attack vectors, collectively referred to

5:14as the attack surface.

5:15Now, when we're using cloud services,

5:17somebody else is taking care of the physical gear,

5:21or depending on the type of service,

5:23perhaps even responsible for all the applications and services.

5:27An example would be cloud-based storage as a service

5:30that we might use.

5:31So we think, oh, somebody else is handling all that.

5:33However, we still have a lot of responsibility

5:36and should be concerned about weaknesses,

5:38aka vulnerabilities.

5:40Because if somebody steals our files, what are the risks?

5:43And so solutions to help protect the data is to use encryption.

5:47So that way if the information is stolen,

5:49the attacker would not have the keys to unlock the data.

5:53And many of the same on-prem vulnerabilities

5:56also affect cloud-based systems and services.

5:58And besides, cloud-based systems may

6:00introduce new vulnerabilities.

6:03So here are some questions that we would probably

6:05want to ask for both on-prem as well as cloud services.

6:09So here are some of the questions we should ask.

6:11Where is the data geographically being stored?

6:14Is it stored in the same state or country that we live in?

6:18Or is that data required to reside

6:20in a specific geographic location?

6:22Another question would be, how is it backed up?

6:24And are we doing full backups and then differential

6:28or incremental backups?

6:29And have we tested it?

6:30And that's critical to both know and test

6:33because we can't really be sure that data backup is functional

6:37and working until we test it.

6:40And we should test it periodically, perhaps every six

6:42months or once a year.

6:45I was doing some work for a bank that had a fault-tolerant disk

6:48subsystem.

6:49And I asked them because they were telling me about it.

6:51I said, are you sure it's fault-tolerant?

6:53And they said it was.

6:55So after scheduling some downtime and doing a test,

6:58it was discovered that there was a misconfiguration.

7:01And a loss of any one drive caused the failure

7:04of the whole system, even though it

7:05was supposed to be a rated level five storage system.

7:08The moral of this story is that testing

7:11can help verify functionality, including

7:14when something has changed.

7:15So an example is any time there's

7:17an update or a patch or some modification,

7:20it's wise to test it in a test environment

7:23prior to rolling it out into production.

7:26So another great question to ask is,

7:29which security vendors-- we're using cloud services--

7:31which security vendors and methods are in use?

7:34And do those security measures work

7:35to protect the data against the most likely vulnerabilities

7:39and exploits that we're expecting?

7:41And many applications and systems

7:43use application programming interfaces or APIs

7:46to interact with other systems.

7:48An example would be network automation,

7:50one of my favorite things, where we use a controller to interact

7:54with all the network devices.

7:55And they use APIs to do that.

7:57So the negative side is if there is a weak or missing security

8:02regarding the APIs that are used,

8:04then it would be possible for an attacker

8:06to use those same APIs to compromise

8:08our network with our own APIs.

8:10And that leads to the next question regarding

8:12which API methods are in use.

8:15Are they requiring appropriate authentication?

8:17And remember, the attack surface is the sum

8:20of all paths for data into or out of a system or application,

8:24including APIs.

8:26Now, what else should we be considering?

8:28Oh yeah, another great question for security

8:31is what is the underlying OS, the operating system?

8:35And are there host-based based or network-based firewall

8:37services available to protect it?

8:39Because a lot of times, we might have

8:40a system that is built on top of some other operating system.

8:44And if that lower level operating system

8:46has a vulnerability that we aren't paying attention

8:49to because we just forgot about it,

8:50that would be important to know about.

8:52Another great question to ask is what encryption methods

8:55are in place, if any, on our systems and on our data?

8:58And that includes data in transit,

9:00going over the network, and data at rest.

9:02And also, regarding availability,

9:05what are the fault-tolerant options or high availability

9:08options that we have for our systems and for our data?

9:10And do they work?

9:12That's another critical test.

9:13So in short, for on-prem or cloud services,

9:16we want to know the answers.

9:17We want to ask those questions and know the answers

9:19to those questions with an eye towards what

9:21types of vulnerabilities and associated risks

9:25we may encounter as a result of those vulnerabilities.

9:28Now, even with proper precautions in place,

9:30a compromise may occur by a brand new vulnerability

9:35or a recent attack that is not yet known

9:37to the general public.

9:38And that's known as a zero day attack.

9:40And that's what we get to talk about in the next video.

9:42So I'll see you there in just a moment.

9:44Meanwhile, I hope this has been informative for you.

9:47And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:06We may have multiple layers of defenses in place, including

0:10antivirus or anti-malware software,

0:13both on hosts and servers.

0:14We may have next-generation firewalls-- grrrr--

0:17with application layer inspection

0:19looking for and filtering out malware.

0:22However, these devices and systems,

0:25they could miss an attack because the attack as

0:27of the time it's used may be not yet known

0:30to the vendor or the general public.

0:32And that could be a new attack method, new malware,

0:34or a combination of both.

0:36And this is referred to as a zero-day attack.

0:39And a lot of times it's helpful to use the internet

0:42as a resource tool, and also third-party products

0:44and vendors that are collecting.

0:46Like, if we have an antivirus or anti-malware company that

0:50has thousands or hundreds of thousands of devices

0:53listening to the network, looking for malware

0:55and viruses, and so forth, and then reporting it,

0:57it'd be awesome to leverage some of that.

0:59And part of that is proprietary.

1:01And then part of that is open source intelligence.

1:03This website, which is talosintelligence.com,

1:06is from Cisco Systems.

1:08It is their cloud intelligence ARM

1:10that they integrate in many of their products.

1:13They're just one of the vendors that do it.

1:14Checkpoint does it.

1:16Palo Alto does it.

1:17And other companies do it as well.

1:18But one of the features they have here under Vulnerability

1:22Information is they've got options

1:24for zero-day vulnerabilities.

1:25And that way it's a place we could

1:27go to learn more about zero-day or brand new vulnerabilities

1:30that are hot off the press.

1:32And if we scroll down a little bit--

1:33I'm trying to make this a little bit bigger--

1:35and if we scroll down a bit and click on View All Zero-Day

1:38reports, so here it has zero-day reports

1:41and disclosed vulnerability reports.

1:43And that's why it's so important to have defense in depth

1:45and multiple layers of security, and not just rely

1:48on the attitude of, oh, it's crunchy

1:50and hard on the outside like a firewall

1:52and then soft and chewy on the inside

1:54because so many attacks happen inside

1:57because once an attacker compromises the network

1:59and gets in, or does social engineering and compromises

2:03the human and gets in, they can then

2:05use that device that they've compromised and pivot.

2:08And they can move laterally and find other devices

2:10to compromised and then continue the attack.

2:13So it's important to identify our vulnerabilities that we

2:15have, that we know about.

2:17Put the appropriate countermeasures,

2:18which often involve hot fixes or patches or devices

2:22in front of our systems that are protecting them

2:24from the incoming attacks.

2:25And that's referred to as mitigation

2:27or defending or putting a control in place

2:29to help compensate for the vulnerability.

2:31So if we can get rid of the vulnerability altogether,

2:34that's awesome-- best option.

2:36But if we can't completely get rid of the vulnerability,

2:38we also might have some other type of a control,

2:40like, a firewall that could help defend

2:43against the vulnerability that the system or the application

2:45or the network has.

2:47So here under Disclosed Vulnerability Reports,

2:49if we just grab one and click on it,

2:51it'll give us more details about it,

2:52including the CVE number, which stands for common vulnerability

2:56and exposures.

2:57And then we can scroll down for additional information

3:00about this vulnerability.

3:01And so if we had Linux, for example, in our environment,

3:04a certain flavor of Linux running

3:05Apache and a certain flavor of that,

3:08and then there was a new vulnerability discovered,

3:10hot off the press, regarding that, we'd

3:12want to take steps to put in a countermeasure

3:14to help protect that system against that vulnerability.

3:17And then eventually, when a patch is created and released,

3:20we'd want to apply the patch, which,

3:22again, reduces or removes the vulnerability on that system.

3:25So the concept of a day-zero or zero-day attack

3:28is that nobody knows until after the attack occurs.

3:31And then the steps are taken to correct it.

3:34And that, again, is why having defense in depth with firewalls

3:37and intrusion prevention systems, IPS devices,

3:40both in the network and on the critical host,

3:43and also using the concept or the idea of least

3:46privilege or least access, and having those rules in place,

3:49are essential.

3:50And that way the user isn't helping

3:51to propagate some vulnerability just based

3:54on too many privileges that they currently have

3:57as they're logged in.

3:58While we're talking about users, practical end user

4:01training and verification that that training is taking place

4:04and that they understand, that is also

4:05critical to keeping our environments absolutely secure.

4:08Now, one of the reasons, in general,

4:10that vulnerabilities are so prevalent

4:12is gravity, like, inertia.

4:15Like, if there is an operating system that's

4:17been deployed as part of an Internet of Things device,

4:19maybe a real-time operating system, or an older

4:21version of Linux or something that people have just forgotten

4:24about or whatever, if it just sits there and then an attacker

4:27discovers, hey, I've got a million

4:28of these Internet of Things devices that are all

4:31running this version of Linux, and it has this vulnerability,

4:34away they go because it's the default.

4:36And oftentimes, we forget about many of those things.

4:38Also, the configurations are often very,

4:41very weak because when a vendor deploys something,

4:43they want the user, the person who buys it,

4:46to be able to bring it up, get it installed,

4:48and have functionality.

4:49And their biggest concern is on functionality and not security.

4:53So one of the challenges is overcoming

4:55some of those default deployments

4:57which have a weak configuration as a default or as a baseline.

5:00And that is what we are going to talk about in the next video.

5:03So I'll see you there in just a moment.

5:06Meanwhile, I hope this has been informative for you.

5:08And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:06Hello and welcome back.

0:07So let's ask the question, what is

0:10and what causes a weak configuration?

0:13And the answer to that is a lot of the vulnerabilities come

0:16from using the default settings, including default passwords

0:19for the root or admin account.

0:21If they're not changed, they are easy to look up

0:24and they are a significant risk.

0:26And that's because rooter admin accounts have open or full

0:29permissions and access.

0:31So it's common sense, I suppose.

0:33We need to change those defaults and only use

0:35accounts with the concept of least privilege.

0:38An example would be an unsecure root or admin account

0:42with a default or no password.

0:44We definitely want to solve that by changing it.

0:46And ideally, we'd want to use two-factor or multifactor

0:50authentication to make sure that the person who's logging in

0:53is the authorized actual user and not an attacker.

0:57So this is the Exploit Database.

1:00It is such an amazing tool because it makes it very easy

1:04to find vulnerable systems.

1:06So over here on the left, if we go to Exploits,

1:08we can do a search for, let's say, Linux.

1:13And then press Enter.

1:14And it's going to basically sort the output here

1:17based on the word "Linux."

1:18So we can search for virtually anything.

1:20And then to make it easier to find vulnerable systems

1:23after we have identified vulnerabilities here

1:25with the Exploit Database, over here on the left, we have,

1:27GHDB, which is the Google Hacking Database.

1:30So this is not about hacking Google.

1:32It's simply how to use Google search

1:34terms to drill down and find via a public search engine,

1:39or I should say, Google search engine,

1:41how to find vulnerable systems based on the criteria

1:44that we're looking for.

1:45So let's do a search for "default password" and press

1:50Enter.

1:51So by doing a search for a default password,

1:53it's showing us these, basically,

1:55Google searches that we could do to help discover where

1:58those are on the internet.

2:00So I'm going to go ahead and-- ooh, that's--

2:01I'm not going to use these.

2:03I'm just going to go ahead and look at it.

2:04But here is the actual search--

2:06filetypedoc inurl looking for "gov" in text "default password

2:10is."

2:11So I'm not going to click on that.

2:12If I did click on that, it would actually

2:14take me to the Google search and do it for me.

2:17And then give us a list of all the hits

2:19where it found that, where the file type was doc

2:22and the inurl had gov in it.

2:24And it had default password is.

2:26And then it has a description down here,

2:28saying pages from gov domain with default passwords assigned

2:31in their systems.

2:32Also try "pdf" and "txt" in the file type.

2:34Some of the default passwords being-- oh my gosh.

2:36OK, so I'm not going to launch this

2:38because I don't want to even have a history of my search

2:41record of looking for that.

2:42But I wanted to share with you how easy it is to, first

2:46of all, identify vulnerabilities with the Exploit Database

2:49and then have the Google Hacking Database provide

2:52a method for easy retrieval and lookup of those devices

2:56to further push along the attack.

2:58So in short, we never want to have an account with a default

3:01password, especially if it's accessible

3:05over the public internet.

3:07Now, another reason for a bad or a weak config is just an error.

3:10We just misconfigured it.

3:12And to solve this, we can build and use and verify

3:15a baseline for our settings and configurations

3:18for any new systems.

3:19And that way, if we're ever rolling out

3:21a new server or mobile device or a printer or anything else,

3:24we can use a default configuration

3:27that we've tested and verified that doesn't accidentally

3:31include some vulnerability based on a default of that system.

3:35Now, another challenge is that we

3:36might be using a security protocol that's

3:38old or weak itself or broken.

3:41For example, WEP, Wired Equivalent Privacy--

3:44for wireless, we don't use that anymore

3:46because it's weak encryption and it

3:48can be compromised due to a wimpy initialization

3:51vector that can include plain text for the attack.

3:54And as part of the attacker eavesdropping,

3:56they could figure out what the key is and basically get

3:59on our wireless network.

4:00So we don't want to use any kind of broken or old or "wimpy"

4:04security protocols.

4:05Now, another challenge would be if we're not even

4:07trying to encrypt.

4:09That's a problem.

4:10So we shouldn't use insecure or unsecure protocols

4:13if we're using sensitive data.

4:15So data in motion over network or data

4:18at rest on a storage device, if we're careless,

4:20we may allow clear text sending of data or storing of data,

4:24and if it includes usernames or passwords

4:27or other sensitive information, that's a huge problem.

4:29In fact, let me show you how easy

4:31it would be for an attacker to compromise based

4:34on using the wrong protocols.

4:36So let's use this network.

4:38And let's imagine that-- in fact, we

4:39don't have to imagine too much because here

4:41is a router named R1.

4:43Here is the CLI for it.

4:45And if we wanted to communicate over to R2,

4:46we want to do a remote session for a CLI

4:49over at R2, command line interface,

4:51we could use a couple of different protocols.

4:53One would be Telnet.

4:54And Telnet uses TCP port 23.

4:57And that's not the problem.

4:58The problem is that Telnet is an insecure protocol.

5:01It doesn't bother encrypting anything.

5:03And that way, if there's an eavesdropper who's

5:05listening to our packets go back and forth, if we're

5:08sending a password, they've got the password.

5:10If we're sending our config, they see our config.

5:13And as a result, our data integrity

5:15has just been compromised.

5:17In fact, let's have some fun and do a demo.

5:19Let me go ahead and capture the traffic

5:21as it's going between R1 and R2.

5:23So here in my environment, I'll just do a capture.

5:25And I'm going to capture-- what interface is this?

5:27Gig 0/1.

5:28We'll do a capture of interface gig 0/1.

5:32And that capture is now running.

5:34Great, I'll put it over here--

5:35fantastic.

5:36And with that capture running, we're

5:38basically eavesdropping on all the network traffic.

5:40Then from router 1, let's go ahead and do a telnet over

5:44to router 2.

5:44Let me just check an IP address that we can reach on R2.

5:47So show ip interface brief.

5:49This is on a Cisco router.

5:50I just want to verify what addresses we have.

5:52So we have an address of 2.2.2.2.

5:53I just want to make sure from R1 I can reach that.

5:56So I'm going to do a ping real quick.

5:57So let's ping to 2.2.2.2.

6:01Oh, unreachable.

6:02OK, let's go-- that's not going to be good.

6:06Let's go for an address that we can reach.

6:08Let's go, or on R2, let's try 25.2.2.2.

6:11So we can't really telnet in unless we have connectivity.

6:14So let's try 25.2.2.2.

6:16Going back to R1, let's ping 25.2.2.2.

6:20All right, that looks better.

6:22And let's telnet over there.

6:24So we'll telnet to 25.2.2.2.

6:27Ah, connection refused. (LAUGHS) Hence the demo.

6:32Let me set up R2 to allow telnet traffic to go ahead

6:37and come back in.

6:37So let's do a show run.

6:41I'll say section line.

6:43I just want to take a look at the configuration.

6:44So basically, R2 has to be willing to allow

6:46a telnet session.

6:47And right here it's saying that on the VTY lines, that's

6:50the logical way that this router allows incoming SSH or telnet

6:54sessions, it says transport input none.

6:56You can't come in.

6:57So we'll fix that real quick.

6:59So we'll go to line vty 0 through 4,

7:02which is the five VTY lines.

7:04And we'll say transport input.

7:07And we'll say all.

7:09Basically he's now willing to take everything.

7:11All right, with that in place, let's go back to R1,

7:13hit the Up arrow key.

7:14We'll telnet over.

7:15Oh no. (LAUGHS)

7:19All right, I will take a breath.

7:21OK, let's make sure we can log in.

7:23So over on R2, let's create a user account, username bob.

7:28Privilege level 15, which, in the world of Cisco,

7:32is King Kong rights.

7:34And we'll say his secret, which is like his password,

7:37is going to be Cisco!23.

7:40Fantastic, so top secret information right there.

7:43And let's also go to line VTY 0 through 4 and say login local.

7:51All that means is that when somebody

7:52does connect on the VTY lines, it's

7:54going to prompt for a local user, Bob.

7:57And then Bob can supply his credentials.

7:59All right, now That we've done that, let's go back to R1.

8:01Hit the Up arrow key.

8:02All right, there we go.

8:03Now, if we're using an insecure protocol, like,

8:06Telnet between R1 and R2 and an eavesdropper

8:09is there, which, we are.

8:10We're eavesdropping.

8:11We're listening.

8:11Anything I type in-- so I'm going

8:13to put in Bob's username and his password.

8:17You notice how Bob, B-O-B, when I type those characters,

8:20it reflected back.

8:21And that's because I typed in B and the server

8:24the telnet, the R2, echoed back and sent back that character

8:28to my screen.

8:28And then did it for O and B, too.

8:30And then when I put in the password,

8:32it didn't echo that back to the screen

8:33because it doesn't want to put it on the screen for anybody

8:35looking to see.

8:36But I have logged in.

8:37If we type in who, it shows me that I'm currently logged on

8:40on logical VTY line 0.

8:42My username is Bob and I'm coming in from this address

8:45of 15.1.1.1.

8:46Now, the problem within secure protocols

8:49is that they are totally wide open, like opening the kimono.

8:53So anybody who wants to eavesdrop now

8:55has access to that password.

8:57So if we go back here to our packet capture,

8:58and I'll bring that full screen and make

9:00it a little bit bigger.

9:02All right, and I'll stop the capture.

9:03And it's going to do a quick search for telnet.

9:05So I'm just doing a display filter, which effectively

9:08is going to only display or show to the screen out

9:11of all the 251 packets it's collected,

9:14just those that are related to the telnet application.

9:16Let me make it a little bit smaller there-- great.

9:18And then we can just grab any one of these and just

9:20right click and say Follow.

9:23And follow the TCP stream.

9:26And that's going to show us the whole conversation right there.

9:28Check this out.

9:29I made this a little bit bigger so we can see it.

9:31But right here, here is where I'm

9:33typing in the username of Bob.

9:34So the red characters are what I typed.

9:36And then the blue characters are being echoed back

9:38to the screen.

9:39And then when I put in the password, Cisco!23,

9:42right here in the packet capture.

9:44So using insecure protocols are dangerous if we have any type

9:48of sensitive information.

9:50So let's take a moment and talk about insecure protocols.

9:52In fact, let's go to this camera and do it.

9:55There we go.

9:55Much better.

9:56OK, so insecure protocols over a network

9:58would be anything that doesn't have encryption of the data

10:02or at least encryption of the sensitive data that's

10:04being sent across.

10:05So HTTP, which is TCP port 80, insecure

10:09by default. Telnet, TCP port 23--

10:12and there's nothing that's miserable or weak

10:14about the actual port numbers.

10:15It's just that's the well-known ports for those applications.

10:18So HTTP, Telnet, FTP, trivial file transfer

10:23protocol-- all weak protocols that

10:26have no encryption whatsoever.

10:27And that's why if we have sensitive information that we

10:30need to protect for remote access, instead of Telnet,

10:33we'll use SSH.

10:35For file transfers, instead of using FTP and TFTP,

10:38we'll use file FTP secure.

10:40Or we can use SSH versions of FTP, which is SFTP.

10:45And for our web traffic that needs to be secure,

10:47we'll be using HTTPS, which behind the scenes

10:50is using some flavor of SSL if it's really, really old,

10:54or a more current flavor of TLS, transport layer security.

10:57And as I bring over the mic, you and I

10:59are going to have separate sets of videos regarding

11:02TLS and HTTPS and what goes on behind the scenes

11:04to make that happen.

11:05But the gist here I want to talk with you about

11:07is that we are introducing vulnerabilities on our networks

11:11if we are ever sending or moving any type of sensitive data

11:15within secure protocols that don't encrypt that data as it's

11:19being sent over the network.

11:21Now, another example of a weakness in an attack

11:23vector which could be used to compromise the system

11:26is when that system has open ports or open services that

11:30aren't needed, but yet they are listening.

11:32That means if anybody connects, like,

11:34a web server, if it's sitting there running web services,

11:37it's listening and paying attention

11:39to the well-known port for HTTP, which is 80.

11:42Or if it's running TLS, it has the open listening port of 443.

11:45So you know what I'd like to do?

11:46Let me share with you how easy it is to identify on a system

11:51the open ports on that system.

11:53And one of the tools that we can use,

11:54and this is available on Windows and Linux--

11:57the options are slightly different depending

11:59on the platform-- but if we did a netstat

12:02and then a dash help (CHUCKLES) --the reason I'm chuckling

12:08is because I typed in dash hlep.

12:09And I thought, aw, you need help.

12:11Anyway, there's the options for netstat.

12:13And so we could actually-- one of these options

12:15is listening ports, display listening server sockets.

12:19So if we did a netstat and then a dash l,

12:23that would help reveal to us some of the listening ports.

12:25So right here, it has SSH, which is TCP port 22.

12:30It also indicates it has some listening ports for IPv6

12:33as well that's showing here.

12:34And it also shows here for IPv4 TFTP, which is UDP port 69.

12:39So part of the idea of hardening a device

12:42is to remove unused stuff.

12:45Think of it like clearing out your closet with stuff

12:47you've never needed or haven't used in a long time.

12:50The same principle applies to a system

12:52because this stuff that if we leave

12:54the ports and services open, it could provide an attack vector.

12:57So attack vectors could include apps and services that are not

13:02needed and ports that are not used but are still

13:04open or "listening."

13:05And so anytime we have non-required open ports

13:08and services, they should be closed and disabled.

13:11And that's going to reduce our attack vector.

13:13We could also reduce our attack vector on a system

13:15by verifying that it's booting up cleanly.

13:18For example, when a computer first gets its power,

13:21there's a power on self-test.

13:23And there's some firmware that's used.

13:25And it boots and it reads the first little things

13:27off the hard disk or the solid state drive, whatever

13:29it's using for storage.

13:30And then it continues on booting.

13:32If we can verify each of those steps

13:34by either using hashes or checksums

13:37and verifying each step along the way,

13:39we can refer to that as being a secure boot.

13:41And as far as USB ports and other data paths it might have,

13:45we could secure those, maybe disable them on the system

13:48so that even if something is plugged into a USB port,

13:51it's not able to be used.

13:52And that helps protect that device

13:54by hardening it, again, by removing unused services

13:57and locking down those things that are not needed.

13:59So those are all examples of hardening a device,

14:02making it less vulnerable.

14:03Now, sometimes, we introduce our own vulnerabilities

14:05and our own weaknesses.

14:06And we inflict them on ourselves,

14:08like, this finger right here.

14:10I slammed it moving some furniture

14:12about a month and 1/2 ago.

14:13It no longer hurts.

14:14But it's a self-inflicted wound.

14:16Now, sometimes, we introduce vulnerabilities

14:19via products and services that we purchase from a third party.

14:22And these resources are often referred

14:24to as part of our supply chain.

14:26And if they have vulnerabilities and we use their products,

14:29now we have those vulnerabilities.

14:31And so in the next video, let's take a look

14:33at third-party risks and how we can

14:35help mitigate those or reduce those whenever possible.

14:38Meanwhile, I hope this has been informative for you.

14:40And I'd like to thank you for viewing.

0:07Very few companies are islands.

0:09We all use products and services from other vendors,

0:12and they are considered to be part of the supply chain.

0:15And that's true whether it's goods or services

0:17that we use from them.

0:18And third parties get introduced vulnerabilities

0:21as part of the goods or services that we use from them.

0:24So what could possibly go wrong?

0:26Well, here's a scenario.

0:27Let's imagine a vendor's management software

0:30used in our network.

0:32We purchased it.

0:33We installed it.

0:34We use it.

0:34And it's part of our supply chain.

0:36And let's further imagine an automated software update

0:39that unfortunately hackers have compromised.

0:43And now, we have when we do the update,

0:45we're going to have a remote access Trojan installed,

0:48and we're toast.

0:50So part of the solution is to use proper vendor management

0:54where we can prepare for and analyze factors such as,

0:58how does this product integrate with our system?

1:01And how and where do our systems interact?

1:04And what are the risks?

1:05Now unfortunately, we may buy a product

1:07and not realize the lack of vendor support

1:10until it's too late.

1:11So it's essential to understand what type of support

1:14we have from the vendor after we integrate their product

1:17or service in our environment.

1:19And another consideration is about code development.

1:22Are we hiring a third party company?

1:25Are we outsourcing the code development?

1:27And what code reviews are we doing

1:30that confirms that secure methods and best practices

1:33are in play and that no back doors exist?

1:36Now, another question, especially if the third party

1:39is storing or working with our company data, is data storage.

1:43Now, what are they holding?

1:45And where do they keep it?

1:46And how do they protect it, et cetera?

1:48So when we do an IOC, an indicator of compromise,

1:51let's say I have some event that happens.

1:52We need to report it.

1:53We're not just going to release all the data.

1:56We are going to sanitize that data first

1:58to avoid exposing or releasing any sensitive data.

2:02Now, another vulnerability that plagues most organizations

2:05is just keeping up with security updates, and hop fixes,

2:08and patches.

2:09And so what I'd like to do in the next video

2:11is talk about vulnerabilities that we

2:14may inherit by simply having an ineffective or a lacking patch

2:19management program.

2:20And we'll talk about that in the next video in more detail.

2:22Meanwhile, I hope this has been informative for you,

2:25and I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:06So let's begin with a question.

0:08Does software ever need to be updated?

0:11I imagine you're saying, Keith, of course.

0:13Yes, it does, all the time.

0:14That's absolutely true.

0:16However, and unfortunately, many companies

0:19have improper or weak patch management

0:22and update management simply because they have not

0:25thought it through.

0:26They have not asked themselves the questions,

0:28such as, what may need to be updated or patched?

0:30Or is it even possible to do an update or a patch?

0:34And that could apply to firmware, real-time operating

0:38systems, or our general purpose operating

0:40system, or applications.

0:42So a great example of things that we forget to, or cannot,

0:46update stem from legacy systems and platforms.

0:49And that includes firmware, embedded OS,

0:51as well as the apps that run on those.

0:52Let's think about how we onboard a new device.

0:55If we have an internet-connected device with a vulnerability,

0:59whether it's the firmware or the BIOS or the operating system

1:03or its config, whatever it is, that means that even a script

1:06kiddie, if it's public-facing, could

1:08be able to compromise that system,

1:10let alone a professional or a state actor.

1:13So an effective patch management program or system

1:16is going to include a few things to make it work.

1:19Number one, we need to have an up-to-date inventory

1:21of all of our systems and all of our network devices.

1:24And that way, when new patches or updates

1:26apply to a system, first of all, we know where it applies to.

1:29And then, before we apply it, we should have rigorous testing.

1:32And then, using change control, rollout a patch or an update

1:37into the production environment after all the change control

1:40and testing has been done.

1:41Now, frequently, the testing is performed

1:43in a virtualized environment.

1:45And that way we can replicate, as closely as possible,

1:48the production environment.

1:49See, our goal is to identify any surprises regarding

1:53functionality or security in the testing phase

1:56before it goes into production.

1:58So the necessary steps for implementing

2:00an update or a patch would be to, first of all,

2:03identify the systems that need it.

2:05An example would be servers running a specific version

2:08of Apache, or hosts that are running a particular operating

2:11system version.

2:12And based on the update, we'd want to prioritize and apply

2:15the updates or the patches, whatever it is we're applying,

2:18to the most critical systems and the most vulnerable systems

2:21first.

2:21Now, part of that decision making process

2:23would be to identify the risk or the potential loss,

2:27which is going to help steer us to the most critical systems

2:29first and get those updater patched.

2:31Now, once we've identified the critical systems or the people

2:34who get the patches first, that patch or update,

2:36it needs to be thoroughly tested first before being rolled out.

2:40I remember one of my early experiences,

2:42where I didn't do thorough testing, and it was a disaster.

2:47There was a new update-- this was back in the '90s.

2:49There was a new update of a network driver

2:51for a vendor's card, a network card, that we were using.

2:54And this new update was supposed to give us

2:56like a 30% or 40% more throughput-- woohoo!

2:59We were like, woo, go, go, go.

3:00Well, unfortunately, once we did the update,

3:03it didn't really have the opportunity

3:05to provide us the advanced and increased performance

3:08because the system had a panic condition.

3:10Think of that, like similar to a blue screen, which

3:12means the server completely stopped working.

3:15So that was many years ago, but I've never

3:18forgotten that lesson to always test in a practice environment

3:22first before rolling it out into production,

3:25no matter what it is.

3:26So that concept of testing should

3:28apply to updates that are supposed

3:30to provide additional functionality

3:32as well as updates that are supposed

3:34to be fixing a security issue.

3:36Now, sometimes a patch or an update,

3:37it can't be tested as quickly as we need to, or there may be

3:41other situations where we cannot provide an update to a critical

3:44system.

3:45In those cases, we would want to consider

3:47some type of a countermeasure or another workaround

3:51that can mitigate the risk.

3:52So until we apply the patch, what we could do

3:54is we could restrict certain traffic patterns or protocols

3:58from ever reaching the device or the server by putting up,

4:00for example, a firewall in between the users

4:04and the server itself.

4:05Now, if there's already a firewall there,

4:07we could just possibly tweak or tune the access controls

4:10on that firewall to help mitigate or temporarily

4:13stop the risk or the vulnerability

4:15from being leveraged by an exploit.

4:17And that would be a temporary fix until we got the patch

4:20or update on the actual server, which

4:23then removes the vulnerability.

4:24So countermeasures are a great way

4:26to help mitigate risk while we're

4:28waiting for a full solution.

4:30And now, over the years, I've learned a lot,

4:31and I've come to really appreciate change control.

4:34And as a part of change control, there

4:36should be a documented backup and restore

4:39plan that should be thought through and available.

4:42So let's imagine that we have a change window that's

4:44one hour in length.

4:45So it's been communicated.

4:46It's all good.

4:47And let's also imagine it takes 20 minutes to restore

4:51if something goes bad.

4:51So that means at 40 minutes in, we

4:55would have to make a decision to commit and go forward or roll

4:58it back to its previous state.

5:00So the benefit of having all that documented is that there's

5:03less ambiguity, there's less confusion in the event we do

5:07need to roll it back.

5:09Now, many operating systems that users are familiar with

5:12perform auto updating.

5:14So let's suppose that you and I are in a company that

5:17doesn't want those auto updates to happen

5:20without in-house testing automatically.

5:22In that case, what we could do is

5:24we could set up the configuration

5:27so that those devices do not--

5:28I repeat-- do not pull from the public repositories regarding

5:32security updates or other patches,

5:34and then our workstations could point to an on-prem, a local,

5:36repository that we manage and control.

5:39And then, what we could do is we could facilitate updates

5:42and patches after we do our in-house testing regarding

5:46those updates and patches.

5:47And so it's kind of a double-edged sword,

5:48because if we're going to test them,

5:50that means those patches and updates may

5:52have to wait a day or two or more

5:54before they get on our systems.

5:55So at the end of the day, if we boil it all down,

5:58one of the benefits of having automated updates, including

6:01operating systems and browsers and virus definitions,

6:04et cetera, is that we have an excellent possibility

6:08of keeping current, which is really important,

6:10and thus, reducing risk.

6:12So in a perfect world, we want all of our systems updated

6:16with any security patches as soon as possible while,

6:19at the same time, not causing any loss of functionality

6:23by applying those patches.

6:25Now, another important thing to keep in mind

6:26is that when we're getting new software

6:28and we're going to deploy it, test it and then deploy it,

6:31when retrieving updates and patches from a vendor,

6:35it's critical to validate that we don't have a compromised

6:38version of that software.

6:40And so one way of verifying our updates

6:42is to download, or at least look at,

6:45the hash values that are calculated and published

6:48from the vendor's official website.

6:50And then, after we download, we could then

6:52generate the hash for that file and compare

6:54the hash we generated to the hash that they published.

6:57And so comparing the hash values can

7:00help us validate data integrity and help ensure

7:03that we have a correct and untampered

7:05with version of that update, because it would

7:07be super devastating if we downloaded a file that we

7:10thought we needed or wanted or would help our systems

7:13and, at the same time of installing it,

7:15because we get a wrong copy of it from an attacker,

7:18we've just injected malware onto our systems.

7:21So let me share with you an example of how easy it

7:23is to do a quick check regarding the hash value,

7:26just to make sure that the file we downloaded and are using

7:29is the actual file from the vendor.

7:31So let's imagine that we want to download a file,

7:34whether it's a patch or an update or anything else.

7:36We just want to verify that this file has

7:38been modified or tampered with by some third party.

7:42So I'm going osboxes.org as an example.

7:44And let's imagine we want to download

7:47an image for a Raspberry Pi.

7:48And so I have a VMware environment behind me.

7:51So I'm going to go ahead and just download

7:52the VMware flavor of it.

7:55And then I can download it.

7:56So I click on Download.

7:57It's going to download to my local computer.

7:59So if we wanted to verify that we got the real file

8:01and that we didn't get sidetracked and download it

8:04from a malicious source, we could actually

8:06look at this SHA256 hash right here that they're publishing,

8:09and then we could generate our own hash once we download it.

8:11And if the hash we generate matches

8:13the hash they publish, bada bing bada boom,

8:16we have data integrity.

8:17So here's another critical point.

8:19If we are downloading software and we

8:22are at a malicious website, where they're saying,

8:24oh, here's the software, and oh, here's the hash value,

8:28they could have taken the software,

8:29injected the malware in it, published it, published

8:33the hash that matches the malware-laden version,

8:35and then it would just-- it would still

8:37match because we're looking at the hash published

8:39by the attacker, and it matches the hash on the file.

8:43So we'd also want to verify that we are at a site that we trust

8:46and not at a malicious site that's publishing a hash.

8:49So in this case, osboxes.org, if we take a look.

8:52I'm right here.

8:53It says the connection is secure.

8:55I could look at the certificate to see who signed it.

8:57So it's an important piece to make

8:59sure we're at the right site, at a website that we trust.

9:01So if we wanted to compare this hash, what we could do

9:04is download the file, which I've already

9:05done to save us a few minutes, and then,

9:07using a tool on our local computer,

9:09generate that SHA256 hash and compare

9:11it, the one we generate from the hash that they're publishing.

9:15So to do that, I have downloaded that file, which

9:20is approximately 2.2 gigs.

9:22Let's just a real quick dir.

9:24There it is right there, Raspbian-2020--

9:27blah, blah, blah, blah.

9:28So let's generate our own hash value.

9:30And the way we're going to do that is

9:31with a little, teeny utility called certutil

9:33that's part of Windows 10.

9:35So we'll type in certutil space dash,

9:39and we want to generate a hash, so we'll

9:41type in hashfile space, and then we're

9:43going to put the actual file name.

9:45Now, this is--

9:45I'm going to hit r and tab it out.

9:47Because it's unique, it'll bring it down for me.

9:50And then I'm going to specify the type of hash.

9:52So they're publishing the SHA256 hash,

9:54and so what we'd want to do is generate that same hash.

9:57So we'll do sha256, press Enter.

10:00And if my syntax is correct, in just a moment,

10:02it'll just generate the hash for us.

10:04All right, so let's go ahead and a pair of few characters here.

10:07It says it's 7f3da.

10:09And the first characters here are 7f3da.

10:12That looks great.

10:13And if we scroll to the end and look at the last part,

10:17we have 6d46b.

10:20And that's 6d46b.

10:22And if we compared every single bit of that hash,

10:24they would match here as well.

10:26So what's the end game here?

10:27What's the point of this?

10:28The point is to verify that the file that we have

10:31is literally the file that was published

10:33by the vendor or a manufacturer or the website that we trust,

10:36and we are not downloading or we haven't

10:38downloaded a malign copy that has malware injected in it.

10:42So in this case, the file that I downloaded

10:44is exactly the same as the file provided because the hash

10:47matches identically.

10:48So the benefit of using a hash, which

10:50is a one-way function, where we can run the hashing algorithm

10:53against the data, that little digest it

10:56creates, that little hash it creates,

10:57if the file has not been modified or tainted or changed,

11:01the hash values are going to match,

11:02which means we have data integrity.

11:04And in the next video, I'd like to chat with you about what

11:07we can do to help prevent our attack

11:09surface and our vulnerabilities from growing

11:12by doing a little bit of management regarding

11:14vulnerabilities.

11:14And I'd like to touch on that in the next video.

11:16So I'll see you there in just a moment.

11:18Meanwhile, I hope this has been informative for you,

11:21and I'd like to thank you for viewing.

0:00Let's imagine that we have a policy regarding company

0:03workstations and the following-- that current patches must be

0:07installed, after we've tested them, of course;

0:09and local firewall has to be installed on host,

0:12has to be running; local IPS or anti-x--

0:14antivirus, anti-malware software--

0:17must be running and current on our hosts.

0:19And for our special servers, we want

0:21to verify that a list of items are in place, including

0:25minimum operating system levels, minimum patches.

0:29We want to make sure that specific ports are not open

0:32and that the systems are prepared

0:33for and resistant to many well-known attacks.

0:37All right, so for us, the question

0:38is, with thousands of devices, even if we roll them out

0:42correctly, how do we verify over time

0:45that our baselines are being followed

0:47and we aren't having additional vulnerabilities creep in?

0:49One method of doing that is a good vulnerability management

0:53program, which has, basically, the goals of identifying,

0:56removing, and when they can't be removed,

0:59mitigation of vulnerabilities.

1:01So here's an example of what we'd want to keep on top of.

1:03If we were running Microsoft Windows,

1:06we would want to make sure we're looking at their security

1:08advisories and any vulnerabilities

1:10that they're discovering in their software.

1:12So as of this recording, that's not too far in the past.

1:15And we've got for this SharePoint remote code

1:18execution vulnerability, it's got

1:20a CVE, a common vulnerabilities and exposure ID number,

1:23fantastic.

1:23So we can research it more there.

1:25It also has a CVSS score, which can help us

1:28by looking at that number to identify, OK, we have

1:30all of these vulnerabilities.

1:31Which ones do we focus on first?

1:33The answer would be our core systems and servers

1:36where we expect the most loss of the most harm.

1:39And then, of those devices, which

1:41ones have the most significant vulnerabilities exposed?

1:44Now, if we were in a shop, even a Windows shop

1:46where we didn't use SharePoint at all,

1:48this vulnerability would not be a risk to us.

1:50But the key is, whatever operating

1:53systems and applications we're running,

1:55we need to have those feeds coming to us

1:57so we can be aware of what those new vulnerabilities are

1:59and then take the appropriate steps once they pop up.

2:01And one of the tools that we have in our tool

2:03belt that we can use to help maintain our security posture

2:06is a vulnerability scan.

2:08And they are intended for us to be proactive with them.

2:10So we can perform scans to interrogate

2:13the network, the web servers, and even specific applications

2:16in an automated fashion.

2:18And so we can look at the scan's results

2:20and see if the vulnerabilities it was looking for exists.

2:23And having visibility to those known issues ahead of time

2:27allows us to do the mitigation and the protection

2:30regarding those vulnerabilities before the attackers take

2:33advantage of us.

2:34So let me share with you an example of two

2:36of the most popular vulnerability scanners

2:38out there.

2:39One of them is Nexpose by Rapid7.

2:41It is fantastic.

2:43And it's modular.

2:44So if we're doing vulnerability scans on Linux or Windows,

2:48there's modules that we can effectively

2:50plug in or remove so we're looking

2:52for specific vulnerabilities based on the platform

2:55that we're doing the vulnerability scan on.

2:57So Rapid7's Nexpose is a great, full-purpose vulnerability

3:02scanner.

3:02Another very popular vulnerability scanner

3:05is Nessus from Tenable.

3:07And again, it's also very modular.

3:09So you can plug in modules to do additional scanning based

3:12on the type of environment that you're in.

3:14So if you're in a Linux heavy or Microsoft heavy

3:16or whatever the environment is, you

3:18can plug in the modules that will

3:20be scanning for certain vulnerabilities

3:22based on those platforms.

3:23And one of the cool things about a vulnerability scanner

3:26is that they get updated.

3:27So if there's a new vulnerability that's known

3:29and it applies to a Microsoft or a Linux environment,

3:32whatever the platform is, that can become part or updated

3:35as part of the software for our vulnerability scanner

3:37to look for those specific vulnerabilities.

3:40Again, the key is to be aware that it exists

3:43so we can fix it, correct it, update it

3:45before an attacker compromises it.

3:47Other scanners, besides full-blown vulnerability

3:49scanners, can also be used to look for open ports

3:53and also identify, when possible,

3:55the actual operating system that's

3:56running on those systems.

3:58One example of a tool that can be used to scan a device

4:01and look for open ports and help identify what's going on is

4:04a tool called Nmap, N-M-A-P, and it's graphical user interface

4:08equivalent, which is called Zenmap.

4:11So here on this Kali Linux box, it

4:12is a distribution of Linux that has a lot of tools, including

4:15Nmap and Zenmap.

4:16I'll go ahead and click on Applications

4:19and then hover over Information Gathering.

4:21And then over here, I've got nmap at the CLI.

4:24We also have an option for zenmap.

4:26And that's the graphical user interface version of Nmap.

4:30So let's go ahead and launch Zenmap.

4:32And let's go ahead and do a quick scan

4:34of the entire 192.168.1.0 network.

4:39And this is in a lab environment.

4:41So I'm not doing anything in my corporate environment

4:44or anything else.

4:44Because doing a scan is considered

4:47malicious if you're not authorized to do it.

4:49So as far as the type of scan from the dropdown,

4:52I'm going to go ahead and just do a quick, just a quick scan.

4:56And click on Scan.

4:57And it'll just take a moment.

4:58It'll go out.

4:59It's going to find every device that responds

5:01and give us a list of them.

5:02And let me scooch this over just a little bit.

5:05And wow, check it out.

5:07So I've got 1, 2, 3, 4, 5 hosts that it found on this network.

5:10And if we click on Services here,

5:12it's going to show us each of the services it found.

5:14So we can click on one of those, like, HTTP.

5:17And then it gives me a list of who's supporting that.

5:20So the host at 151 HTTP has an open port

5:23if, we click on domain we've got .1 and .100.

5:27If we click on LDAP, it's going to show us

5:29that we have .100, which is my domain controller.

5:34And it's using port 389.

5:35That's the not secure version of LDAP,

5:39which, if an attacker was looking at this, that might be

5:41something they want to pursue.

5:42And then we go to SSH.

5:44It shows me I have two hosts that are supporting SSH.

5:46So if we go back to Hosts it has a whole list.

5:49If I wanted to get more information, for example,

5:51on this bad boy right here, 151, we

5:53could do a more thorough scan just on that one host address.

5:56So let's do that.

5:57We'll go ahead and put in .151.

6:00And we'll go ahead and do-- if I do an intense scan, that's

6:03going to take quite a while.

6:04Let me do a Quick scan plus.

6:07And that's going to help identify the operating system

6:10behind it as well.

6:11So with that in place, we'll go ahead and click on Scan.

6:13And again, this is just like Nmap.

6:15We could do all that with the nmap command at the CLI,

6:18get the same results.

6:19So let's give it a moment.

6:20So now that it's done its scan, it's

6:22going to come back and tell us about more details regarding

6:24that host.

6:26So let's take a look at this bad boy right here, .151.

6:29It's identified it as running a flavor of Linux version 2.6.x

6:33It's identified a whole bunch of open ports.

6:35So 22 is SSH.

6:38Port 80 is HTTP.

6:39So if this had come back and it said, oh, it's

6:41got TCP port 25 open, we would know

6:44that that's an SMTP, simple metal transfer protocol.

6:48That's the well-known port for SMTP.

6:49Or if it had port 23 open, which is

6:52the well-known port for Telnet.

6:54That would be a huge option as far as a vulnerability

6:56on that device.

6:57Or if it had TCP port 21 which is FTP another plain text

7:01protocol.

7:02So it's got some HTTPS open right here.

7:05It's also indicating the services behind it

7:08and the flavor, which would be very helpful to an attacker.

7:10So the key is, if we are doing a vulnerability scan

7:14and we have a policy saying, hey, no port 80 open

7:17or no port 23 or no port 21, especially on workstations,

7:21we could run a vulnerability scan,

7:22have it run across the network, and then

7:24as these ports show up, if they're not

7:26supposed to be there, we could then take action and shut down

7:30those ports because open ports are absolutely

7:32part of an attack surface that we don't want exposed.

7:35We don't want that vulnerability.

7:37So if we have a system and it's got open ports that should not

7:39be there, ports that are listening and waiting

7:41for an incoming connection, we'd want

7:43to remedy that to reduce our attack surface on that device.

7:47Now, another consideration is not

7:49doing damage or impacting performance

7:51in a negative way on a production system

7:54as a result of our scans.

7:56See, management frowns on a denial of service attack.

8:00And that's either from an attacker

8:01or as a result of our scan.

8:03So we'd want to test first.

8:05So scans can be said to be very nonintrusive, where

8:08we're looking for specific open ports.

8:10And that would be considered a passive scan.

8:13And when we use our scanners against Microsoft Active

8:16Directory with a non Active Directory

8:18account looking for unpatched systems

8:20and so forth, that would be considered a non credentialed

8:24scan, as the user that we're using

8:26as part of the scanning software is not part of AD.

8:29And so we can get a lot of great information

8:31from scanning, even with a non credentialed scan.

8:33Another example is scanning, for example,

8:35on looking for TCP port 443 to discover not only is

8:39that port open, but also to discover,

8:41is that server using a self-signed certificate?

8:44So it doesn't take a valid user account

8:47to learn that because a server with those open ports

8:49will communicate with anybody making those requests.

8:52So the cool thing is that we can identify some vulnerabilities,

8:55that they exist, without having to actively or aggressively

8:59test specific applications.

9:01And that's just by doing some simple port-based scans

9:03of a device.

9:04On the other hand, a scan could be very, very aggressive.

9:08And that would be considered an active scan.

9:10It's intrusive.

9:11It's going to use system credentials.

9:13Somebody has a user account that's

9:14part of the scanning software.

9:16And that's referred to as a credentialled scan.

9:18And here's how it works.

9:19In the scanner, we simply provide a user account

9:22that has permissions.

9:23And then the scan, when it's done, uses that permissions.

9:26And that may operate with an agent or other software

9:29on each of the systems as well.

9:30So when a scanning service runs using

9:32the permissions of a valid user account,

9:34it can better assess potential vulnerabilities

9:37across the domain because it can ask detailed questions

9:40to that system because it has, basically,

9:42all the permissions of that user account.

9:44So we may have the scanner inventory every app

9:48and every service on every system.

9:50And so the benefit of doing an active or credentialled scan

9:54is that we can get more detail and get reports regarding

9:57a system and discover that it's vulnerable to a certain type

10:01of an attack, such as an injection attack, like, LDAP

10:03or SQL.

10:04So here's the payoff for doing aggressive or more aggressive

10:07scans, as long as they don't take our systems

10:09down is that the more successful scans that we do,

10:12that's going to lead to learning more

10:14about potential vulnerabilities, which hopefully guides us

10:18to correcting those with either configuration changes

10:21or patches or additional controls

10:24to help mitigate risks if we discover, or when we discover,

10:28vulnerabilities in our systems.

10:30There's a few other options, too,

10:31that we can use to help reduce the vulnerabilities on a host.

10:35And that would include using what's called a secure boot

10:37process to verify that rootkits or other changes

10:41have not been implemented on a system.

10:43Also, many host-based intrusion prevention systems or IPSes

10:47have explicit allow lists for applications.

10:51And by using this type of control, any applications

10:54or access that's attempted that is not explicitly permitted,

10:59would be implicitly denied.

11:01So if you have malware or something else

11:02that's going wrong, it wouldn't be

11:04able to run based on the host based intrusion prevention

11:06software.

11:07Another good security option is to restrict data

11:09from going into or out of USB ports if it's not needed.

11:13And that way, even if a user does pick up a USB device

11:18and they plug it into their computer,

11:19their system can't be compromised

11:22if there's a technical control in place that

11:25doesn't allow any transfer into or out of that system

11:28via the USB ports.

11:30So the guiding security principle is less is more.

11:33Fewer permissions, fewer apps, fewer services--

11:37that's going to reduce our attack surface.

11:40It's also going to reduce our vulnerabilities as well.

11:43So thank you for joining me in this video.

11:45And in the very next video, I'd like

11:46to do a wrap-up and a review with just a few quiz questions.

11:49And I'll see you there in just a moment.

11:51Meanwhile, I hope this has been informative for you.

11:54And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:06Hello, and welcome back.

0:07In this review's last quiz, I'd like

0:09to present a few questions, which

0:11will give you and I the opportunity

0:13to both confirm our understanding

0:14and also to reinforce many of the concepts

0:16that we've talked about in this set of videos.

0:19So if you're ready, here is question number 1.

0:22What can be done to reduce the attack

0:25surfaces and/or vulnerabilities on a system.

0:28There's four choices on the board.

0:30Go ahead and pause me.

0:31When you're ready, go ahead and click on Resume

0:33and we'll address the correct answers together.

0:36All right, so here we go.

0:37Secure boot is a fantastic option

0:39to help verify that a system has integrity.

0:42So when a system first powers on--

0:44I'll go ahead and put a little lightning bolt here--

0:47there's some power applied.

0:48And then there's going to be some firmware and some BIOS

0:52that's read, or the more current UEFI, instructions

0:55for the system to get going.

0:56Then it's going to read some information from the bootstrap

0:59loader on the storage device.

1:01And then it's going to load the operating system.

1:03And if we can use secure boot during that process,

1:05it can verify with hashes each step along the way

1:09that it hasn't been tainted or modified by something else.

1:13And that way, if we verify each of these individual steps

1:16with a secure boot, and oftentimes we

1:18can use a TPM chip as well as part

1:20of that for storing those hashes,

1:22then we can have more confidence in the system booting up.

1:25So by having secure boot, we are absolutely

1:27reducing the attack surface because if we're

1:29avoiding a rootkit or something else malicious running

1:32on the system, we're not going to be as vulnerable.

1:34All right, so I'd say answer A is correct.

1:37Answer B says use a security baseline config.

1:40And I would say that's also super important

1:42because we're rolling out all types of devices.

1:46We're rolling out mobile devices and servers.

1:49And those servers may be physical or in a data center

1:51or they may be, like, in the cloud.

1:53But if we have baselines, especially security baselines

1:56regarding the best practices of how they should be configured

1:59and what services they should be running or not running,

2:02that's going to help us improve our security posture

2:05and reduce our attack surfaces.

2:07So mobile devices, servers, workstations,

2:09and Internet of Things devices, anything else that we're

2:12rolling out, if beforehand we can have a security

2:15baseline regarding configuring them,

2:17we can then use that as a checklist

2:19as we roll out those systems or even

2:21automate it to help improve our security.

2:23All right, so answer B is correct.

2:25And answer C says vulnerability management.

2:27And that is absolutely true to help reduce attack surfaces.

2:31And that way if we're scanning for TCP port 80

2:34and we find it behind the scenes,

2:37that implies that HTTP services is running.

2:40And if it's not supposed to be running,

2:42that's an attack surface that we don't want on that system

2:44and we'd want to go further and investigate that and get

2:47it shut down.

2:47Maybe the user had the privileges

2:49to install some software or perhaps it's

2:52some malicious software that's currently running,

2:54causing it to be open.

2:55Either way, if it shouldn't be open,

2:56we'd want to identify that.

2:57And vulnerability management and vulnerability scans

3:00can help us do exactly that.

3:02So answer C is correct.

3:03And then answer D, restrict USB ports.

3:06And I would say that's also true as far

3:09as reducing attack surfaces.

3:11If the USB ports are not functional,

3:13you can't get data in or out via a USB port,

3:16then you just reduced that attack surface of the USB ports

3:19on that system.

3:20So every answer on the board here is correct.

3:23All right, let's take a look at question number 2.

3:26A scan shows open ports of 25, 80, and 443.

3:31Let me also throw in there that those are TCP ports.

3:35And as a result, if we had that scan report come back,

3:38whether it's a vulnerability scan or its Nmap

3:40or Zenmap, which services are likely

3:43running on the host that has these three ports that

3:47are open?

3:47So go ahead and pause me.

3:48Take a look at the answers.

3:50And when you're ready, click on Resume.

3:51All right, so let's take a look at these together.

3:54We have five answers on the board.

3:55FTP is a clear text protocol-- not secure.

3:58And that has a control port by default of TCP port 21.

4:05That's the control channel for FTP.

4:07That's not up here in this list.

4:09So we'll go ahead and take that off our list.

4:11HTTP has the well-known server port of TCP port 80.

4:16HTTP is also plain text--

4:18not secure, doesn't do encryption.

4:21But as part of our question here, port 80,

4:23I would say, yes, we could assume or infer

4:27that if TCP port 80 is open on that host, that

4:30means that there's an HTTP service or very likely

4:33an HTTP service running because TCP port 80 is

4:35the well-known port for HTTP.

4:38All right answer C is HTTPS, which uses

4:42the well-known part of TCP 443.

4:46And behind the scenes, it's very likely

4:48using TLS, transport layer security, version 1 dot

4:51something.

4:52And we'll have separate videos on TLS and how that all works.

4:55But the question here is if you see a server or device that

4:59has 443 open, it's very likely running

5:02some type of HTTPS services.

5:04All right, so we've got 80 and 443.

5:07All right, answer D is TFTP, trivial file transfer protocol,

5:11which is also not secure.

5:12That uses UDP port 69.

5:15And that's not part of what we found in our scans.

5:18So that's not a correct answer here.

5:20And then SMTP, simple mail transfer protocol,

5:23it uses TCP port 25.

5:25So there's a lot of other ports, also, that SMTP may be using.

5:29Also, many that can use encryption.

5:31But SMTP, the well-known port is 25.

5:34And so if we saw that, we could assume on that system

5:37that SMTP services are running on that host.

5:40So our answers here are our answers B, C, and E.

5:44And I've got one more question for you.

5:46It's question number 3.

5:48And here it is.

5:49Which of the following are full-featured vulnerability

5:53scanners?

5:54So I've got four things listed on the board.

5:57Go ahead and pause me.

5:58And which of these are full-featured vulnerability

6:01scanners?

6:02All right, welcome back.

6:03So if we take a look at the two that are the most popular

6:06in the universe, at least the universe that I live in,

6:09they are Nessus, made by Tenable,

6:11and Nexpose, which is made by Rapid7.

6:15So those are the two full-featured vulnerably

6:17scanners.

6:18Nmap is a great tool that can help us identify open ports.

6:22And Zenmap, which we had in an earlier

6:24video as a demonstration, that's a great tool, too,

6:26to help identify ports.

6:27But it's not a full-featured vulnerability scanner.

6:29For example, we don't have plug-ins for Nmap

6:32that are specific to a flavor of Linux or Apache

6:36and so forth that could help identify vulnerabilities

6:39on those specific platforms or applications.

6:41And then Nslookup is a great tool

6:43that we can use for name server information.

6:46And if we wanted to find out what

6:48is the IP address for a certain host

6:50or if we wanted to validate an MX record or something

6:54else in DNS, Nslookup is a fantastic tool.

6:57But again, it's not a full-featured vulnerably

6:59scanner.

6:59So the answer we're looking for here are answers A and B.

7:03So I'd like to thank you for joining me

7:05for both this quiz and also this set of videos.

7:08And I look forward to seeing you, my friend, in another set.

7:10Meanwhile, I hope this has been informative for you.

7:13And I'd like to thank you for viewing.