Security problem - some ideas sought
Hello All, Here's an interesting scenario for you security buffs out there - I've been approached to think about the issues and return with some verdicts and would appreciate some intelligent ideas I'm sure you can conjure up... Company A has its software installed on lots of customer Windows machines around the world. The software has effectively got 'root' access on the machine, and talks regularly to a central server to gain upgrades etc. If the software is tampered with, the computers could well cause disruption. [ Yes, really bad idea. Microsoft should indeed be shot for allowing it. ] The upgrades can be 'pushed' out at will to a subset of customers, or to all. The software, having full Administrator access, needs to be careful. Or, more to the point, the procedure for releasing upgrades and changes to the software needs to be highly secure. One idea that was my initial on the subject is as follows: Six 'trusted' employees, six 'secure' servers. Employees are minor shareholders in the company. For an upgrade to be pushed out, a majority of the trusted employees must submit the same upgrade package to a majority of the servers, and the servers between them must agree that the upgrade is verified as coming from the claimed sources. Combined, they should check out. If any one employee, or one machine, were to raise a black flag, the process is aborted. In the event that a bad upgrade is indeed rolled out any two employees can activate a rollback procedure (which I can't think of procedurally right now). Normally I would of course be thinking in terms of specialised identity and verificaton equipment, but Company A doesn't exactly have the resources of the CIA or NSA, so remote servers and a chain of trust is the closest they can get. PGP keys all round I suspect. A nightmare to secure, and is still open to attack, both internally and externally, however thats how I see it. I warn that I got almost three hours sleep last night due to "server issues" so if I make no sense thats probably why. Comments/suggestions on completely different ideas/etc most welcomed. I don't have experience in this field. Thanks all, James
On Tue, Jan 06, 2004 at 09:09:47PM +0000, James Green wrote:
[ Yes, really bad idea. Microsoft should indeed be shot for allowing it. ]
TBH I don't see how this is MS fault. (wow, I am defending the evil!!)
software needs to be highly secure.
Six 'trusted' employees, six 'secure' servers. Employees are minor shareholders in the company. For an upgrade to be pushed out, a majority of
PGP keys all round I suspect.
OK, right, the software needs to be secure, that means it must come through one point, unless those trusted employees are security aware they are useless. Are they able to read code? have they had a hand in the development? PGP signing (well GPG) seems mandatory. Updates should come from the head of the IT dept, or whoever is given large amounts of dosh to put their head on the line. It seems you are being a bit to specific to me wihtout giving enough detail, now I am currently looking for work, if you want to pay me some amount of dosh I would be prepared to do a proper risk assessment ;) but to be brutaly honest right now it sounds as though you need someone who knows what you want advising you. Adam -- jabberid = quinophex@jabber.earth.li AFFS || http://www.affs.org.uk/ || Not a filesystem
On Tuesday 06 January 2004 22:45, adam@thebowery.co.uk wrote:
Updates should come from the head of the IT dept, or whoever is given large amounts of dosh to put their head on the line.
I'm with Adam on this one, you give six people the responsibility of "voting" the release and you'll get the 5 lazyest ones clicking on the "yes button" hoping to god that the 6th does a good job of checking the update. Then when it goes wrong who's accountable ? Also peer/team pressure will come into it, who would want to be the guy whos vote clogged up the update and caused a deadline to be missed/ project delayed/customers angered whatever. only to come in the next day and find out that the fault he thought he saw was his error ? How about something like this- Assuming there is some sort of QA procedure/team, they sign off the final build and at the point of sign off they package the files (assuming the update is more than one file) as a tar archive or something, and create an MD5 sum The archive is transfered to the update mechanism by whatever means and the MD5 sum is presented to the head of IT (or whoever we are going to make responsible) during a process where the QA personell or team head confirm that the packaged build is "ready for launch" The head of IT then makes the final decision, checks the package against the MD5 sum, assuming a match untars it and launches the update process. Scenarios If the build or source tree is tampered with, hopefully the QA team will pick up on it. If the build is tampered with between the QA sign-off and the update mechanism, then the sums won't match You could even perhaps have a well protected script that uses the Md5 sum as part of a launch key/password. So the update can't be initiated until the correct Md5 sum is presented by the head. Ok it's getting late so I am not sure this makes sense................ Replace Md5 sums with encryption if you want.
James Green <jg@jmkg.net> writes:
Six 'trusted' employees, six 'secure' servers. Employees are minor shareholders in the company. For an upgrade to be pushed out, a majority of the trusted employees must submit the same upgrade package to a majority of the servers, and the servers between them must agree that the upgrade is verified as coming from the claimed sources. Combined, they should check out. If any one employee, or one machine, were to raise a black flag, the process is aborted. In the event that a bad upgrade is indeed rolled out any two employees can activate a rollback procedure (which I can't think of procedurally right now).
Have you considered doing the verification end-to-end, i.e. the clients have a public key on them and verify the image with that? Then the important things becomes protecting the private half of the key rather than maintaining and protecting multiple trusted servers. (How currently do the clients tell that the upgrade comes from the right place? I hope they're not relying on IP address or hostname over the internet!) -- http://www.greenend.org.uk/rjk/
participants (4)
-
adam＠thebowery.co.uk -
James Green -
Richard Kettlewell -
Wayne Stallwood