Powerful features of PFCLScan
When we designed PFCLScan we wanted to have a very powerful tool that is able to scan Oracle databases and the servers that they run on for security issues but also to be able to do what I have done for many years manually. That is to correllate and match and use results across many checks. The idea being that you can ask the sorts of questions such as "if we have this" and also "this is set" and "in the database there is this" but "on the OS there is this" ..... the design of PFCLScan focused around these ideas of sophistication and also cross boundaries such as OS/Database/Network and even asking questions verbally. We designed PFCLScan to be powerful so that customers can work and create their own policies to satisfy internal security standards and requirements but also so we can use that power in the policies we ship for customers who prefer to simply run out of the box.
We have come across a phenomena a few times when using PFCLScan in "user/customer" space over the last couple of years. By "user/customer" space we mean writing policies or reports or checks where we are using the PFCLScan software to create content rather than developing new features of PFCLScan.
It is really surprising and fun to find a feature in our product or a way of doing something that we did not intend. What I mean is we found a way to do something that we didnt design.
We have a number of features in PFCLScan where we get productivity and also sophistication in terms of developing checks and policies quickly or in terms of saving time because we can utilise existing code or checks where they change slightly rather than having the same code repeated many times with slight differences. We added libraries to allow this where you create some source code as a check in a policy and instead of it being pure SQL or pure PL/SQL or pure shell script or pure LUA or pure.... then we are able to create a policy and check as a library and insert special variables where the "template" of code needs to change for a particular check. Then the library policy is used in exactly the same way as a standard check except the user specifies a check type of LIBRARY and instead of writing code simnply supplies the template variables. This is a great space and time saver.
Libraries provide the first layer of productivity but pre-conditions and loop conditions also provide time saving and space saving opertunities. An example would be for a pre-condition would be to have a check that determines the version of the database and then for a subsequent policy/check to use the version as part of its code. Again this is achieved by a simple substitution variable that PFCLScan knows how to handle. In the PL/SQL or SQL or shell or LUA code we add a variable such as:
and version <>{{1}}
In this case the engine knows to go and get {{1}} from a previous check. This can be considered a static check and in C language parlance it is similar to a #define, except that the #define is dynamic in that its read from a previous check not hard coded.
Then the next layer of power is the "loop" construct. Imagine we have a need to determine the security access for all database tables that contain credit card details but we don't know what those tables are before we start. This as an example is where the "loop construct" comes into play. We can write a query in one policy/check - in any language but SQL or PL/SQL would be suitable in the database. This check returns a list of schema.table_name. This can be passed to a further check using the "loop construct" - again simply a substitution variable such as:
select privilege from dba_tab_privs where table_name='##1##' and owner='##2##'
Where ##1## and ##2## are passed in by PFCLScan automatically via the "loop contstruct" mechanism. This, unlike the "pre-condition" is a dynamic substitution and is very powerful again for adding sophistication to PFCLScan checks either shipped by us or written by you.
These two elements, "pre-conditions" and "loop constructs" along with libraries and also config values add a massive amount of power to what you can achieve in policies for PFCLScan and of course of the Oracle security questions it can answer.
Back to the plot of this post. We have added PFCL.config to PFCLScan recently and this will be available in the next service release as a new feature. The PFCL.config functionallity allows a user to change pre-defined values such as the name of a custom DBA role created on their site and to take advantage of builtin checks that determine whether the customer has implemented their custom DBA role and further that only the DBA team are using it. When implementing this we discovered that we supported a feature of "pre-conditions" that we did not design originally. The idea behind a pre-condition is that one check returns one or more lines of PFCLScan XML output and this is then used in a subsequent check. For PFCL.config we discovered that we can list out all PFCL.config parameter values in one built in check and then use each seperately in later checks simply by adding the single variable {{n}} in the relevant check that uses the PFCL.config data where "n" is the entry number in the config. This was great as originally we intended all "pre-conditions" when used to be consumed as a whole; now we can consume a "pre-condition" line by line in any check. Of course customers can use the same technique in their custom policies.
One of the poweful factors of PFCLScan is that its purpose originally is to perform very powerful audits of Oracle databases but because we support so many check types we can use PFCLScan for other targets easily.
PFCLScan is very competitively priced; £849 + VAT for an annual "Pro" license; one installation and scan as many of your databases as you wish, £2,495 + VAT for an annual "Enterprise" license; unlimited installations in your organisation and unlimited targets to scan. We have also added an "Engagement license" for 30 days priced at £110 + VAT for one installation and scan as many targets as you need.
Please email pete at petefinnigan dot com for more details or to purchase a license.