Requirements and Implementation for Audit Log for Data Changes

[MaeganWood64]

• As of 10/19/23 the requirements for audit log data changes have not been analyzed and confirmed by the EPA. CVP started the requirements anaylsis process. You can find the started requirments at the following link.

• https://usepa.sharepoint.com/:w:/r/sites/CAMDCVPTeam/Shared%20Documents/Tech/Audit%20Log/EASEY%20Requirements%20for%20Audit%20Event%20Logging.docx?d=w72fca1cd69c241dc84b9339e1ec87b69&csf=1&web=1&e=TFWoqh

Next steps:

• complete requirements analysis
• Decompese tickets into the backlog

Needs to be implemented before performance testing.

[MaeganWood64]

• Out of Scope for March Beta

[JanellC]

Need requirements for what needed to be audited. Mike H will send over requirements . Requirements will be sent week of 5/29

[JanellC]

Aiming to work on this after the ECMPS BETA functionality is completed

[JanellC]

@JanellC add requirements to this ticket for whoever picks this ticket up

[mark-hayward-erg]

@maheese Is this covered by #6246, or does additional logging need to be defined in this ticket (or other new tickets)?

[maheese]

@maheese Is this covered by #6246, or does additional logging need to be defined in this ticket (or other new tickets)?

6246 was intended to cover AC-6(9) which just deals with privileged functions. In our case we are defining these as any action that requires ECMPS Admin. Privileged audit records are called out separately in the controls.

This ticket was created to cover general audit requirements. Since this ticket was initially created we have received additional guidance on what event types need to have audit records. Here's what was provided:

• User Authentication (Success/Failure)
• User Access of Application Components
  • File and Object Access
  • Audit Log Access (Success/Failure)
  • System Access (Failure)
  • Application Transactions
• Transaction Logs
• System Performance and Operational Characteristics
  • Resource Utilization
  • Errors (Input Validation, Disallowed Operations) and Exit Codes
  • Process Status
  • Service Status Changes (e.g., Started, Stopped)
• Application Configuration and Version, Middleware Configuration and Version
• Usage Information, if Applicable
• User Request and Response Events, if Applicable

For each event we are supposed to be capturing:

• What type of event occurred
• When the event occurred
• Where the event occurred (component, system, etc.)
• Source of the event
• Outcome of the event
• Identity of any individuals, subjects, or objects/entities associated with the event.

We should have a discussion and come to a consensus on what these mean for our system and then create additional tickets to implement.

[alangmaid]

@maheese for each of the bullets above can you add the applicable NIST Standard and/or Security control? Doing so will enable us to tag the logs and facilitate providing evidence for annual security reviews.

[maheese]

@maheese for each of the bullets above can you add the applicable NIST Standard and/or Security control? Doing so will enable us to tag the logs and facilitate providing evidence for annual security reviews.

@alangmaid sorry, just seeing this now. These requirements come from NIST 800-53 AU-2 Event Logging and AU-3 Content of Audit Records. The specific EPA requirements for these controls are in the EPA's Audit Policy. The Audit Policy defers to M-21-31 as to what to audit. The list that I supplied in the comment above is from M-21-31, Appendix C, page 40.

[alangmaid]

Thanks @maheese.

[maheese]

@ergjustin I think most of what is required can be covered by adding logging to the API's since the endpoints identify the type of event (checkout, revert, create activity, etc.).

For content:

• What type of event occurred
  • This is the endpoint
• When the event occurred
  • Logged time
• Where the event occurred (component, system, etc.)
  • The app is automatically added to the log
• Source of the event
  • Source IP?
• Outcome of the event
  • The response status (success, bad request, not found, etc.)
• Identity of any individuals, subjects, or objects/entities associated with the event.
  • For authenticated methods we would log the cdx-user-id of the caller
  • For objects/entities associated we could log the Id (monPlanId, testSumId, etc.)

It would be good if we could use a structured format:

{
   "eventName": "Revert monitoring plan",
   "eventOutcome": "success",
   "eventSource": "0.0.0.0",
   "userId": "test-user",
   "moreInfo": "..."
}

There are process that run outside of the API requests, such as Quartz jobs, that we also need to make sure we are logging.

Lastly, we need to make sure that we are trapping any errors/exceptions that are being thrown and make sure those are logged.

[ergjustin]

LoggingInterceptor Doc : https://docs.nestjs.com/interceptors#aspect-interception

Now, it's not deployed in dev env, so I couldn't test with cloud.gov and kibana. I only tested on local env.

The below listed APIs I used the LoggingInterceptor

auth-api	camd-services	monitor-plan-api
sign-in	evaluation	revert
sign-out	queue [Creates submission]	POST - check-outs/plans/{planid}
create-activity		PUT - check-outs/plans/{planid}
		DELETE - check-outs/plans/{planid}

When the error occurs from Auth Guard, it does not catch the interceptor (link, link)