Despite the many challenges an organization faces in log management, there are a few key practices an organization can follow to avoid and even solve many of these obstacles it confronts. The following four measures give a brief explanation of these solutions:
- Prioritize log management appropriately throughout the organization.：An organization should define its requirements and goals for performing logging and monitoring logs to include applicable laws, regulations, and existing organizational policies. The organization can then prioritize its goals based on balancing the organization’s reduction of risk with the time and resources needed to perform log management functions.
- Establish policies and procedures for log management：Policies and procedures are beneficial because they ensure a consistent approach throughout the organization as well as ensuring that laws and regulatory requirements are being met. Periodic audits are one way to confirm that logging standards and guidelines are being followed throughout the organization. Testing and validation can further ensure that the policies and procedures in the log management process are being performed properly.
- Create and maintain a secure log management infrastructure. It is very helpful for an organization to create components of a log management infrastructure and determine how these components interact. This aids in preserving the integrity of log data from accidental or intentional modification or deletion, and also in maintaining the confidentiality of log data. It is also critical to create an infrastructure robust enough to handle not only expected volumes of log data, but also peak volumes during extreme situations (e.g., widespread malware incident, penetration testing, vulnerability scans)
- Provide adequate support for all staff with log management responsibilities. While defining the log management scheme, organizations should ensure that they provide the necessary training to relevant staff regarding their log management responsibilities as well as skill instruction for the needed resources to support log management. Support also includes providing log management tools and tool documentation, providing technical guidance on log management activities, and disseminating information to log management staff
- Log Generation. The first tier contains the hosts that generate the log data. Some hosts run logging client applications or services that make their log data available through networks to log servers in the second tier. Other hosts make their logs available through other means, such as allowing the servers to authenticate to them and retrieve copies of the log files.
- Log Analysis and Storage. The second tier is composed of one or more log servers that receive log data or copies of log data from the hosts in the first tier. The data is transferred to the servers either in a real-time or near-real-time manner, or in occasional batches based on a schedule or the amount of log data waiting to be transferred. Servers that receive log data from multiple log generators are sometimes called collectors or aggregators. Log data may be stored on the log servers themselves or on separate database servers.
- Log Monitoring. The third tier contains consoles that may be used to monitor and review log data and the results of automated analysis. Log monitoring consoles can also be used to generate reports. In some log management infrastructures, consoles can also be used to provide management for the log servers and clients. Also, console user privileges sometimes can be limited to only the necessary functions and data sources for each user.
- Multiple log servers that each perform a specialized function, such as one server performing log collection, analysis, and short-term log storage, and another server performing long-term storage.
- Multiple log servers that each perform analysis and/or storage for certain log generators. This can also provide some redundancy. A log generator can switch to a backup log server if its primary log server becomes unavailable. Also, log servers can be configured to share log data with each other, which also supports redundancy.
- Two levels of log servers, with the first level of distributed log servers receiving logs from the log generators and forwarding some or all of the log data they receive to a second level of more centralized log servers. (Additional tiers can be added to this architecture to make it even more flexible, scalable, and redundant.) In some cases, the first level servers act as log caching servers—simply receiving logs from log generators and forwarding them to other log servers. This can be done to protect the second level of log servers from direct attacks, and it is also useful when there are network reliability concerns between the log generators and the second level of log servers, such as those servers being accessible only over the Internet. In that case, having log caching servers on a reliable local network allows the log generators to transfer their logs to those servers, which can then transfer the logs to the second level of log servers when network connectivity permits.
- Log generation
– Which types of hosts must or should perform logging
– Which host components must or should perform logging (e.g., OS, service, application)
– Which types of events each component must or should log (e.g., security events, network connections, authentication attempts)
– Which data characteristics must or should be logged for each type of event (e.g., username and source IP address for authentication attempts)
– How frequently each type of event must or should be logged (e.g., every occurrence, once for all instances in x minutes, once for every x instances, every instance after x instances) - Log transmission
– Which types of hosts must or should transfer logs to a log management infrastructure – Which types of entries and data characteristics must or should be transferred from individual hosts to a log management infrastructure
– How log data must or should be transferred (e.g., which protocols are permissible), including out-of-band methods where appropriate (e.g., for standalone systems)
– How frequently log data should be transferred from individual hosts to a log management infrastructure (e.g., real-time, every 5 minutes, every hour)
– How the confidentiality, integrity, and availability of each type of log data must or should be protected while in transit, including whether a separate logging network should be used
- Log storage and disposal– How often logs should be rotated
– How the confidentiality, integrity, and availability of each type of log data must or should be protected while in storage (at both the system level and the infrastructure level)
– How long each type of log data must or should be preserved (at both the system level and the infrastructure level)46
– How unneeded log data must or should be disposed of (at both the system level and the infrastructure level)
– How much log storage space must or should be available (at both the system level and the infrastructure level)
– How log preservation requests, such as a legal requirement to prevent the alteration and destruction of particular log records, must be handled (e.g., how the impacted logs must be marked, stored, and protected)
- Log analysis – How often each type of log data must or should be analyzed (at both the system level and the infrastructure level)
– Who must or should be able to access the log data (at both the system level and the infrastructure level), and how such accesses should be logged
– What must or should be done when suspicious activity or an anomaly is identified
– How the confidentiality, integrity, and availability of the results of log analysis (e.g., alerts, reports) must or should be protected while in storage (at both the system level and the infrastructure level) and in transit
– How inadvertent disclosures of sensitive information recorded in logs, such as passwords or the contents of e-mails, should be handled.
Organizations should also ensure that other policies, guidelines, and procedures that have some relationship to logging incorporate and support these log management requirements and recommendations, and also comply with functional and operational requirements. An example is ensuring that software procurement and custom application development activities take log management requirements into consideration.
Reference NIST SP800-92
沒有留言:
張貼留言