CSSLP Tutorial: Module 07,Part 04 – Monitoring / Auditing

In this part of module 7, the topic really has more to do with monitoring and auditing. This is a topic about the product as it has rolled out into production. This is in the everyday sort of operations of producing the product.  The first area that will be discussed is over monitoring.  Specifically, steps will be covered as to software monitoring.   The big idea is that it continues to provide functionality as well as the protection that it was designed to provide as when it was first installed. We demonstrate monitoring by showing that we’ve gone through due care and due diligence.  The terms are a little different from each other even though people sometimes want to use them synonymously.

Due diligence is about the research that is involved and due care is more about what action is being taken. As an example of the due diligence, is being aware of the security regulations for my industry.  So, for example, knowing that you have to be particularly careful of protecting the privacy of patient healthcare information for each client or each individual. However, being knowledgeable of the privacy laws isn’t enough, there has to be an action associated.  This is the due care. So, for an example, of due care is that not only is the person aware but also then devise certain policies to do the action of the protecting of the patient healthcare information privacy issues.

Further exploration of due care and due diligence relates to the topic of monitoring in the cybersecurity world.   Due diligence again is like the research aspect, so it’s the part where the person is monitoring the network for compromises but also with specific applications.  This monitoring is once they’d been installed to ensure that there hasn’t been any compromises. When a person is collecting more information, for example when collecting information so as to prosecute an attacker so we may have to monitor access to and from a network resource perhaps.There’s very specific ways that we have to collect this information of concern so as to maintain it for forensics purposes.  We’ve really thought things through as to our process, so that we can collect the evidence for being used in the court of law.  Typically, for this kind of collection, it’s been done by a person who is trained to do that.

Another reason for monitoring and showing due diligence is watching our software/ network to make sure that our mechanisms are configured properly and that we can still provide a certain level of security.  It is an ongoing monitoring to ensure functionality of the program again with making sure that we are meeting the security compliance. For example, the CIA triad, which again means the Confidentiality, Integrity, and Availability aspects to make sure that any external threats are considered, detected, and attempts are unsuccessful.  Sometimes, the external threat can be successful, but often we can detect and eliminate before it actually makes any affect on our system. We want to continue to monitor performance and functionality but also maintaining monitoring mechanisms for security purposes as well.  If you’ve got a live portal hooked to a wall, I can easily setup a dhcp server that would provide ip addresses for hosts on your network, and dhcp provides a service but it isn’t very secure at all, natively. So, that’s very easy to do.   So, there’s a number of reasons for the monitoring process to be in place.

The collection of information is related to metrics.  Metrics are the pieces of information which has been collected and we want to make sure that those we obtain, document and monitor are good, quality metrics.  There’s basic qualities to be considered to identify if a metric is of a high calibre or not.  We want metrics to be consistent, quantitative, objective, relevant and inexpensive.  Each of the five elements are as important as is the next.

Consistency is listed as first.  It means that if we go through data, and collect a sample at a certain point, then the data should be reflective of the same or equivalent and other points along the way.  We shouldn’t get much variation between the point at zero minutes versus the point at five minutes away from where we started.  So, it’s important for the data to be consistent. Second, the metrics need to be quantitative.  Risk analysis can be either qualitatively done or it can be done quantitatively.  We want in this case for the situation to be more of a quantitative nature.  So, we want something that is numeric in nature. Instead of saying something like, It’s effective.  We’d get instead, that there has been a 10% drop in successful attacks.  That way, it is more numeric and more objective and less judgement involved on the part of the person making the analysis.  We also want the information that we collect to be unbiased or objective. 

This way we can have a bit more confidence in the statistics obtained. For example, Microsoft publishes a ton of different tools for monitoring. However, it’s Microsoft monitoring Microsoft products.  This definitely represents a conflict of interest, in that how accurate will their results be because they are interested in making the other products “look good” rather than presenting truthful results.  So, we want a third party to help provide an analysis to ensure that objectivity and/ or unbiased results.   Last, we want to ensure cost-effectiveness as opposed to just simply cheap.  We want to actually compare costs and benefits and not just go automatically for the most expensive or for the cheapest product.  We really want to make sure that it will fit our needs with it being not so cumbersome in cost that it’s impossible to be able to gain because we’ve spent too much.  There’s five factors to consider when deciding on what metrics collection device or tool we are going to use, for obtaining our results. All of this relates to monitoring.

Along with monitoring comes auditing.We want to make sure that our audit policies are in line with not only our system and the product(s) we’ve created, but also in line with our organizational policies.  Basically, we are auditing the accounts to make sure they don’t exhibit authorization creep. This is where accounts accumulate rights and privileges based on previous tasks and being able to see certain aspects and then not deleting those rights and privileges before moving on to the next task.  So, part of the auditing process is to check and monitor progress on whether the accounts are creeping in their rights and so on, or do they go back to what they started out with.  Another way we can mitigate the authorization creep is through rules-based access controls.  This is where permission isn’t automatically granted and instead your role has the rights and permissions assigned to it. Regardless, however, really regardless of your role you perform on the network, you get that set of permissions and after the job or task is completed, they need to be eliminated off your account so as to not continue the creep.

In overview, auditing is all about checking the accuracy of interactions coming into our network and any of the interactions on the way out the door of our network.  Attackers like to clean up their tracks, so we also want to make use of hashes and message digests to guarantee the integrity of our audit logs.  In addition to the auditing process, and really what allows for the auditing to take place is monitoring.  There are five key aspects to monitoring. They include for the metrics to be consistent, quantitative, objective, relevant and inexpensive.  These two major topics together are applied once the product is out in the production stages.

Enjoy this blog? Please spread the word :)