If you set up a monitoring system on your network,
then one of the key components you're going to monitor
will be interfaces.
You need to know whether an interface is up
or whether the interface is down.
This can often be one of the most important things
you need to know about that particular device.
If an interface has been available
and suddenly changes to an unavailable state,
then you'll probably want to open some tickets,
and have someone investigate.
Fortunately, the monitoring of an interface
doesn't require any special rights
or any special permissions.
You can simply ping the interface
to see if it's still running.
Green, then, would obviously designate that the interface
is up and running.
And a red interface would be one that is no longer responding
to our queries.
These are commonly automated functions.
They continue to run all day, every day, periodically
checking to see if an interface is available.
If an interface is suddenly unavailable,
you'll probably want to create some alarms and alerts.
You want to notify the proper people that particular device
is no longer responding.
You may open up a ticket in your help desk system.
You might send an email notification.
Or you might send a text message.
Since you're querying these interfaces so often,
you can create short-term and long-term reports
that show the uptime and availability of these devices.
This interface monitoring may provide only a basic up or down
statistic.
If you want to gather more details about what's
happening with that interface, then you
may want to implement simple network management protocol
and constant queries against very specific management
information base details.
We mentioned in an earlier video about the importance of a SIEM.
This is a security information and event management platform.
This is usually a device that is consolidating
log files from all of your different devices.
And you are able to monitor and create reports
on all of that logged information.
Since the SIEM is gathering so many different details
from so many different parts of the organization,
it can also perform real-time monitoring
of the information it receives.
So if an alarm state suddenly occurs,
you can send out security alerts or other messages
so that people are getting real-time information
about what's happening on the network.
But of course, since this device is
gathering so much information and storing
all of that information over such an extended period
of time, you can really create some very interesting
short- and long-term reports.
Usually, there are our advanced reporting functions
within these SIEMs that may include built-in reports.
And it may also allow you to build your own custom reports.
This wealth of data that you've collected
may also allow you to create some correlation between all
of these different very diverse data types.
For example, you could look at detailed log information
from a VPN where someone logs in.
You can see switch information when they were assigned a VLAN.
You can identify firewall details.
And then you can track exactly what application
was accessed on a server all by consolidating
this data within the SIEM.
If a security event does occur, the SIEM
will contain very valuable information.
This will allow you to rewind over time
and access all of the details from all
of your different components to determine
exactly what may have happened.
These SIEMs are gathering data from many different kinds
of devices made by many different manufacturers.
There may be a VPN concentrator from one manufacturer,
a switch and a router from another manufacturer,
and a firewall from a third manufacturer.
But fortunately, there is a standard way
to collect all of the log files from those devices.
And that standard is called syslog.
Syslog is a standard way to transfer log information
from all of these different kinds of devices.
It's very common to have all of these devices
report back to a centralized SIEM
using the syslog protocols.
You're going to be gathering a lot of information
from a lot of different devices.
So it's very common that your SIEM
would be equipped with a lot of storage space
to be able to gather and maintain
all of that log information over an extended period of time.
Now that all of this log information
has been consolidated in one place,
you can now go back over time and look at all of the events
that you might need to see.
For example, this is a consolidation
of Windows event logs.
You can see processes that have exited.
You can see when someone has logged in.
You can see when someone has logged off.
Using this consolidated log information on the SIEM
gives you very detailed information
about exactly what's happening on your network.
But sometimes you don't need that level of detail.
You'd rather have a broader view of what may be happening.
You can use a SIEM dashboard to take
all of the information that has been gathered through the logs
and provide it in a broader much more graphical form.
For example, you can see the alerts
on the network that may have been
related to an unsuccessful Windows login or a virus.
Or you may be able to see security events related
to logins and logouts.
All of this is available at a glance.
And you're able to tell very easily exactly
what may be happening on the network at any particular time.
Another way to monitor the network and all of the devices
is to proactively query those devices for more information.
We would normally use SNMP to provide that query.
This is the Simple Network Management Protocol.
And it allows you to use a standardized information base
to be able to query devices and return details about how
that device may be performing.
You would normally set up a management station
to perform these queries.
That management station would be configured with the name or IP
address of the remote device that you wanted to monitor.
And then you need to specify the version of SNMP
that is supported by that remote device.
SNMP version 1 was the original version of SNMP.
And it allowed the management station
to send a single query to the device
and get a single response from that device.
That response was also sent over the network in the clear.
There was no encryption associated with SNMP version 1.
SNMP version 2 added a number of additional enhancements.
One of those was that the management station
could request many different items at one time
and receive a bulk response in return.
But like SNMP version 1, there was no encryption
associated with SNMP version 2.
We got the security we were waiting for in SNMP version 3.
This allows for message integrity, authentication,
and encryption of the requests and the responses.
The SNMP agents that are running in your infrastructure devices
are collecting a wide range of information.
So you want to be sure the people that
are querying these devices through SNMP
are only the ones that need access to that information.
Once you've queried a device over time
and gathered all of these different metrics,
you can create a reports showing information on uptime, response
time details, the amount of traffic transferred,
or anything else that may be collected by that SNMP agent.
There are many third-party tools that you can use
to browse or walk the SNMP MIB.
I'm using a generic MIB browser.
You can download MIB browsers for almost any operating
system.
And I'm using one that is accessing a set of demo data
on the internet.
And you can use this on your MIB browser,
as well, at demo.SNMPlabs.com.
If I click Fetch, this will begin sending SNMP queries
and receiving SNMP responses and gathering details
about all of the interfaces that may
be on that particular device.
We can see in this example, this device is at SNMP laboratories.
It is in San Francisco, California.
And we can get details about the uptime, availability, speeds,
throughput, and other information
that's gathered by that SNMP agent.