Time
8 hours 35 minutes
Difficulty
Intermediate
CEU/CPE
9

Video Description

This unit covers problem management. Problem management is about how a response is provided in a timely manner relative to defined procedures such as escalation. Problem management is needed to manage the following: - Procedures vs actual work - Inefficient and ineffective controls - Acceptable use policy violation (AUP) - Job Accounting - Training This unit also covers the incident handling process; focusing on the phases and who is involved and the IS auditors role in the handling of incidents. Participants will also learn about digital forensics, which examines computer data in a laboratory. [toggle_content title="Transcript"] Now let's move on to problem management. This is basically talking about the idea that when issues arise, which they always do, that the organization can deal with the resolution in a timely manner. The more mature the organization is, the more experience it has with resolving various problems, the more efficiently it should be able to deal with problems when they crop up. So when do we need problem management? It should be needed at all times, obviously, but some times more than others. We want to think about analyzing our procedures, for one thing. If you've gone to the trouble to document the job responsibilities and roles and what those people do and how they do it, we want to make sure that that's a good alignment with what was documented and what actually gets done. If you've got great procedures but people aren't actually doing the job as it's described, then there's a disconnect. There's some failure there that needs to be analyzed to understand why this happened and what to do about it. Sometimes we implement controls that are inefficient or ineffective that only might be discovered during some kind of risk analysis or an audit. When those controls are discovered that are not meeting the objectives that it was designed for, then something needs to be done. So having a problem management methodology is where we would want to point ourselves. What about acceptable use policies? This could be something as simple as someone spending too much time surfing the Internet for their own personal interests, or reading personal email taking up too much of their time, wasting time on Facebook and so on. When those policy violations happen, what is the result? What are the consequences for the violator? We need to think about job accounting. This is a job as in a processing job, not as in someone's role. So if we're running a job like payroll, for instance, and it doesn't complete or there are problems with it, how do we deal with those exceptions? This ties-in with the exception report, of course. We also want to think about how the organization responds when there's an issue during one of its critical jobs or critical processes. Of course training can't be underestimated or ignored. We need to know that all of our staff are trained properly for the roles that they find themselves in. If there's job rotation then training needs to address that as well. You can't expect somebody to rotate into a different position that they haven't been trained for. So that's a known quantity as far as training budgets and timelines. One of the most important types of training that everybody gets, regardless of their job, is security awareness. This is a vital part of the organization's staff. Everybody needs to be aware of the different pitfalls and problems that come and go as a normal course of doing business. What about incident handling? We've got an incident response team. Most organizations do. We have to think about whether or not that team has the right form and function. It could be a centralized team, if the organization is of a certain size. That might make the most sense. You might have various offices scattered around the country or even the globe, but your incident response team might be based at your headquarters. Or you could have a de-centralized team. So each office might have their own incident response team and then they all report to the central management area, or the headquarters, if you will. There needs to be coordination and good communication. Overall when there's an incident, we have four main phases of activity. We start with preparing for the incident response, getting as much information as possible about what needs to be done, what the options are what the contingency plans are, and so on. Then we move to phase two where there is detection of an incident, and some initial analysis is done. It could be that the detection is done by a user and not by some automated monitoring program. In either case, once the incident is known, then the analysis begins. Some cases the incident needs to be contained: in the event of a worm or virus outbreak, for instance. You want to isolate that system, make sure that the problem doesn't spread to other areas of the organization. Then, once it's isolated, we work to eradicate the problem or mitigate the problem and then try to recover from the issue in as quickly a manner as possible. Lastly we can't forget about our lessons learned or post-incident activities. If it's a larger incident especially, the organization might have several meetings discussing what happened, did we perform as expected? Where are the areas where we could use some improvement? Organizations that do this step properly will continue to grow and mature to provide more efficient use of their resources in the future. So why would an auditor be interested in incident handling? One of the most important things to think about right off the bat would be how long did it take to respond? When the problem was discovered, how long did it take before the help desk was notified? How long from that point was the first level of support notified? Your first level engineers or second level support or third level developer support? These are all different metrics that might be generated in the course of dealing with an incident. seeing the trends over time helps the auditor understand whether the business has the right policies and procedures and training in-place. What about the members of the incident response team? Are they formally appointed or is it an ad-hoc group that just comes together when needed? Do they have professional training for their different roles, or is everyone just sort of a subject matter expert on the needed areas and they just do the best they can? These are questions that need to be answered in order for the auditor to fully understand the incident response team's abilities and capabilities. Moving on to digital forensics, this is an important aspect to an organization, especially when there are problems that relate to hacking or incidents that happen due to disgruntled internal employees, privileged insiders and the like. When this happens, one of the first things we think about is the acquisition of information. We want to get it from the best possible sources, meaning that we want first-hand direct evidence, not something that was second-hand or indirect evidence. We have to pay attention to those data sources that are volatile. So if you've got a system that was involved in a hacking attack, or some kind of illegal activity, we don't want to turn it off, right? Maybe we unplug it from the network, or disable the network connection, but we want to leave the system running so we can get an image of memory. Maybe then the system can be imaged so we can get a bit-by-bit copy of the hard-drive to capture all of the relevant information that might be needed for an investigation. Non-volatile data, of course, is on the long-term storage. Like the internal hard disk. Then the information gets examined after it's acquired. One of the important things about forensics is gathering the information correctly, dealing with the chain of custody correctly so that when we get to the point where it's being examined, we know with certainty that none of the information has been tampered with or changed in any way. It has integrity. This is critical. That's why we always work with read-only copies of the information. If you're analyzing the information in any case, you should be using a copy if possible. We wouldn't want to do analysis on an original hard-drive that was involved in some fraudulent activity. You make a copy, you do the analysis with the duplicate. All of the contents of the memory, any network connections any files and folders and directories that are involved need to be considered. All the log files, transaction logs, application related logging. There could be temporary files that get generated during the course of using an application or a system itself. Then we think about the utilization of the results of the analysis. How does this piece together to reconstruct what happened? That might be needed for a legal prosecution, or it could just be performed to understand what went wrong and how to prevent it from happening again. Finally, there's a review process. Looking again for lessons learned opportunities to see what went right, what went wrong, and where there's room for improvement. [/toggle_content]

Video Transcription

00:04
Now let's move on to problem management.
00:07
This is basically talking about the idea that one issues arise, which they always do,
00:12
that the organization congee ll with the resolution in a timely manner,
00:17
more mature. The organization is, the more experience it has with resolving various problems
00:23
more efficiently. It should be able to deal with problems when they when they crop up.
00:28
So when do we need problem management?
00:32
It should be. It should be needed at all times, obviously,
00:35
but sometimes more than others.
00:37
We want to think about
00:39
analyzing our procedures. For one thing,
00:42
if you've gone to the trouble to document
00:45
the job responsibilities and rolls
00:47
and what those people do and how they do it,
00:50
I want to make sure that that's a good alignment with what was documented and what actually gets done
00:56
if you've got a great procedures. But people aren't actually doing the job as it's described,
01:02
and there's a disconnect. There's some failure. There needs to be analyzed.
01:06
I understand why this happened and what to do about it.
01:10
Sometimes we implement controls
01:12
that are inefficient or ineffective
01:15
that only might be discovered during some kind of risk analysis or
01:19
an audit.
01:21
When those controls air discovered that are not meeting the objectives that were designed for,
01:26
then something needs to be done.
01:27
So having
01:30
a problem management
01:32
methodology is where we would want a point ourselves.
01:36
What about acceptable use policies?
01:40
This could be something as simple as
01:42
someone spending too much time surfing the Internet for their own personal interests
01:47
or reading personal email, taking up too much of their time
01:51
wasting time on Facebook and so on.
01:53
When those policy violations happen, what is the result? What is the consequences for the violator?
02:00
What did you think about job accounting
02:02
this job as in a processing job? Not as in someone roll.
02:08
So if we were running a job like payroll, for instance,
02:14
and it doesn't complete
02:15
or there are problems with it, how do we deal with
02:20
those exceptions
02:21
that ties in with the exception report, of course,
02:23
but we also want to think about
02:25
how the organization responds when there's an issue during one of its critical jobs or critical processes.
02:35
Course training can't be underestimated
02:38
or or ignored. When you didn't know that all of our staff are trained properly for the rules that they find themselves in.
02:46
If their job rotation than training needs to address that as well,
02:50
you can't expect somebody to rotate into a different position that they haven't been trained for.
02:54
So that's ah known quantity as faras training, budgets
03:00
and timelines.
03:02
One of the most important types of training
03:06
that everybody gets, regardless of their job, is security awareness.
03:10
This is a vital part of the organization's staff.
03:15
Everybody needs to be aware of the different
03:17
pitfalls and problems
03:20
that come and go as normal course of doing business.
03:24
What about incident handling?
03:28
We've got an incident response team.
03:30
Most organizations d'oh!
03:32
And we have to think about whether or not that team
03:36
has the right
03:37
form and function. It could be a centralized team that the organization is of a certain size that might make the most sense.
03:44
You might have various offices scattered around the country or even the Globe
03:47
Incident Response team might be based at your headquarters.
03:52
Or you could have a decentralized team,
03:54
so each office might have their own instead of response team, and then they all report
04:00
to the Central Management Area or the headquarters. If you will,
04:04
I need to be coordination and good communication.
04:11
Overall, when there's an incident,
04:13
we have four main phases
04:15
of activity. We start with preparing
04:18
for the incident response,
04:20
getting as much information as possible
04:24
about what needs to be done, what, what the options are, what the contingency plans are and so on.
04:30
Then we moved to face two were there's detection of an incident
04:34
at some initial analysis has done,
04:38
It could be that the detection is done by a user, not by some automated monitoring program.
04:45
In either case, once the incident is known,
04:46
then the analysis begins.
04:49
Some cases the incident needs to be contained in the event of a worm or virus outbreak, for instance,
04:56
one. Isolate that system. Make sure that the problem doesn't spread to other areas of the organization.
05:02
And once it's isolated, we work to eradicate the problem or or mitigate the problem
05:09
and then try to recover from the issue
05:11
and is quickly a manner as possible.
05:14
Lastly, we can't forget about
05:16
our lessons learned or post incident activities.
05:20
If it's a larger incident, especially, the organization might have several meetings discussing what happened.
05:28
Did we perform as expected, where the
05:31
areas where we could
05:33
you know you some improvement?
05:35
Organizations that do this that properly will continue to grow and mature to provide more efficient
05:43
use of their resource is in the future.
05:45
So why would an auditor
05:46
be interested in incident? Handling
05:49
One of the most important things to think about right off the bat would be How long would it take to respond
05:56
when the problem was discovered?
05:58
How long do to take before the help desk was notified?
06:00
How long from that point was the first
06:02
level of support notified your your first level engineers or second level support? 1/3 level developer support.
06:12
These are all different metrics that might be generated in the course of dealing with an incident.
06:16
And seeing the trends over time
06:18
helps the auditor understand whether the business
06:21
has the right policies and procedures and training
06:25
in place.
06:28
What about the members of the Incident Response Team?
06:31
Are they formally appointed, or is it an ad hoc group that just comes together when needed?
06:36
Do they have professional training
06:40
for their different roles?
06:42
Or is everyone just
06:43
sort of a subject matter expert on the needed areas and they just do the best they can.
06:48
These are answers are these are questions rather that need to be answered in order for the auditor to fully understand
06:56
the incident Response team's abilities and capabilities
07:00
moving on to digital forensics.
07:02
This isn't important to ask back to an organization, especially
07:06
when there are problems relate to hacking
07:09
for,
07:10
um,
07:12
incidents that happened due to disgruntled internal employees, privileged insiders. And like
07:18
when this happens when the first things we think about is the acquisition
07:23
of information, we want to get it from the best possible sources,
07:27
meaning that we want
07:29
first firsthand direct evidence,
07:31
not something that was second hand or
07:35
or indirect evidence.
07:38
We have to pay attention to those data sources that are volatile.
07:42
So if you've got a
07:44
system that was involved in the hacking attack
07:46
for
07:48
some kind of illegal activity,
07:50
we don't want to turn it off right.
07:53
Maybe we unplug it from the network
07:55
or disable the network connection.
07:58
But we want to leave the system running so we can get an image of memory.
08:01
Maybe then the system can be
08:03
imaged so we can get a bit by bit copy of the hard drive
08:07
to capture all the relevant information that might be needed
08:11
for investigation.
08:13
Non volatile gate. Of course, he's on the long term storage,
08:18
like the internal hard disk.
08:20
Then the information gets examined after it's acquired.
08:24
One of the important things about forensics is
08:26
gathering information correctly,
08:30
dealing with the chain of custody correctly so that when we get to the point where it's being examined,
08:35
we know with certainty that none of the information has been tampered with or change in any way it has integrity.
08:43
This is critical.
08:43
That's why we always work with Reed on Lee. Copies of the information.
08:48
If you're analyzing information in any case, you should be using a copy. If possible.
08:56
We would want to do analysis on an original hard drive that was involved in some fraudulent activity. You make a copy. You do the analysis with the duplicate,
09:07
all the contents of the memory,
09:11
any network connections.
09:13
Many files and folders and directories
09:16
that are involved need to be considered.
09:18
All the log files, transaction logs,
09:22
application related logging.
09:26
There could be temporary files that get generated
09:30
during the course of using an application or a system itself.
09:33
Then we think about the utilization of the results of
09:37
the analysis.
09:39
How is this
09:39
pieced together to reconstruct what happened
09:43
that might be needed for a
09:45
illegal prosecution or could just be
09:48
performed to understand what went wrong and how to prevent it from happening again?
09:52
Finally, there's a review process,
09:56
looking again for lessons learned opportunities
10:00
to see what one right, what went wrong and where there's room for improvement.

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