Time
8 hours 35 minutes
Difficulty
Intermediate
CEU/CPE
9

Video Description

This lesson covers IT service delivery controls and system monitoring which includes: - Hardware - Software - Centralized System logging - Network Device monitoring - Uptime-downtime reporting This unit also discusses log management, how to effectively manage log events and data file controls. The lesson also covers the use of anti-virus software, e mail and mobile security code policies as well as maintenance controls. [toggle_content title="Transcript"] Alright, so now let's think about monitoring the status of our controls. We know that continuous monitoring is an important consideration. We need to know that the controls we've put in-place are doing the job they're expected to do. If you recall, I talked about planned inputs, expected behavior and planned outputs. Or expected outputs. So if we think about the delivery of our services, we have a lot of different services that a typical IT department provides. We have the monitoring of our systems, we have controls on our data files systems, control systems, system access controls, we have to deal with anti-virus software, our maintenance controls, providing an appropriate test and development requirement for system monitoring, as I was saying, continuous system monitoring is what we're after here. If we can constantly keep an eye on the controls that protect our assets, then we can find out about problems as soon as possible. This could be problems with hardware, software, monitoring all of our network devices, our routers, our switches, our proxies, firewalls, keeping track of uptime and downtime. Some of these things could be folded into your metrics requirements as well but doing the monitoring to begin with is critical. What about log management? We know that we need logging for important transactions with our applications or operating systems. We also need to log security events. For instance, if you're getting messages from your logging system saying that someone is attempting to login as an administrator again and again and again that could be evidence that there is some kind of brute force attack going on with one of your administrator accounts. Your applications: maybe the applications are experiencing problems and certain functions are failing because you're running low on memory or processor. Your logging should indicate this. You might problems with your operating system, or with the network connections. Having the right tools in-place to send alerts as needed is what we're thinking about. You might have a syslog aggregated server, something like Arc Sight where you're gathering logs from all of the different devices in your environment and having them go to one place so you can centralize the monitoring and management of those log events. We need to think about user access logs, when people login to a system, successfully or especially unsuccessfully that should be logged somewhere. Again, that goes back to the idea that we want to be able to spot suspicious activity. There's also the expectation that when users connect to a system, that they might see a warning banner which says that, "You're connecting to a resource that this organization owns. Your activity is being monitored. If you do something objectionable, or illegal, we will prosecute," and so on. Maybe you've got some policies and procedures in-place dealing with your passwords. We know that we should be using upper and lower case letters and numbers and special characters. Passwords typically should be changed every 30 days. Sometimes organizations go as long as 90 days. Maybe you're allowed to reuse a password after you've changed it ten times, or maybe you're never allowed to reuse a password. Your organization will decide what's best for your requirements. These are some considerations to think about. Maybe you fail to login correctly three times. Now that login becomes disabled. It might be disabled permanently until the helpdesk turns it back on, or maybe it just gets disabled for fifteen minutes. Those are different variations of that type of control. We have to keep track of our privileged login accounts: people that are logging in as root or administrator or domain administrator. Or domain controller. People logging in to Active Directory. These are the critical pieces of the infrastructure in the organization so the controls on those login accounts should be correspondingly tightened to respond to the extra threat. Maybe we change the passwords every 30 days and there's no longer time period allowed. It could be that you've got to save those passwords in an off-site location in case they're needed in an emergency. Some organizations might put a hard copy of the accounts and their associated passwords into a safe. That way it can only be accessed by maybe two or three people that have the combination of the safe, and those might be the highest level individuals within the organization, the most trusted individuals in the organization. What about maintenance logins? We have back-up operators. We have people that deal with optimizing databases. There could be accounts that are used for other types of regular maintenance on a system. These are favorite targets for hackers. This is because when these maintenance accounts get created, sometimes they are left with default passwords, or default privileges. This, again, goes back to the idea of auditing your systems to understand what gets created when you install a database, or when you install a web server. Why are these extra accounts here? Why don't they have the same controls on their passwords as the other accounts? You want to find those problems before they become low-hanging fruit for a hacker. In general, if an account for maintenance is not needed we should just disable it. There's no reason to even leave it active. We want to think also about controls on our data files. This means everything from a table in a database to a log file on a system, an event log. It could be files detailing different configuration detail for how the networking is set-up, or how your routing is set-up. Files that are used to control the system's behavior, or its overall configuration. You want to think about having logical access controls, otherwise known as technical controls. So if someone needs a certain capability, that should most likely be assigned to their role and then they get assigned to a group which has that role. That provides an extra level of protection and makes the overhead of dealing with the maintenance a little bit easier. Transaction processing controls; if we've got processing going on within databases or financial transactions, there should be some expectation that the transaction is being monitored, validated, to make sure that it's correct before it's written to the database, for instance. We want to know that the transaction completed successfully and that the results were correct before we decide to save that information. If there is an inconsistency, or some other problem, typically that transaction is rolled-back and then it might be submitted again, or the user needs to attempt the transaction again. We have to think about application processing controls as well. Input controls, input validation. Trying to make sure that when input is accepted from a user, or from some other entity, like another software program, that the input is in the correct format, has the correct range of values, has the correct length or size. We don't want to be able to facilitate things like SQL injection or Cross-Site Scripting. We want to make sure, for instance, that we have unique logins and passwords on all of our systems. You shouldn't be reusing the same password on all of the systems that you have access to. Sometimes we use the recapture tools where this tries to prevent an automated entry of login data. So some kind of distorted letters and characters might be visible, and someone has to look at that image and manually type that in. These are all controls that enhance the security for access to our applications. Then we can think a little bit about some of our processing controls. What about batch totals? If I've got 1000 records to process and my report shows that I processed 972 now I know that I've got some missing information. A good control in that case should spit out a report and then the information can be processed again until it is done correctly. Total number of items would relate somewhat to batch type controls or batch totals. We want to do things like exception reporting, which I talked about earlier. Maybe you processed all of your transactions but certain ones are irregular, for whatever reason. Or something got skipped. We want to be able to provide a mechanism to detect that automatically so that we don't have to rely on a manual process. Then we have output controls. What about things like negotiable instruments? We've got stocks and bonds and other financial documents. We want to make sure that we've got the right logical and physical controls for certain items like this. Maybe the printer that produces the document is in a secured area with limited physical access. We want to think about our event logs. This could be event logs for lots of different things, related to applications, related to the operating system, related to network events. How was that information retained? How was it used and how was it guaranteed to be available when it's needed? Another important component of managing our environments is anti-virus software. There's obvious reasons for using this. We want to be able to find viruses and worms in the environment. As I was mentioning earlier viruses are attached to programs that might be used in the course of doing business. Sometimes viruses are introduced to the environment because of careless user activity; clicking on attachments in emails, or going to dangerous websites. So effective detection and elimination of viruses is a critical function. Same thing would apply to worms. Worms can replicate without human interaction. So they have a certain difference in the way that they're dangerous to the environment. They can use up all of your available network bandwidth as they multiply and infect other systems. Since worms don't need human interaction, they can multiply much quicker than a virus can. And, of course, worms don't attach themselves, or they're not attached, rather, to a file. They exist on their own. So it's kind of a different beast as far as what kind of controls you need to detect and eradicate a worm. We also have to consider our mobile devices. A lot of organizations are using a bring-your-own-device, or BYOD policy, where everybody can bring in their favorite version of a mobile phone or a tablet. We also have to deal with staff that use laptops. Generally, when we consider mobile code, we're talking about a handheld device, not usually a computer, or a laptop computer. So how is this mobile device managed? Is it managed with group policy? Do you have people just expecting to do the right thing? There is some blend there sometimes between what the organization can provide and what the user is expected to do, depending on the make and model of the device they're using. A little bit here about some email technology. We have multi-purpose Internet mail extensions, or MIME. This allows a lot of the multimedia functions that email was evolved to support. Things like audio files or video images. Being able to embed different components into an email to make it a richer experience for the person reading the email, or interacting with some of its resources. We need to think about the security policy for mobile devices. Going back to handheld devices and knowing that certain things are possible that the users might do on their own interacting with external servers, or the mobile devices are managed somewhat by internal servers where the security policies can be enforced more rigidly. If we let the users do whatever they want with their mobile devices, then you're at your highest risk level. So trying to find a balance between security and functionality can be a challenge. Then we think about our maintenance controls. I talked a little bit earlier about back-up and recovery, as far as managing where the tapes go, how long they're retained and so on. We also have to consider the verification that those back-ups are actually being performed correctly. Can you do a test restore of your data and verify that the data is correct and complete? We have to think about management of our projects, as it relates to maintenance controls. How do we know that the risk analysis phase of project management was done correctly? There should be some workflow involved, some kinds of checklists showing what needs to be done and the fact that it was done. Maybe someone signs off on each individual step and then when it gets finally to the end point we can verify that all of the different things were done correctly and in the right order. Configuration management, also important. This relates back to change control. So that we can understand when changes are made to a system, what needs to be documented? Who needs to review that? Who needs to approve it? And then be able to refer back to that information in the event of problems. Authorizing change is quite often a group effort. You might have representatives from different teams, the network team, the security team, the developers, the database management team, and so on. They all have some input and some perspective on making sure that they all agree that a change is acceptable to perform and that won't cause other problems. Sometimes we have to deal with emergency changes. This is sometimes called a break-fix scenario. Where you see there's a problem, you need to fix it right now, so you go ahead and fix it and then you file the change control paperwork later, because there was no option to wait for the typical change control process which may be several days, or even a week or more, depending on how large your organization is. So this kind of goes back to the idea of it's easier to apologize than to ask for permission. Sometimes that's the reality of dealing with emergencies in an IT environment. [/toggle_content]

Video Transcription

00:04
All right, So now let's think about monitoring status of our controls. We know that continuous monitoring is a important consideration.
00:13
We need to know that the controls that we've put in place are doing the job that they're expected to dio. If you recall, I talked about
00:21
planned inputs, expected behaviour and planned outputs
00:25
are expected outputs.
00:27
So we think about the delivery of our service is
00:31
we have a lot of different
00:32
service. Is that a typical I t department provides.
00:35
We have the monitoring of our systems.
00:37
We have controls on our data files, systems control systems, *** access, controls,
00:44
deal anti virus software, our maintenance controls,
00:48
providing a appropriate testing development environment for system monitoring. As I was saying,
00:54
continuous system monitoring is what we're after here.
00:58
If we can
00:59
constantly keep an eye on the control that that
01:03
protect our assets,
01:04
then we can find out about problems as soon as possible.
01:08
This could be problems with hardware software.
01:11
Uh,
01:12
monitoring all of our network devices are routers are switches. Are proxies, firewalls,
01:19
keeping track of time in downtime.
01:23
These are some of these things could be folded into your metrics requirements as well, But doing the monitoring to begin with is critical.
01:30
What about Logue management?
01:33
We know that we need
01:34
logging for important transactions with our applications or operating systems. We also need to log security events.
01:44
For instance, if you're getting messages from your logging system saying that someone is attempting to log in as administrator again and again and again,
01:53
that could be evidence that there's some kind of brute force
01:57
attack going on with one of your new, straighter accounts,
02:00
your applications. Maybe the applications are experiencing problems, and certain functions are failing because you're running low on memory or processor
02:10
you're logging should indicate this your might have problems with your operating system or with the network connections.
02:17
And having the right tools in place to send alerts as needed is what we're thinking about.
02:23
Oh, you might have a, uh,
02:27
sis log aggregated server, something like Ark site. Well, you're gathering logs from all the different devices in your environment and having them go to one place so you could centralize the monitoring and management of those log events.
02:39
We need to think about user access logs when people log into a system
02:46
successfully or especially unsuccessfully, that should be logged somewhere
02:51
again. That goes back to the idea that we want to be able to spot suspicious activity.
02:57
There's also the expectation that when users connect to a system that they might see a warning banner, which says that you're connecting to a resource that this organization owns your activities being monitored. If you do something objectionable or illegal, we will prosecute and so on.
03:15
Maybe you've got a
03:17
some policies and procedures in place dealing with your passwords.
03:23
We know that we should be using upper lower case letters and numbers and special characters.
03:29
Passwords typically
03:30
should be changed every 30 days. Sometimes organizations go as long as 90 days.
03:36
Maybe you're allowed to re use a password after you've changed it 10 times. Or maybe you're never allowed to reuse the password.
03:43
Your organization will decide what's best for your requirements, but either some considerations to think about.
03:50
Maybe you fail to log incorrectly three times now that log in becomes disabled.
03:57
It might be disabled
03:59
permanently until the help desk turns it back on. Or maybe it just gets disabled for 15 minutes. Those air different variations of that type of control
04:08
we have to keep track of our privileged log in accounts people, they're longing in his route or administrator or domain administrator
04:16
uh,
04:17
domain controller.
04:19
People logging into active directory
04:23
These air the critical pieces of the infrastructure of the organization. So the controls on those law again accounts
04:30
should be correspondingly tightened to respond to the extra threat.
04:34
Maybe we change the passwords every 30 days, and there is no longer time period allowed.
04:41
It could be that
04:43
you've got to save those passwords
04:45
in an off site location in case they're needed in an emergency.
04:49
Some organizations might put a hard copy of the accounts and their associative passwords into a safe.
04:58
That way, it could only be accessed by
05:00
maybe two or three people that have the combination of the safe. And those might be the highest level individuals within the organization, the most trusted individuals in the organization. What about maintenance log ins?
05:13
We have backup operators. We have people that deal with optimizing databases.
05:20
There could be
05:21
accounts that are used for other types of regular maintenance on a system.
05:27
These are favorite targets for hackers,
05:31
and this is because when these maintenance accounts get created,
05:36
sometimes they are left with default passwords or default privileges.
05:41
And this again goes back to the idea of auditing your systems to understand
05:46
what gets created when you install a database or you install a Web server.
05:50
Why are these extra accounts here? Why don't they have the same
05:54
controls on their passwords as the other accounts?
05:57
You want to find those problems before they become low hanging fruit for a hack?
06:01
In general, if an account for maintenance is not needed, we should just disable it. There's no reason to even
06:09
we've it act
06:11
want. Think also about
06:13
controls on our data files. This means everything from a table in a database to a log file on a system and event log.
06:21
It could be files detailing
06:25
different configuration. Details
06:28
for how the networking is set up or how you're routing is set up
06:32
how the files that are used to control the system's behavior or its overall configuration.
06:40
We want to think about having logical access controls or otherwise known as technical controls.
06:46
So if someone needs a certain capability
06:48
that should most likely be assigned to their role and then they get assigned to a group which has that role
06:56
that provides extra level of protection and makes the overhead of dealing with the maintenance a little bit easier.
07:04
Transaction processing controls
07:08
If we've got processing going on within databases or financial transactions,
07:14
there should be some expectation
07:16
that that the transaction is being monitored validated to make sure that it's correct before it's written to the database. For instance,
07:25
we want to know that the transaction completed successfully and that the results were correct. Before we decide to save that information,
07:32
it's
07:33
there's inconsistency or some other problem.
07:36
Typically, that transaction is rolled back, and then it might be submitted again or the user needs to attempt the transaction again.
07:45
We have to think about application processing controls as well
07:49
input controls and put validation,
07:51
trying to make sure that when input is accepted from a user or from some other entity, like another software program
08:00
that the input is in the correct format has the correct range of values has the correct length or size.
08:07
We don't want to be able to
08:09
facilitate things like sequel injection or cross site scripting.
08:15
I want to make sure, for instance, that we have unique log ins and passwords on all of our systems
08:20
shouldn't be reusing the same password on all the systems that you had access to.
08:28
Sometimes we use the recapture tools
08:31
where this tries to prevent an automated entry of logging data.
08:37
So some kind of distorted letters and characters might be visible. Someone has to look at that image and manually type that in.
08:45
These are all controlled. That enhanced the security for access to our applications.
08:50
And we could think a little bit about some of our processing controls.
08:54
What about batch totals?
08:56
If I've got 1000 records to process
08:58
and my report shows that I processed 972
09:03
now I know that I've got some missing information.
09:07
Good control in that case
09:09
should spit out a report, and then the information could be processed again until it is done correctly.
09:16
Total number of items would relate somewhat to batch type controls or batch totals.
09:22
We want to do things like exception reporting, which I talked about earlier.
09:28
Maybe your process all your transactions, but certain ones were irregular, for whatever reason, or something got skipped,
09:33
you want to be able to provide
09:35
a mechanism to detect that automatically so that we don't have to rely on a manual process.
09:41
Then we have output controls.
09:43
What about things like negotiable instruments?
09:48
We've got stocks and bonds and other financial documents.
09:54
I want to make sure that we've got the right
09:56
logical and physical controls for certain items like this. Maybe the maybe the printer that produces the document is in a secured area
10:05
with limited physical access.
10:09
You want to think about our event logs?
10:11
This could be event logs for lots of different things related to applications related to the operating system
10:16
related to network events.
10:20
How is that information retained? How is it used? And how was it guaranteed to be available when it's needed? Another important component of managing our environments is anti virus software.
10:31
There's obvious reasons for using this.
10:35
I want to be able to find viruses
10:37
and worms in the environment.
10:39
As I was mentioning earlier, viruses attached themselves
10:43
or rather are are attached to programs that might be used in the course of doing business.
10:50
Sometimes viruses are
10:52
are introduced to the environment because of careless user activity,
10:56
clicking on attachments and emails or going to dangerous websites.
11:01
So effective detection and elimination of viruses
11:05
is a critical function.
11:07
Same thing would apply to worms.
11:09
Worms can replicate without human interaction, so they have a certain difference in the way that they're dangerous
11:15
to the environment. They could use up all of your available network band with as they multiply
11:20
and, in fact, other systems.
11:22
Since worms don't need
11:26
human interaction, they could multiply much quicker than a virus can't.
11:30
And, of course, worms don't attach themselves.
11:33
They're not attached rather to a file. They exist on their own. So it's a kind of a different beast
11:39
star. What kind of controls you need to detect and eradicate
11:43
a worm.
11:45
We also have to consider our mobile devices.
11:48
A lot of organizations are using a bring your own device or B Y o D. Policy.
11:54
Everybody can bring in their favor
11:56
version of a mobile phone or a tablet
11:58
way also have to deal with,
12:01
uh, staff that use laptops.
12:03
But generally, when we consider mobile code, we're talking about a handheld device not usually a
12:09
computer, a laptop computer.
12:13
So how is this
12:13
mobile device managed?
12:16
Is it marriage with group policy? Do you have
12:18
people just expecting to do the right thing.
12:22
There's there's some blend there sometimes between what the organization can provide and what the user is expected to do, depending on the make and model of the device they're using well. But here about some email technology we have multipurpose Internet mail extensions are mine.
12:39
This allows a lot of the multimedia functions
12:43
that email was evolved to support
12:46
things like audio files or video images.
12:50
Being able to embed different
12:52
components into an email to make it a richer experience, or the person reading the email or interacting with some of its resource is
13:01
we need to think about the security policy for mobile devices
13:05
going back to handheld devices
13:09
and knowing that
13:11
certain things are possible that the users might do on their own. And you're acting with external servers.
13:18
Or the mobile devices are managed somewhat by internal servers, where the security policies can be enforced more rigidly.
13:26
If we let the users do whatever they want with their mobile devices, then you're at your highest risk level,
13:31
so trying to find a balance
13:33
between security and functionality can be a challenge.
13:35
Then we think about our maintenance controls.
13:39
I talked a little bit earlier about backup and recovery
13:41
as far as managing where the tapes go,
13:46
how long they retained and so on. We also have to consider the verification that those backups are actually being performed correctly.
13:54
Can you do a test restore of your data
13:56
and verify that that the data is correct and complete?
14:01
We have to think about management of our projects as relates to maintenance controls.
14:07
How do we know that the risk analysis phase of project landed? It was done correctly?
14:13
There should be some
14:15
workflow involves some kinds of checkoffs or checklists, rather
14:20
showing what was what needs to be done, in fact, that it was done. Maybe someone signs off on each individual step,
14:26
and then when it gets finally to the end point, we can verify that all the different things were done correctly and in
14:33
in the right order.
14:35
Configuration management also important.
14:39
This relates back to change control
14:43
so that we can understand what changes are made to a system
14:46
what needs to be documented, who needs to review that, who needs to approve it
14:50
and then be able to refer back to that information in the event of
14:54
problems
14:56
authorizing change is quite often a group effort.
15:00
You might have representatives from different teams, that network team, the security team that developers, the database management team and so on.
15:09
They all have some input. In some perspective. I'm making sure that
15:13
they all agree that a change is acceptable to perform, and that won't cause other problems.
15:20
Sometimes we have to deal with emergency changes.
15:22
This is this is sometimes called a break fix scenario
15:26
where you see there's a problem. You need to fix it right now, so you go ahead and fix it and then you file the change control paperwork later
15:35
because there was no option toe wait for the typical change control process, which made be several days or even weeks or more, depending on how large organization is.
15:46
So this kind of goes back to the idea of it's easier to apologize, then to ask for permission. Sometimes that's the reality of dealing with emergencies in a nightie environment

Up Next

Certified Information System Auditor (CISA)

In order to face the dynamic requirements of meeting enterprise vulnerability management challenges, CISA course covers the auditing process to ensure that you have the ability to analyze the state of your organization and make changes where needed.

Instructed By

Instructor Profile Image
Dean Pompilio
CEO of SteppingStone Solutions
Instructor