The power of PFCLScan

When we designed PFCLScan we wanted to create a database security tool that would be useful to security people, DBA's, Developers and more. For it to be useful, not only should it run its own out-of-the-box policies for the Oracle database but it should be easy for the customer to create their own database security policy that maps easily to their own requirements. In other words a customer would have their own database security policy in a Word document or as a simple set of SQL checks or as part of a lock down script - again maybe SQL*Plus based or maybe there are more generic company wide security policies that should be implemented within the database?

Of course you can run our security policies for the Oracle database and that will give you a detailed view of your current Oracle database security but it would be much better to create your own policy specific to your own site.

This idea of making PFCLScan simple to use for someone who simply wants to run a scan on a database they own was a priority of course but for me it was more important to allow the customer to be able to easily create their own policies as I had a lot of SQL and PL/SQL and shell scripts that I used in my Oracle database security audits at that point and I wanted to find a way to create a useful tool that utilised that knowledge and of course added to it drastically.

The ability to create your own custom policies is enhanced by some of these features:

• You can start with our policies and turn off checks that you do not need or indeed you can turn off a policy that you do not need provided it is not referenced by another policy or check
• We have decided not to hide our checks. The code is not hidden or encrypted so you can view our code in our checks and modify it if you so wish to achieve your goals. You can of course simply cut and paste our code to a new check and modify to your hearts content also.
• We have added "libraries". This is a time saving construct. Basically imagine that you have multiple tests in an Oracle database for whether PUBLIC execute privilege is present for various packages such as UTL_FILE or UTL_TCP or UTL_HTTP. Instead of writing the code to do this check three times our library feature allows it to be written once. The code is written in the normal language such as SQL or PL/SQL and where the package would be named there are instead PFCLScan substitution variables. The library check is just a check in a standard policy so it can be written and edited in the same way as all other polices. The time saving is when you come to use it because you simply specify a library type check and specify the actual parameters not the code.
• All checks are gathered into groups called policies. Policies are simply XML files that are editable via the policy and check editors in PFCLScan.
• All of the code in your checks is editable in a programmers editor with color syntax highlighting, macros, snippets and all the features you would expect in a programmers editor
• All of the text for your check descriptions can be spell checked internally in the policy and check editors.
• We support many types of checks; you can write checks to target a database in SQL or PL/SQL and you can write checks that can ftp/sftp/ftps files, you can write checks that are questions to be asked via the interview screens, you can write checks to target the server in shell script, you can write checks via DOS commands so that essentially PFCLScan can be extended by calling your own perl or any other scripts. Also we have a built in scripting language that uses Lua plus extensions to allow you to write tests that are executed internally in the tool.
• We also support hierarchical checks both dynamic and static in nature. These use the same simple template based structure as the library templates and allow you to write checks that take input or depend on previous checks. This can be done statically before the check is run. So an example would be to substitute code that represents the database version to a set of checks before they run. Dynamically a check can also benefit from the hierarchical nature of processing. A good example would be that say we want to test the access permissions on all tables that hold credit card details BUT we don't know what those tables are until we find them. We can write a check that locates all potential tables in any language and then write a second dynamic check that takes the output from the first and for each table or view it goes and assesses the access rights. What is really powerful is that we can make either of these previous checks library checks as well.

PFCLScan is an open framework that runs on XML based files. All projects, policies, checks, results, configurations and more are XML files. The engine is able to run any set of policies and checks in any languages and also able to feed the results of checks statically or dynamically to further checks no matter the original language even including questions. So you can create an interview project, ask questions and record some answers and even feed those answers into technical type checks written in SQL, or Unix shell or even Lua.

The other great powerhouse of PFCLScan is its reporting language and plugin architecture. PFCLScan includes its own reporting language that supports a template like language. This was designed it be simple for end users to create their own reports or output. The idea behind it is that you can create a report like you want to see it. So you could create an HTML page with the correct boiler plate text and headings and more. Then you add variables where you would like the data to go; The data can be taken from PFCLScan settings, project settings, database settings, policies, checks and results. All of these are supported by loops on data and if statements.

This makes creating reports simple but because a report can be any text file creating any output or input is also simple. This leads to the ability to automate PFCLScan easily. PFCLScan is implemented as command line tools and a Graphical User Interface (GUI). The GUI can be used to manage projects, reports, policies and checks and of course to run scans but all of the scanner engine is implemented from the command line so PFCLScan can run completely from the command line if you wish.

Because the reports functionality and language allows any text based template to be used to generate output, the command line functionality combined with the reporting tool allows us to easy create automation's also with PFCLScan. This is admirably demonstrated in our plugin architecture. Our plugins are simply projects within PFCLScan itself using automation and libraries, projects, checks and of course our reports tool. This gives us great power as extending PFCLScan is a simple matter of creating a new project to do what you need.

A good example of a plugin is the functionality in the database connections screen. The connection tests for the database or to a Unix/Linux server are implemented as a plugin using an internal project. If you wish to see this, nothing is hidden, go and look in the plugins directory and open the database connection project for instance.

A another useful peice of functionallity to help customers write and test their own policies is the logging and trace interfaces. We have fully instrumented PFCLScan both in the GUI and also all command line modules. You can set the logging level of every component and the log windows show these in real time or if you run from the command line you can view these logs. You can also run silently and send logs to a file. Also its possible to enable trace from levels 0 - 9 on all components. These logs files and trace files are viewable and searchable within the GUI also. The main purpose is to aid development and testing of your own policies.

Using automation its possible to develop custom policies for PFCLScan that allows compliance testing and even integration with other systems. It is easy to run PFCLScan and generate input for a management console for instance or much much more.

We created PFCLScan to be powerful to allow it to be used in a myriad of ways but mostly so its useful and competitively priced.