I looked at a product the other day that is designed for a specific compliance need. It requires a web server and a SQL server. Sounds pretty normal, right? That's pretty much where the "normal" ends.
Files containing user info are sent to the web server via FTP. They are "processed" by the software that is on the web server. All of the processing is done via .bat files. Once the processing is completed the output it sent to the SQL server where is resides and is accessed via the web interface.
What struck me as "odd" about this is the following:
- BATCH FILES!!!! Is this 1986?
- All Processing done on the web server! Why do I have to pay for a SQL server? (of course they recommend a dedicated SQL server) WHY? The SQL server does NOTHING other than serve up the data to the web server when requested. No stored procedures run, nothing. I could use Excel for that.
- This is a compliance product and it stores unencrypted user data on the WEB SERVER. Last time I looked web servers were pretty vulnerable to hacks. And there are NO procedures for removing the data once it was finished being processed (by batch files on the web server). Sorry, that still blows my mind.
- Since it's a "Compliance" product it's not cheap. And they are using batch files.
4 comments:
Hey. Hey. Do you know how much work it would be for them to write an actual compiled program to do the processing? I mean, first, they need to open up an IDE. That's a lot more overhead than notepad! Their systems aren't powerhouses. They aren't made of money.
And besides -- you don't want to speak bad of them, or they might send out MS Paint created BMPs that show you in an embarrassing pose. *nods*
That is just ridiculous. A "compliance" product should not come with its own set of vulnerabilities. Not to mention a shoddy implementation.
Let me guess - a CA product?
I won't say here who it is but I will tell you 2 things. It's not CA (since that was asked) and it's very specific to the financial industry. Think OFAC
Post a Comment