Information
Enabling this audit option will cause auditing of all attempts to connect to the database, whether successful or not, as well as audit session disconnects/logoffs. The commands to audit SESSION, CONNECT or CREATE SESSION all accomplish the same thing - they initiate statement auditing of the connect statement used to create a database session.
Rationale:
Auditing attempts to connect to the database is basic and mandated by most security initiatives. Any attempt to logon to a locked account, failed attempts to logon to default accounts or an unusually high number of failed logon attempts of any sort, for any user, in a particular time period may indicate an intrusion attempt. In forensics, the logon record may be first in a chain of evidence and contain information found in no other type of audit record for the session. Logon and logoff in the audit trail define the period and duration of the session.
Solution
To remediate this setting, execute the following SQL statement in either the non multi-tenant or container database, it does NOT need run in the pluggable.
AUDIT SESSION;
Notes:
Although listed in the documentation as a privilege audit, audit CREATE SESSION actually audits the CONNECT statement. This is evidenced by the undocumented audit CONNECT which has the same result as audit SESSION or audit CREATE SESSION. There is no system privilege named either SESSION or CONNECT (CONNECT is a role, not a system privilege). Also, it behaves as statement auditing rather than privilege auditing in that it audits all attempts to create a session, even if the user does not hold the CREATE SESSION system privilege.