Part 05 - Monitoring and Auditing

Video Activity

Once software is released it still must be monitored for proper functionality as well as vulnerabilities. This is important because not all defects are caught during QA testing and threats against applications are constantly evolving. These topics are covered in this video. We discuss the auditing process that goes hand-in-hand with monitoring. Thi...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

12 hours 41 minutes
Video Description

Once software is released it still must be monitored for proper functionality as well as vulnerabilities. This is important because not all defects are caught during QA testing and threats against applications are constantly evolving. These topics are covered in this video. We discuss the auditing process that goes hand-in-hand with monitoring. This is important for both gathering evidence in the event that we need to prosecute attackers as well as being essential for tracking performance metrics and ensuring that policies are being followed and are effective.

Video Transcription
now the next topic that we want to cover. Once the software has gone out into production, it's in the day to day environment is we want to monitor the software. We've already alluded to this a little bit. We want to make sure that it's continuing to provide the functionality as well as the protection that it was designed to provide
early on when it was first installed.
So we wanna look and make sure that we continue to meet our compliance requirements. Monitoring also shows that we've gone through due care and diligence. And if you're not familiar with those terms, just let me give you a cheapie definition of those
due diligence is research. Duke. Here is action.
Okay, Due diligence is research. Duke hears action. Now, please don't take those definitions back to law school with you, but it's a good cheapie definition for what we mean. So, for instance, being aware of the security regulations for my industry, that's due
diligence. I research, and I'm aware of the fact that we have
check the privacy of patient health care information. That's due diligence. The problem is just knowing that doesn't really do anybody any good I have to follow that knowledge up with Duke Ear, where I use certain policies to protect the hour. I device certain policies to protect the privacy
of patient health information.
So do diligence is the research do care is the action and I'm showing both due diligence and do care by monitoring my network for compromises but also with specific applications once they've been installed. I want to make sure that that application is continuing to maintain the degree of security that's necessary.
And there haven't been any compromises.
I may also continue to audit. Um, if I'm looking to collect information, um, maybe we're looking at prosecuting an attacker. So we monitor access to and from a network resource, perhaps, and we might do so in such a manner that we're collecting information
in a forensically sound
means we really have to have very thorough process is on how we're gonna monitor the network and how we're gonna collect this information because, especially if we're looking to collect evidence to use in a court of wall, there's some very particular, very specific ways that we have to do that in some big concern. So we want to make sure that if we are looking to provide
forensically sound evidence collection
that we've been trained to do, so
all right. Also, we may just want to be making sure that our mechanisms air still configured properly and that they're still providing the level of security that we thought or that we've decided would meet the requirements. So many different reasons to monitoring. It's just ongoing. We're keeping an eye on the application. We're doing a series of tests,
you know, based on a predefined sort of schedule, if you will,
to make sure we're still getting the functionality out of the software that we need.
All right. Other things. We want to make sure that the security aspects of the product are still working and again Anytime we say the security aspects, think the C. I. A. Triad confidentiality, integrity and availability.
Um, we want to make sure that any sort of external threats have been detected or able to be detected. You know, not every threat is successful. Many attacks also aren't just one time attacks,
so we may notice that there's been some sort of breach and even though in an attacker may not still be on the network. Currently,
there may be mechanisms that would allow that attacker to come back onto the network, and certainly we would always want to be aware of any sort of compromise that we've had. So we're gonna continue to monitor from a performance from a functionality standpoint, but also, essentially, from a security standpoint as well,
uh, will monitor network to make sure rogue devices haven't been added.
You know, if you've got a live report in the wall like very easily set up a d h c P server that would provide I P addresses for hosts on your network and D H E P is a service that isn't very secure natively, So that's fairly easy to do.
So ultimately, all those reasons you can think of monitoring the network again, Is it functioning as it should? Has the threat landscape changed? Are there new risks? And how's the application? Responding to these new risks isn't configured properly. Your policies being followed all of those ideas air perfectly relevant
for why we monitor,
um, when we monitor, we want to collect information and we want these metrics or this piece of information that we obtain that we document to be good quality metrics. We want the metrics to be consistent, quantitative. We want them to be object.
We want them to be relevant and inexpensive.
So when we go through these elements, these five elements consistency, meaning If I go back and sample the same data set,
the results should be the same or they should be equivalent.
So if I keep going back to the same data elements, I shouldn't get a variation between, you know, element. Uh, you know, element A. Now an element A in five minutes.
We want our metrics to be quantitative. Earlier, when we talked about risk analysis, we said, There's qualitative analysis and there's quantitative analysis.
So when I ask you how well a piece of software is performing,
you know, a qualitative response would be I was doing pretty well. It's pretty effective.
What I want instead is I want a quantitative response. I want something that's objective, and I want it to be New American nature. You know, we've seen a 3% decrease in successful attacks over the last quarter. You know that information is much more meaningful to me, so quantitative
it's gonna be precise. It's gonna be objective. It's gonna be new Mirror.
We certainly want the information that we collect to be unbiased or objective in nature. Sometimes you know, Microsoft gives us a 1,000,000 tools to monitor their Microsoft systems. And sometimes you wonder how objective you know the performance tools are
and the reliability tools are when it's a Microsoft product.
You know, analyzing we're evaluating another Microsoft product. So we want third party monitoring tools so that we can be assured of that objectivity.
And then also, we want the tools to be inexpensive. Or, I think, better than saying inexpensive is We want the tools to be cost effective that, based on a cost benefit analysis, we gain more than we spend. When we look at monitoring tools,
along with monitoring comes auditing, and we create our audit, polities out it policies, rather to track actions to a subject. So we're going to configure an audit policy that is in line with their system and organizational policy to make sure these policies are being followed
to make sure that, um,
accounts are accumulating rights and permissions through something called authorization creep.
Um, I don't know if you're familiar with authorization creed. But we have to go back and audit user accounts to keep this from happening, and I think I may have mentioned this earlier in the class. But what happens is that a user that's on the network, the longer they're on the network, especially as they're given different tasks to manage.
They tend to accumulate a lot of rights and permissions.
And then when I go to another department, I get additional rights and permissions heaped on my account.
However, what we miss a lot of times is revoking those earlier rights and permissions that are no longer necessary. And we call that authentication or authorization. We actually call it Authorization Creek.
So we have to audit those accounts another way that we could mitigate authorization. Authorization creep is through role based access control. We talked about that earlier, and we talked about you don't get permissions assigned your user account. Your role has certain permissions assigned to it. Regardless of the role
that you're performing on the networks,
you get that, um, that set of permissions and access.
All right. Auditing also lets us check the accuracy and completeness of transactions. We want to pretend our audit logs and make sure that they haven't been modified because an attacker does like to go back and clean up his tracks, so we would use hashes or message digests in order to guarantee the integrity of
those audit longs.
Up Next

Our free online CISSP (8 domains) training covers topics ranging from operations security, telecommunications, network and internet security, access control systems and methodology and business continuity planning.

Instructed By