Pair Programming Ina Secure Environment
Pair Programming Ina Secure EnvironmentWe have an issue here with pair programming and the company policy of individual responsibility for network usage. The "management information systems" and "human resources" departments have a very strong desire to be able to monitor and audit every user's individual network activity, for use as evidence in any disciplinary scenario that might occur in future.
They have noticed that our XP developers all log on to the development workstations (which are reserved exclusively for pairing on development tasks) using the same ID. They find this unacceptable. Their preferred solution is for the "driver" to be logged in, and then log out to allow the "navigator" to log in each time the keyboard changes hands. We find this unacceptable, for obvious reasons.
In search of a workable compromise, I'm wondering what other teams do as I can't imagine we are the only ones with this issue. So, stories please (and not speculation :) about your experience of this issue. Thanks. --KeithBraithwaite
[Also posted to the ExtremeProgramming Yahoo group: http://groups.yahoo.com/group/extremeprogramming/message/89121 ]
Would it be feasible to create user ids with the pairs name like JoeTom?, MattGreg?, etc? Then when a pair sits down, they both are logged in as a pair?
This option was discussed, but MIS balked at creating so many IDs (there are 24 developers involved), and they dislike having more than one person know a given password. Has this approach been used in your shop (or was that mere speculation ;)?
Mere speculation - Our shop isn't a secure environment, and I've never been a sysadmin for a secure site. Of course in theory it shouldn't be your job to fix this, it should be their job to figure out how to help you get work done. . . in theory. . . in practice, I wouldn't hold my breath
Secure environment? "Paranoid" sounds better to me.... of course, if you don't like your pair in such a place, just wait 'til he goes to the can then start looking at pr0n while he's logged in...
An AntiPattern, for sure.
Indeed. There was an entire dilbert episode about this kind of approach. Bureaucracy + ParanoidSecurity? = Low productivity + Low Morale.
Pure philosophizing here. It's worth considering the apparent difference in value systems between the employer and the XP team. The security policy is geared towards assigning responsibility to the individual. An XP team is based on collective responsibility. In other words, the security people are saying "we want to single out people", and the team is saying (at least in the context of the development process) "we all accept responsibility". Suppose you were to extend that? What would it mean to say that each individual on the team is responsible for and to the team collectively in the security domain? Lawyers have a term for something that seems related: joint and several liability. It's seen in leases where several individuals sign the lease, but each person is responsible for the rent and any damage to the apartment on the part of any other lessee. Would this sort of collective responsibility work in terms of security and pair programming? How would it be implemented? Some kind of technical solution seems unlikely, but more possible would be an amended employment agreement making each team member responsible for the actions of all the others. That might or might not be possible, it would certainly entail taking courage and trust to another level.
It's what you have to do when you set up in business as a partnership.
When A pairs with B, either A or B logs in as {him,her}self. Any network activity during pairing will be blamed on whichever user logged in; this shouldn't be a problem because they're both at the keyboard at all times, right? If A logs in and later needs to go away briefly, s/he locks the workstation for the duration; if s/he needs to go away for long enough that that's a problem, then the relative cost of logging out is small and s/he can do that.
This might bother the MIS/HR people because A might log in to pair with B, then go away for a while and leave the workstation usable; but equally, A might log in to his/her "own" machine and then let B use it. You can't do anything to prevent that, other than perhaps putting video cameras everywhere. It might bother the developers because they have to put up with some interruption when half of a pair leaves; but arguably they should keep their hands to themselves when their pair isn't looking anyhow :-).
This seems obvious enough that I feel I must be missing something. What am I missing? -- GarethMcCaughan
As I posted on the Yahoo group... http://groups.yahoo.com/group/extremeprogramming/message/89149
If you're really paranoid, then each team member can keep a notepad log of who they've paired with: When Sam pairs with Sue, let's say Sam logs in. Both Sam and Sue write in their notepad "<name-of-the-other-person> <start-time>". When they're done, enter write the end time next to the previous entry. Then should human resource charge in and accuse Sam of reading http://www.c2.com/cgi/wiki?TipsOnUsingVbUnit during work hours, in addition to saying "We're using that tool for VB6 development here; it's very work related." he could also consult his notebook and say, "Sue was working with me at the time, and she'll back me up on the fact that we both found reading that page solved real work related problems." -- JeffGrigg
And how does this company deal with the situation where an IT person comes to your office and asks you to log in so he/she can perform some upgrades or diagnostics? Or are all IT personnel just trusted? That's basically the same as pair programming with respect to this issue, only worse, since often the owner will be at a meeting or at lunch during the IT visit.
That should not happen even in a nominally secure environment the IT person should ask you to logout, then login as themselves if they need to do some task, and log out before you go back on. Modern upgrades and diagnostics are usually done remotely
True, until you have a problem that only shows itself when you log in as the end user.
While I agree the policy is too paranoid, given the situation couldn't you have 2 workstations or laptops, one for each person logged in as themselves, side by side? That would eliminate the probability of finger pointing: "yes, I was logged in but she was the one typing...". With a large shared monitor and kvm switch should almost be the same as using one computer.
To extend this, we can use VNC, PCAnywhere or GotoMyPC, etc. so one person can drive the other's PC :-)
One can physically separate an internal from the external network. In the internal network there are only secure assets and they are supposed to be shared in the shop anyway so no worries.
In the external network we don't have much more than firewall + VPN and we use only encrypted mails. Everything else is insecure anyway so no worries. If you can surf wiki, evil things can surf your computer. It's just a matter of time.
If there needs some additional security we use encrypted storage and no physical network connection.
Put all servers on the private network. You'll have to integrate with outside somehow. When you bring some data out "physically" you can identify who did it and when. Not a big problem. Use guards with the machine guns.
So far about security. Look like you have social problem.
How feasible would it be to physically partition the network such that the development workstations are isolated from the "real" network? Of course the development workstations will need access to the source control system and any testing/integration servers, so presumably they couldn't be physically disconnected from the network. In some of the environments I've worked in the development team was placed on its own network loop. --StevenNewton
Yes. Wouldn't you semi-isolate your test machines anyway, in case a bug in the program did something "insecure" during testing ?
I like the way wiki and XP changes the emphasis from
they dislike having more than one person know a given password.
No problem. (I speculate that) MIS could assign MattGreg? a 10 character password, but only tell Matt the first 5 characters and Greg the last 5 characters.
EditText of this page
(last edited March 2, 2011)
or FindPage with title or text search