0

NIST SP 800-92 Logging

  • updated 8 mths ago

Description

With release v8.1, LogicNets' security event logging aligns with the NIST 800-92 guideline, which provides a high-level overview and guidance for planning, developing, and implementing an effective security log management strategy. The NIST 800-92 guideline covers both infrastructure, organization, and applications, and the LogicNets runtime aligns with the NIST guidelines for applications (NIST 800-92 / 2.1.3), events correlation (NIST 800-92 / 2.3.1 and 3.2), and offloading event logs to protect the system against tampering.

The NIST guideline recommends logging all security related events, including the following: 

  • Client Requests and Server Responses. These can be very helpful in reconstructing sequences of events and determining their apparent outcome. If the application logs successful user authentications, it is usually possible to determine which user made each request. Some applications can perform highly detailed logging, such as email servers recording the sender, recipients, subject name, and attachment names for each email; Web servers recording each URL requested and the type of response provided by the server; and business applications recording which financial records were accessed by each user. This information can be used to identify or investigate incidents and to monitor application usage for compliance and auditing purposes. 
  • Account Information. This includes information such as successful and failed authentication attempts, account changes (e.g., account creation and deletion, account privilege assignment), and use of privileges. In addition to identifying security events such as brute force password guessing and escalation of privileges, you can use it to identify who used the application and when each person used it.
  • Usage Information. This includes information such as the number of transactions occurring in a certain period (e.g., minute, hour) and the size of transactions (e.g., email message size, file transfer size). This can be useful for certain types of security monitoring; for example, a ten-fold increase in email activity might indicate a new email-borne malware threat and an unusually large outbound email message might indicate and inappropriate release of information.  
  • Significant Operational Actions. Information such as application startup and shutdown, application failures, and major application configuration changes can be used to identify security compromises and operational failures.

Client requests and server responses and usage-information events shall be logged by the Cloud or on-premises infrastructure. The LogicNets runtime and system applications log account information and significant operation actions, including the following types of events:

  • User authentication, authorization actions and failures
  • User details modifications (password, name, email)
  • User groups and role modifications
  • Session creation and deletion

The system stores security event logs in the changelog together with application events, and you can review it using the LogicNets standard reporting application. For a detailed list of security logging events, see Security Event Logging

A background task that runs every 5 minutes also copies the security event logs to a JSON-formatted log file (/dat/log/events_<date>.json). You can pick up these JSON-formatted log files by log scrape/collecting tools like the AWS CloudWatch agent and the Azure Monitor agent. The system uses the AWS CloudWatch agent on LogicNets-hosted installations to move security event logs to a central CloudWatch database for long-term storage and to protect the log from tampering. 

Configure Logging

To configure the log event collection in AWS do the following:

  1. Update the IAM Role and add policy CloudWatchAgentServerPolicy.
  2. Install the CloudWatchAgent using System Manager from the LogicNets instance:
    https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance-fleet.html#download-CloudWatch-Agent-on-EC2-Instance-fleet
  3. Create a config file called C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\config.json with the following content:
    {    "logs": {
            "logs_collected": {
                "files": {
                    "collect_list": [
                        {
                            "file_path": "D:\\*\\logicnets\\dat\\log\\events_*.json",
                            "log_group_class": "STANDARD",
                            "log_group_name": "/logicnets/runtime",
                            "log_stream_name": "{instance_id}",
                            "timestamp_format": "%Y-%m-%dT%H:%M:%S",
                            "timezone": "UTC",
                            "retention_in_days": 90
                        }
                    ]
                }
            }
        }
    }
  4. Restart the CloudWatchAgent service.

Event correlation is an important aspect of the NIST guideline. Most (Cloud) infrastructures add trace IDs to HTTP request headers. AWS adds the X_AMZN_TRACE_ID HTTP header, and the LogicNets runtime adds the value of this header to every event log. This enables event correlation between LogicNets-generated events and AWS-generated events. You can change the default header by adding the following statement in settings.cfg: _global. HOST_REQUEST_ID_HEADER = "HTTP_<header-name>".
 

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 10 mths agoLast active
  • 25Views
  • 1 Following

Home