RE: Auditing of FAILED_LOGIN_ATTEMPTS value on Oracle profiles

From: MacGregor, Ian A. <ian_at_slac.stanford.edu>
Date: Fri, 6 Dec 2013 08:51:47 -0800
Message-ID: <FD1D618E4F164D4C8BA5513D4268174A01A1AB9B0983_at_EXCHCLUSTER1-02.win.slac.stanford.edu>



There are accounts, usually labeled service accounts, which should be exempted from these rules because the denial of service which would result from their being locked is too costly. This in exemption is not to be universal, but applied to only those accounts which qualify. The accounts should be audited for failed login attempts.

Ian A. MacGregor
SLAC National Accelerator Laboratory
Computing Division.



From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of Rich Jesse [rjoralist3_at_society.servebeer.com] Sent: Friday, December 06, 2013 7:07 AM
To: oracle-l_at_freelists.org
Subject: Auditing of FAILED_LOGIN_ATTEMPTS value on Oracle profiles

Hey all,

I'm expecting to get dinged on an audit because I have FAILED_LOGIN_ATTEMPTS set to 10 in a profile (11.2.0.3, if that matters). On our new DBs, I plan on changing that to UNLIMITED. The initial feedback from the auditors is that "the recommended is 3 to 5".

I reasoned that instead of a malicious attempt to break in to our ERP DB, it's much more likely that someone (in IT) will accidentally choose our Production ERP DB when they meant to choose Development (which has a different password), causing login failures which could lockout the account, effectively causing a denial of service. This has already happened, but with a non-existent user, so no harm done.

I have EM12c paging me for EVERY login failure in Production, since there are no user logins other than for the DBA (me).

What do others do? Take the audit hit and just move on?

TIA!
Rich

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Fri Dec 06 2013 - 17:51:47 CET

Original text of this message