Chris,
To describe a proper security audit would take more than an email. But when
conducting a security audit, I look at the following things. Sorry don't have
time to get to deep into this, but this should give you a good idea where a
security audit starts.
Access to systems. This includes:
Connection Paths: How are connections being made to the servers and
application. Are there direct logins to servers, console access, what hops are
being made. Are those connections encrypted.
Authorization: I really like to see a paper trail that says DBA Joe can have an
account on xyz and DBA Joe can be granted DBA rights. This goes the same with
all users. I normally pick a random set of users and dbas to audit the
authorization. Is there a remedy ticket, an email, a form to support the
authorization. There should always be something to support access authorization.
Authentication: How are DBA’s and users authenticating the system / serves? Are
there inherent weaknesses in the authentication. Are common accounts being
used. I still see people connecting to servers as oracle then doing their work
AS SYSDBA and users sharing an account to make things more “efficient.”
Audit Implementation: What is the customer auditing, how they are performing
the audit. Are they using, syslog, Audit Vault, Oracle Audit, FGA, etc. How are
they auditing the application server. Who is reviewing the audits and how often.
Encryption implementation: Surprisingly, if encryption is not implemented
properly you wind up chasing ghost data and deal with data leakages. Is the
customer using tablespace encryption, column encryption and what about their
implementation of network encryption. There are a lot of places here where
things can go wrong.
Is the system internal facing or internal facing. If it’s an external facing
system, I’m going to put a lot of focus on sql injection flaws. If the system
is internal, it’s a bit easier, but I still look for sql injection.
App code. Scan code for sql injection flaws. Look to see if the database app
code is using packages as opposed to functions and procedures. Look to see if
packages are created using definers rights or invokers rights or some
combination thereof.
Are the apps using ACLs. Surprisingly, a lot of shops are not using ACLs.
-Rob
===================================
Robert P. LockardOracle ACEWinner of the 2015 Oracle Developers Choice Award
for Database DesignPresident Oraclewizard.com, Inc.
The question is not “who is going to let me,” it's “who is going to stop me."
Ayn Rand
(cell) 571.276.4790
(office) 410.766.6960
(fax) 410.766.0332
twitter @navonpilot
youtube https://www.youtube.com/user/n4281k
blog: http://www.oraclewizard.com
-----Original Message-----
From: Chris Grabowy [mailto:cgrabowy@xxxxxxxxx]
Sent: Thursday, August 11, 2016 09:38 AM
To: ''ORACLE-L''
Subject: Oracle Security Audit
I searched through the backlog of Oracle list emails I have and I do not see
this question being asked so….
My manager stopped by and mentioned that Oracle will be coming in next month to
do a Security Audit.
Uh, ok. No other details.
Apparently this is no cost Oracle Security Audit.
So this could either be a Q&A session and they recommend some security products
to improve our security.
Or this could be an exhaustive audit of our configuration from every possible
angle.
Has anyone else had an Oracle Security Audit performed at their site?
Should I just resign now? Should I switch to the SQL Server team? Should I move
my desk to the basement? Or change to my dream job of studying sloths in the
rain forests of Costa Rica?
Thanks,
Chris Grabowy
