Last week we released version 1.3 of our database security scanner PFCLScan. Version 1.3 has more than 220 changes over version 1.2 and these changes include new content in the form of new checks, modifications to some checks and also new features.
The major new features include the PFCL configuration screen. This gives you the ability to affect the standard Oracle database only audit policy set and also the Oracle database + Linux policy sets. You can now specify values to be used in a security scan/audit or even override scan values. This adds the “personal” touch to an audit where local policy and values can be used in a PFCLScan audit. Here are a couple of examples that use this new feature:
1) We calculate the ORACLE_HOME for the server hosting the database we are scanning using various techniques in the database and in most cases this would be the right value. This directory is then used in the operating system checks as a location for various things such as finding the listener control utility or checking the ORACLE_HOME/bin Unix file permissions match those specified in various industry Oracle security standards. If PFCLScan fails to find the right ORACLE_HOME location during the first scan you can go to the options page and change it manually so that it finds your ORACLE_HOME. Here is an example:
2) A second example is DBA’s and custom DBA roles. Our recommendation always is that each DBA (the person) has their own account within the database and that the customer does not simply grant the built-in DBA role to their DBA staffs accounts and should in fact define and design their own DBA role. The name of this role and “who is” a real DBA is only known to the user of PFCLScan not us in advance of running a scan. Because the user can now speficy the name of their DBA role – or even multiple roles and also specify a list of the authorised DBA accounts in the database we can now test whether that custom role(s) exist in the database and also whether the DBA users exist, we also test that only the DBA users have been granted the custom DBA role and no one else has it and even more…
These are two good examples of what we can do now with the configuration element of PFCLScan to make your audit of an Oracle database more appropriate to your own policies and security. As you may expect this facility is extendable. You can go to the options screen and the configuration page and add new name/value pairs yourself:
The standard Oracle database audit and database + Linux audit policies already pre-process the values we supply (54 currently) and automatically any you add. Of course we cannot predict what you may do with a new configuration value so you would need to write your own policy/check and use the new value in your check code. Remember the check code can be many different languages such as SQL, PL/SQL, Shell, Dos commands, Lua and more. Using the configuration value is as easy as adding a template variable in the middle of your code where you need to use it. Here is an example where we reference the list of DBA users defined by the user to test if they exist :
This example is in the policy check editor and you can see that it is as easy as adding template variables into the PL/SQL code.
In version 1.3 we have also enhanced the installation and code to allow PFCLScan to now work on Windows where different language settings are enabled. All of the internal date handling code has been re-written to work with only numerical dates as the previous versions that handled text months such as October or Okt or Oktober broke the application when dates were processed and the language was not English. This is now fixed.
We have also re-written our ssh engine so that it now processes (removes) Unix box banners emitted from motd, issue, .profiles, .rc, sshd banner and more. In parallel we have also re-written our set of Linux checks that test various Oracle security values on the Linux server and also test listener settings.
Some of the other highlights in version 1.3 include:
- Hundreds of new checks and enhancements to existing checks to work over a broader range of database versions
- We have also re-written some checks to work in a different way
- We have enhanced the documentation
- We have made a number of bug fixes
PFCLScan works remotely and does not require agents to be installed into database. It is very powerful and allows easy use out of the box to scan a database but also has the ease and power to translate your own internal Oracle database security policies to a custom PFCLScan report to easily test all of your databases internally against that policy
Of course the major benefit is PFCLScan’s cost-effective licensing based not on databases scanned but on the installation of PFCLScan software. This makes it really affordable for use as an auditor or internaly to test all databases.
We also added an engagement license for 30 days so you can install PFCLScan once and scan as many databases as you wish. This has been popular so far!
Please talk to us for more details.