Part 4 - Monitoring and Auditing

Video Activity

This lesson focuses on monitoring and auditing. Monitoring involves the continuous observation of a software post-installation to make sure it is properly working and meeting all the requirements specified by the contract. Monitoring also ensures software remains secure. There are five elements of good monitoring: • Consistency • Quantitative • Obj...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 54 minutes
Video Description

This lesson focuses on monitoring and auditing. Monitoring involves the continuous observation of a software post-installation to make sure it is properly working and meeting all the requirements specified by the contract. Monitoring also ensures software remains secure. There are five elements of good monitoring: • Consistency • Quantitative • Objectivity • Relevance • Inexpensive Audits are very important in that they can be used to verify information after an event and can also be used to ensure policies are being followed and to make sure individual accounts are in compliance with the rules and regulations of an organization.

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 due diligence. And if you're not familiar with those terms, um, 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 II research. And I'm aware of the fact that we have to protect 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 here, where I use certain policies to protect that our I devise certain policies to protect the privacy of patient health information. So due diligence is the research
Duke. Here 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
continue to audit is 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 a very particular, very specific ways that we have to do that. It's a 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, a sort of schedule, if you will, to make sure we're still getting the functionality out of software that we need.
All right, other things. We want to make sure that the security aspects of the product they're still working and again any time 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
reach, 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
will monitor network to make sure road
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 are 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 obtained that we document to be good quality metrics. We want the metrics to be consistent, quantitative. We want them to be jet.
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 a 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 or 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 gained 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 thio 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 Creek.
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 to 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 won't pretend our audit laws 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 on it long.
Up Next