Slashdot Mirror
Security Plans for When Your Senior Developer Leaves?
An anonymous reader asks: "Our CTO, responsible for all hardware and networking setup, who also coincidentally happens to be our senior (and only) developer, has just resigned to go work for the competition. We are not a software company, but he's written proprietary code that we use on a daily basis to work. What interim measures should we be taking to ensure a smooth transition to the next person hired to take over? What can we do about security, since this person designed and implemented all current security procedures? What about ensuring that we have all the intellectual property to which we're entitled? As one co-worker put it: 'His resignation was a surprise to us, but it definitely wasn't a surprise to him.' If he wanted to leave some hard-to-find malicious timed-release back-door-opening code running, it's certainly within his means. We don't expect any malicious action, and can rely on a reasonable level of co-operation and documentation before he goes, but I want to get a sense of what others have done in this situation."
When you hire the person, make them sign something saying that any proprietary code they develop for the company becomes the property of the company. also, insert clauses with penalties for intentional security breaches, etc. it's all a matter of planning. when you hire someone, you want to bring them on, but you should also look at it from the perspective that they can do real damage to your company. you should have them sign something to the effect that they shouldn't do that damage, and if they do, they will be held responsible for any intentional damage. NDA's while not always enforceable if they are unreasonable are a good deterrent as well.
In the heyday of the bubble, jumping ships was a practice that everyone knew about it, and often tried. So, relating from my experience of that...
I think your requirements for a replacement CTO should start with securing the system. Hire consultants until the right guy is found to document what's going on - NOT for more development.
Although I have no info about the politics, your lack of insight into managing your technology is stunningly poor. I hope you pick the best of those consultants and hire them to spread this risk in the future.
Above all this, prepare for your competition to now exploit any weakness you have in your market. No more BusinessAsUsual. If you didn't care about what this guy until he left, perhaps you should re-evaluate what you use your technology for, and take it a bit more seriously.
mug
You say you're not a software company, so obviously the code that he's written isn't your product. Is it utilities, or something that manages your workflow and process? If so, it doesn't seem like you've got that much of a problem. I guess a lot of it depends on what terms he left as -- going to the competition doesn't necessarily imply a bad breakup, but the tone of your posts seems to. Well, anyways...
The easiest source of information is going to be him, himself. It doesn't sound like he's left on the worst terms, and, really, the truth of the matter is he's got all the cards now. If he wanted to screw you over with a malicious time bomb, he could, and there's very little you could do about it. So I would just take what he gives you in terms of documentation and all, and, unless evidence proves otherwise, assume that he's on the up and up. You have little choice, and the other options (like lawyers) are going to make him very uncooperative. Most programmers I know don't get malicious unless they feel that they've been royally screwed over. YMMY.
But, to the future! The best way to avoid exactly this kind of thing is to not have a new guy, but two (or more) new guys. Even if its a senior-level and a junior-level, having someone who can be your backup is invaluable. At worst (depending upon the software), you could get an intern or other low-paid peon to serve as the backup on the cheap. Some of them are clods, but some can be quite smart. Code review reduces not only bugs, but logic bombs and backdoors, and it leaves someone who at least has a clue about the system if one of the two leaves.
As for security: Make sure you have a firewall, and the rules are set to the bare minimum allowed in (but you should have this already, right?) Change the root/administrator passwords. If you have a competent sysadmin, have him monitor for unusual activity...but these are all things that should be going on all the time. In other words, nothing out of the norm.
I was thinking the same thing... something about barn doors, horses, and bolting.
You could've hired me.
First, hire a security team to secure your systems.
Make sure they remove all existing accounts on all systems, and start with new ones, with very secure passwords. This is a good time to require a password rotation policy, and password length & strenght requirements as well.
No non-secure connections to non-public systems from outside the company, period. Or at all, if you can get away with it. No connections from dynamic-IP connections to internal systems, either. (make sure all allowable connections to internal systems are from a list of known IPs)
Make sure PHYSICAL access is secured! Lots of ex-employees keep security cards, keys, etc, and can often get back in after the fact.
Make sure your people know about 'social engineering'!
Don't use inherently-insecure technology from companies who don't give a rat's ass about your security. No bonus points for correctly guessing which company I'm talking about. This becomes stupendously more important if you're the sort of silly-ass company that only has one techie on staff at a time. Lots of updates are to be applied, no matter what platform you go with.
Now's the time to separate systems if you host stuff. Hosting stuff should go in a co-lo facility (since you obviously don't have the staffing resources to handle your own data center), and you should have separate systems for business needs, like e-mail, etc., in case your website gets DOS'd, it won't impact your e-mail, etc.
Have regular security reviews by external security companies. Rotate which company you use each time.
Make sure your insurance covers all your computing infrastructure and eventualities (fire, flood, theft, cracking, etc.).
Make regular backups.
TEST your backups.
Make sure you have off-site backups.
Make sure you have a disaster preparedness plan and the appropriate people know how to implement it. What happens to your business if the building burns down? If the phones go out? If the Net connection goes down? What if there's a major terrorist attack in your city and noone can get to work? Welcome to the real world.
Make sure you have onsite spare parts for your computers, at least for the critical ones.
Make sure noone saves important documents ONLY on their own machine - either make them start saving to shared drives which get backed up daily, or have each machine backed up daily. Say you lose the business plan you're showing to investors tomorrow? What do you do? WHAT DO YOU DO?!
Don't get locked into proprietary file formats, or you may never be able to switch. Plus you may get hit with 'requests' (ie threats) to inventory every piece of software on your site.
Definitely have more than one techie & programmer (2 of each, at least) at your company. That's flat-out ridiculous, as you are probably aware by now.
Okay, that's all I can think of off the top of my head right now. Have a day.
I have been the guy in charge of everything technical, and left to go work for a competitor. (by that I mean in charge of IT, in charge of engineering, for a sick period of time, in charge of the web site, answering to the board, and oh by the way writing mission critical software.)
Where's about what I told them. (I wish I could find the original letter, but I can't.)
Disable all accounts listed on attachment (a). Better yet, monitor activity on them. Look for ones I've forgotten/failed to list. (We had a horribly fragmented pile of crap for authentication/authorization.)
Review all changes I have made or have caused to be made by others on externally facing systems for the last N months, where N is something I obviously cannot recommend. (I was a nazi about change logging.)
Review all executive reports I've made for accuracy.
Randomly interview my employees and fish for things I might have done, might have wanted to do, etc.
Review this list of important things I've done over the last while, and think of how I could go about damaging you with underhanded techniques.
Review your infrastructure. Hire outside people if needed.
Review your trade secrets. Hire outside people if needed.
Note problems with either of the above. Wait for signs that I'm exploiting them.
Think about my tenure here, what I've done, and what I'm legitimately taking to my next workplace. If you believe I've been underhanded, please call me to task. I'd prefer a non-judicial approach first, obviously.
Don't trust me, think of how, in my shoes and with malicious intent, I'd be sneaky. Please assume I'm not doing so (because I'm not), but verify.
***
There was more, some of it company specific, some of it items I've forgotten. My approach was to put myself beyond reproach. I don't do underhanded things. There was concern that I could, and I wanted to explain the tools they could use to convince themselves of that. Of course, I could have done all of that just to try to trick them... I was hoping (and have been proven correct) that my prior track record reinforced faith in me, even when I was moving to a competitor. Sometimes, being a good person makes sense.
I also had some heated sessions with a corporate attorney at my new role over that letter. It came down to, "well, then I already fucked up. Fire me." They didn't.
(Afterseveral years: the two companies have moved in different directions in the same general field, there haven't been any problems between them, and we still trade employees from time to time. And I'm back to having dinner with my former CEO.)
-obviously, anonymous
non-compete clause...
California, where no-competes are unenforceable. Note that you could still get the soon-to-be-ex-CTO with inevitable disclose of company secrets, but you have to go to court for that one.
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.