RE: Auditing of FAILED_LOGIN_ATTEMPTS value on Oracle profiles
Date: Fri, 6 Dec 2013 13:57:36 -0500
Message-ID: <D623983FC52A9346AC003016DE490B4F01AEB885_at_V53-EX02.nets.nemais.navy.mil>
I wouldn't be surprised if your auditors have a problem with "someone in IT" having the ability to access your production database and bring it down in that way. I would say the solution is not to change the # logon attempts value but to prevent them from hitting the production db in the first place. I would say the solution is not to relax the standard because it works as designed :d.
Don Freeman,
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Rich Jesse
Sent: Friday, December 06, 2013 10: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 - 19:57:36 CET