A 'BYO' Too Far?

Undoubtedly, most of you will have seen the amazing story about the developer who secretly outsourced his own role to China, investing 20% of his annual salary to free up almost all his work time. The ruse came to light when the firm, who were pushing forward with a more flexible working package, noticed anomalous VPN activity and called in their telecom provider to investigate. The logs indicated that their lead programmer, "Bob," was apparently regularly telecommuting from Shenyang despite being peacefully sat at his desk surfing the Internet for amusing cat videos.

It transpires that "Bob" had FedExed his SecurID token to China and was allowing the remote development company VPN access to his employer's network so that they could do his day job for him.

Irrespective of the terrible security implications here, and they are pretty horrid, "Bob" was delivering high-quality code to schedule.  In fact, his performance review regularly identified him as the best developer they had!  And what "Bob" did here was not difficult – many sites offer the services of dedicated professionals such as developers, designers, proofreaders, even lawyers, for a small price.

In a business environment where we encourage flexible working, allow personal devices, and seek to incentivize workers for innovation, excellence, and performance, "Bob" could be held up as a role model, but at what cost to the enterprise?

How many of us truly enforce the contractual requirements that prohibit sub-contracting for service providers? Do we even include such terms in employee contacts?  As our workforce is being transformed by technology, we need to ensure that our terms of employment, monitoring, and audit systems keep pace, or we will find that virtualization becomes a "people" issue rather than a "technology" one.  

Comments

I agree with your statement

I agree with your statement that, "...Virtualization becomes a "people" issue rather than a "technology" one." Keeping that in mind I think some security implications could be introduced toward the new UPnP risk. I recently read an article that was quite interesting touching on a few similar points mentioned in this article.

http://www.leonard-mcdowell.com/index.php/johns-blog-page/upnp-security-...