Summary
This is a recap of an interesting project that got dumped on me, urgently :), to protect Enterprise Database. As usual it was last minute and very very urgent – and actually in this case the urgency was merited. The eventual project was a combination of a Windows Service running on each machine, a Web Service that controlled configuration of Windows Service runtime and a Configuration Admin Application to control what applications are allowed to access Enterprise Database and which application would be shutdown.
Project Origins
I was already working on a project when one of my colleagues and I were asked to join an urgent meeting to discuss security related issues. At the meeting we learned that users were using “unapproved” applications to access Ingres Enterprise Database. I should explain that in this enterprise database security was handled by individual database user accounts – each user account had its appropriate grants to tables and resources. Enterprise had multiple Client/Server applications that allowed users to access enterprise database with their unique database user logins.
Turns out some users, who I guess did not like using enterprise client/server applications, were using tools like MS Access or Visual FoxPro to access and modify the database. The problem with that was the “approved” tools had built-in business level constraints that prevented data corruption. Meanwhile users with MS Access/Visual FoxPro tools would make only partially valid changes which would break various business rules as well as applications trying to access these modified data.
This had to be addressed immediately or more and more of the enterprise data would be corrupted.
This is where my colleague and I come in; we were asked to build a tool to prevent this issue. Main proposal was to build a Windows Service that would run on each domain computer and only allow approved applications to access Ingres Enterprise Databases.
Project Details
Once the project’s high level requirements were outlined it was up to us to determine how to successfully implement it. We decided to each try a different approach, my colleague was going to use C++ to build the windows service, while I, being more comfortable with .NET, decided to use .NET instead. Jumping forward I should say that my approach was better and quicker thanks to .NET memory management and ease of coding.
My approach was to create a Windows Service (codenamed “watchdog”) running in the background which would wake up on predefined interval and get local PC processes. It would then scan each process and see if that process was consuming the DLLs that were required for access to Ingres database. Once a match was found it would compute a hash for the process executable (.EXE file) and see if that process hash was on the allowed list. If YES – then process was left untouched, but if the process hash was unknown then the process would simply be killed.
In trying to future proof the whole design, I also added Web Service components that would expose the Configuration data as XML file (with it’s own XSD Schema). Each local version of the watchdog windows service would get installed with it’s own copy on the config file, however, at a predetermined interval, I think every 6 hours, the service would contact Web Service to get the latest copy of the config file and update the local version. If the Web Service was not available then a local copy of the config file would be used.
Furthermore, the Web Service was used to record any instance of a “bad” application accessing the database and then being killed.
WatchDog Admin Utility
Pretty soon after completing the Windows and Web service code I realized that I needed something that would help me manage the XML configuration file. The file contains a lot of information and any typos could and did result in errors. Also, the whole system was supposed to be managed by the system administrator and not being intimately familiar with the project I was pretty sure they would make mistakes editing config file.
This lead me to create a specific tool – WatchDog Admin utility that would be used to edit configuration file. Tool allows complete control over the config file, including things like selecting allowed executable file and calculating it’s HASH, adding which DLLs are being monitored and controlling how often each application scan will take place.
Project Completion – funny story
Once everything was done and tested then WatchDog windows service was pushed to all enterprise PCs. Immediately Web Service logs started showing multiple instances of people trying to use MS Access and Visual FoxPro to access database. Each attempt was then promptly killed. What happened next was both funny and troubling.
A Manager that was monitoring “kill” logs noticed a pattern – specific user had kill session every 5 minutes. Meaning, each time WatchDog killed his app session he would try again. We think he was hoping to “update the data” before next “kill” command. The manager lowered user’s WatchDog application scan frequency to 3 minutes, then to 1 minutes and ultimately to 30 seconds before this user finally gave up trying to use “custom” tools for database access.
Please let me know if you have any questions or comments.
Sincerely,
Vardan Mkrtchyan
The Developer Guy.