I'm a system engineer and i've worked in some highly secured environments for banks. I've seen my share of badly secured software, not to mention badly written software in general. Sometimes, the problems are in the design. Then the problem is not in the code, so whatever the developpers did after the design was made is irrelevant. Sometimes it's just lazyness of the developper. Why going though the trouble of finding a secure way to handle passwords if you can use them in plain text. But sometimes, the problem is introduced right at the end, while writing the installation manual. The last one is just sad!
Recently I was asked to install an application that gathers all configuration information from every server, database, ... and sends it to a centralized server. That server would use the information gathered to do consistency checks. Great product and it would save us a lot of problems in the long run. The communication between agents and master will be encrypted using SSL. Great, right?
The installation procedure stated that the private key of the server had to be copied on every agent (about 1000 servers). I don't understand this way of thinking. Why is it called "private" if you copy it to every server? In this case, if 1 agent gets compromised, that agent can impersonate itself as the master and gather the info from all the serverpark, being a big security risk.
Ok, I do understand that you decide not to create 1000 private keys... But maybe you can make 2? 1 for the master and 1 for every agent. This way, if 1 agent gets compromised, only bogus info can be sent to the master, no info can be stolen... Off course, we deviated from the installation manual to fix this issue...
Why is it so hard to ask an experienced system/security engineer to review the software before distributing it to customers?
No comments:
Post a Comment