Call: +44 (0)1904 557620 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "How do we Train Staff to do Oracle Security?"] [Next entry: "Happy 19th Birthday Limited"]

Pete, Did You Deliver The Wrong Product?

We sell a number of software products aimed at helping secure data in an Oracle database and we get this issue / point / question coming up from time to time. Yesterday morning I got an email from a customer who we bought a license for our product PFCLObfuscate which is used to protect your PL/SQL in your customers database. The question was; we ordered PFCLObfuscate but you sent us PFCLScan?

Maybe we need to explain this more clearly to customers and so it is worth me doing that now in this blog post.

We did ship the software correctly and the end customer did get PFCLObfuscate BUT they also got PFCLScan because all of our products are build on top of PFCLScan. In effect PFCLObfuscate, PFCLCode, PFCLForensics and PFCLCookie are all built as Apps in side of PFCLScan. Here is the launcher that starts if you purchase a license for a product without PFCLScan:
PFCLScan Applications Launcher

Then if you click the PFCLObfuscate option in this example the PFCLObfuscate app starts and behaves like a standalone windows application BUT PFCLScan is behind it providing the functions needed:
PFCLObfuscate Started from the lancher

This was an architecture decision I made a long time ago. I wanted to maintain one code base (which is very large now) and use the functionality of the core product (PFCLScan) within all of the other products. This saves development time massively, maintenance time and makes it easier to develop, build and ship these products. Each App also uses lower level features and functions within the main PFCLScan scanner so again saving development time. We use plugins in the scanner to do the work in each App; this means that a lot of the development time can be done in user space of PFCLScan rather than the core C code or .NET code. We can develop plugins that do the work and the GUI side just needs to open the output and display and manipulate it. We can also use the full reporting interface and language in each App and we can use the core trace and logging from PFCLScan in each App. We can use many features and functions of PFCLScan to make it much easier to develop new applications and this is what I planned from the start.

PFCLScan uses an open architecture that allows projects to be created in User Space that can have any number of policies and any number of checks and each check can be written in many different languages such as SQL, PL/SQL, Lua, Shell Script, SSH, DOS (Windows Cmd) and many more. Each check can also take input from previous checks in a static way similar to #defines in C and also dynamically at run time. The project based scanning feature is more powerful as we can run these projects also completely from the command line with one single command. This allowed us to create plugins for PFCLScan as a Plugin is simply a project to run in PFCLScan that can have a single input file (parameters) and a single output file which can be XML, JSON, Text, whatever you need. Even this aspect of plugins uses reusability in that the plugins call the scan engine and reporting engine.

We created the Apps as I discussed by using plugins to do a lot of the work and save development time but we also created two OEM plugins so far that allow our tools to easily allow our database security scans, or obfuscation, or PL/SQL code reviews to be added to other products; really easily.

Because of the projects / checks architecture we are not just limited to scanning an Oracle database; we can run anything through this architecture and thats what i planned from the beginning. For instance our build system is just a PFCLScan plugin. We have a simple license CRM in Excel (I know!) and we use a simple piece of vba to then run a PFCLScan plugin that builds the installer for each customer with the correct details, EULA, protection, Windows installer and more. Even the installer also uses the scanner to install itself.

I like recursive features and programs!

I will talk more about some of these features and ideas in later blogs in more details as they may be of interest to potential partners in the future; i.e. develop your own projects for other areas that we don't do now; we can partner and resell; embed our software into your product as an OEM; and more. Talk to me if you have any ideas.

So, we were told we sent the wrong product; we didn't. All of our products are actually PFCLScan and individual products are Apps built using and within PFCLScan.

Please email me at pete at petefinnigan dot com or send me a message in Social Media if you have any ideas around partnering using our powerful product stack and architecture.