> For the complete documentation index, see [llms.txt](https://community-test.logicnets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://community-test.logicnets.com/release-9/platform-documentation/system-administration/security/nist-sp-800-92-logging.md). # NIST SP 800-92 Logging ## Description With release v8.1, LogicNets' security event logging aligns with the [NIST 800-92 guideline](https://csrc.nist.gov/pubs/sp/800/92/final), 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](/release-9/platform-documentation/system-administration/security/security-event-logging.md). A background task that runs every 5 minutes also copies the security event logs to a JSON-formatted log file (*/dat/log/events\_.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: 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\_"*. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://community-test.logicnets.com/release-9/platform-documentation/system-administration/security/nist-sp-800-92-logging.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.