Who should care about logging and monitoring? Not just IT
Logging and monitoring are important pieces of the set controls which protect a company’s data and operational ability. It is complex with highly technical components, possibly making it intimidating for non-technical professionals to be involved in the planning, implementation, or review of a logging and monitoring program. However, it is important that other members of management, in addition to IT, are involved for many reasons:
- A logging and monitoring program could use an infinite amount of resources. Management should understand if their program is using time and money effectively.
- There are regulations which require logging and monitoring, and management is responsible for compliance.
- Logs can capture data which could be helpful to operational or financial teams. Management should understand the capability of the IT systems performing the logging and monitoring to see if the data can be used for operational or financial analysis.
This post is intended to help non-technical individuals understand some basics of logging and monitoring controls with points of consideration which could potentially go overlooked. It could help facilitate conversations with IT to develop logging and monitoring policies, to improve existing procedures, or to help other areas of the business get the most out of an existing logging and monitoring program.
For a detailed understanding of all of the components of a logging and monitoring program, one of the most thorough resources is the Guide to Computer Security Log Management published by the NIST.
The basics of logging & monitoring
Logging is capturing data from the IT systems, which creates a log, and monitoring is reading the logs to look for something specific, like a security breach or a problem with the system. The components that will be critical to understand when thinking about logs is the type of information captured, where it is captured, and how long it is retained. For monitoring, consider who should be performing data reviews, what they should be looking for, how frequently it should occur, and if it can be automated.
What logging should be enabled?
This is an important question where other members of the business should be involved. IT will probably be focused on system security and performance logging and can explain the merits, but there are additional reasons for logging which should be brought to the discussion.
Logging for Fraud Detection or Investigation
Logs can be used for fraud or theft detection or investigation. Examples are the best way to illustrate some different capabilities. By reviewing application transaction logs, one could see if an AP clerk is inputting invoices at unusual times, which might indicate fraudulent transactions. If a theft occurs, reviewing key card access logs could identify individuals to investigate. If a user changes their permissions to circumvent access-controlled segregation of duties to create and pay a fraudulent vendor, logs could be used to detect or confirm this action. Consider different types of fraud could occur in your business and if logs could help a detection or investigation.
Detection vs. investigation: For detection, logs must be reviewed frequently, or notifications can be set up to alert the appropriate party if specific events occur. Ensure the reviewer is independent from the individuals who are capable of performing the suspicious activity. For investigation, consider how long the logs must be retained in order to have enough data for a thorough investigation. For both detection and investigation, management must determine the suspicious activity, transaction, or action, and IT enables logging to capture that data.
Logging and Monitoring for Compliance
There are several sets of regulations which require companies to retain and review logs. The compliance department should be involved in selecting which logs are enabled and how they are reviewed to ensure adherence to these regulations. The following is a list of regulations which require a logging and monitoring program and the type of institutions to which the regulation applies:
- Federal Information Security Management Act of 2002 (FISMA) applies to Federal agencies.
- Gramm-Leach-Bliley Act (GLBA) applies to financial institutions.
- Health Insurance Portability and Accountability Act of 1996 (HIPAA) applies to holders of health information.
- Sarbanes-Oxley Act (SOX) of 2002 applies to public companies.
- Payment Card Industry Data Security Standard (PCI DSS) applies to organizations that store, process, or transmit cardholder data for credit cards.
Some of these regulations, like FISMA require a logging and monitoring program as part of the security controls, while others, like PCI DSS, specify the data which needs to be logged.
Logging based on Risk
IT systems have great capacity for logging, but the more robust a logging and monitoring program, the more resources it will require. Therefore, management will need to prioritize which logging is enabled based on risk.
Logging and monitoring can be key controls to mitigate many risks, so involving IT in the development of a risk assessment and mitigation document is valuable as they understand the logging and monitoring capabilities of systems. Then as management determines its risk appetite and evaluates the severity of each risk, that will determine which logs will be enabled on which systems or servers. Here are two examples:
Example 1 : Management determines that the risk of non-compliance with HIPAA requirements to be high priority. Therefore, logging is enabled on servers which store patient health information, which capture who is accessing the server and all changes made to the data.
Example 2 : A company has a warehouse containing only old product and no IT equipment or documentation of any kind. Management has deemed the risk of unauthorized entry low. Although the key card system has the capability to log who enters and when, logging is not enabled, because of the low risk.
The NIST eloquently stated: “A fundamental problem with log management that occurs in many organizations is effectively balancing a limited quantity of log management resources with a continuous supply of log data.”
Logging and Monitoring Tools
Tools, which require human and financial resources, are available to automate the monitoring of activities captured in the logs. Most IT departments will have these already and are often looking for investment to build out the capabilities of the tools.
Space and Processing Power
Capturing data and writing it to a log requires processing power and space to store the log files. Two things determine how onerous logging will be to the IT infrastructure: the number of days the files are retained and the number of entries in each log. Some come companies use a blanket retention period for all logs or have all available logs enabled. Instead, using the risk based approach to determine retention and which activities are logged can save quite a bit of resource.
People and Time
Logging and monitoring programs require personnel resources and their time, which costs a company money. Using a risk-based approach can lessen the chance of personnel being bogged down with too much data to review. Also, personnel expertise and independence issues are important to consider when determining who is performing the monitoring for the different types of data captured in each log.
There are many third-party service providers which can assist with part or all of the logging and monitoring process: configuration of the logging, capturing, and storage of the logs, and/or monitoring the contents of the logs. Outsourcing could be a great option to save money and utilize the expertise of others.
When relying on a third-party for performing any of the logging and monitoring process, even if it is just storage, it is essential to understand the controls the third-party has in place. Management should obtain a SOC report from the service provider to review the controls in place around the security of the log data and the monitoring of logs. Reference this blog entry if there are findings in SOC report for a company providing your logging and monitoring services.
Logging and monitoring can be quite technical in its execution, but as you can see there are many considerations and decisions to be made with the help of IT’s strategic business partners (upper-level management, finance, compliance, operations) to develop a plan that works for the company and uses resources wisely. Our firm provides SOC , HIPAA security , and FEDRAMP audits to to help companies verify that they have secure logging and monitoring processes in place. Please contact us if you would like to learn more.
Linford & Co., LLP, founded in 2008, is comprised of professional and certified auditors with specialized expertise in SOC 1, SOC 2, HIPAA, HITRUST, FedRAMP and royalty/licensing audits. Our auditors hold CPA, CISA, CISSP, GSEC licenses and certifications. Learn more about our company and our leadership team.