Neo-legacy applications
A friend of mine wrote in about a problem he has. He provides support to small businesses, one of which is in the financial industry. The problem is this, they make use of an application, which runs in a client server model. The 'server' shares out a folder for the clients to access, as well as a share on all of the workstations. The software requires that all NTFS and share permissions be set to 'Everyone - full control'. Sounds like a recipe for disaster to my friend, and I concur. This certainly violates the Principle of least privilege (POLP). In this case the client should be advised of the risk, as well as the software vendor. It also makes me wonder what other security best practices and secure programming principles were disregarded by the software vendor, and why they chose to do so? In this case the software is not legacy, it is current and supported by the vendor. The data within the application is considered highly confidential by the company, and the risk to the organization is high should it be lost, modified, or disclosed. If my friend chooses to disregard the vendor recommended configuration the software may not work properly, if at all, and may void vendor support or warranty.
Rob, a fellow ISC handler also points out the following issues he has also come across:
Applications that require users to be in the local admins group on the local workstation.
Applications that require users to have full rights on the app server.
Applications that require full rights in databases.
Applications that log every user into the application, the log them all into the SQL database using a single account - usually "sa" (or equiv on oracle or mysql, but by far most prevalent on sql).
Oddly enough, where i personally see this the most is in financial apps - apps that run payroll, GL, order entry and warehouse management. Also in support apps for banking clients if you can believe that !
So question #1 is - where have these appdev people been the last 10 years? Is it just the same appdev people from 10 years ago, who haven't been thinking about security? Is it new appdev people, who haven't seen security training? Is it management in the application company who've decided not to develop the app with a secure access model? Is it all 3?
Question #2 is - why aren't auditors reporting things like this as audit findings? - I report this stuff, but it's always news to the client, even if they've had someone else auditing them in the past, this stuff never makes the audit. Is this because there are too many "follow the script" auditors out there, and this just isn't on the script because maybe it's hard to describe?
Once you figure out you have a problem, what option do you have, other than finding a new business system with a better model? You can't go change permissions on your own, even if it's the right thing to do, because the vendor will throw up their hands on the support side, and blame every problem you call them with on the permissions changes. You can't change hard-coded db passwords without source code in most cases.
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
Comments
Jim
Jan 29th 2010
1 decade ago
Chad
Jan 29th 2010
1 decade ago
Steve
Jan 29th 2010
1 decade ago
Really makes one feel good about the amount of cash we shovel out the door for this stuff.
Drew
Jan 29th 2010
1 decade ago
mquibell
Jan 29th 2010
1 decade ago
I don't know how companies like this survive. Luck?
Steven Chamberlain
Jan 29th 2010
1 decade ago
Jack Russell
Jan 29th 2010
1 decade ago
Current place is getting better, however it took the impending PCI requirements to get any traction for security.
In many industries marketing drives development. Marketing wants features they can sell, security (so far) isn't really very marketable.
Just my 2 cents on that.
bkwalker
Jan 29th 2010
1 decade ago
Frank
Jan 29th 2010
1 decade ago
I find it hard to believe that anyone can be held accountable for something that the software vendor has implemented, and an auditor has accepted as safe. On the other hand, failure to update software, patch operating systems, tighten login credentials, limit IP access and the like is clear idiocy!
I know... the forms said "had to do it". The program is needed and we have to use it. Well.. not true! There are options always!
Chances are you can still be hacked, but at least it will take a master, not a script you can download for free to do it.
Those 10 year software engineers should know better, but most learn in the Windows world, where point and click is the easiest thing to do. Buying up parts of your package and integrating them is the biggest no-no out there, but it happens every day. Especially in Health Care, Banking and Government applications. No one knows what these things were written in half the time and no one can support them. After all... the company you bought doesn't exist anymore and the engineers are gone. S.O.L.
Sad... very sad that security is non-existent except at the border gateway. Even there.. not much.. not much at all!
-Al
Al Thiel
Jan 29th 2010
1 decade ago