Employees Admit They'd Walk Out With Stolen Data If Fired 380
Gunkerty Jeb writes "In a recent survey of IT managers and executives, nearly half of respondents admitted that if they were fired tomorrow they would walk out with proprietary data such as privileged password lists, company databases, R&D plans and financial reports — even though they know they are not entitled to it. So, it's no surprise that 71 percent believe the insider threat is the priority security concern and poses the most significant business risk. Despite growing awareness of the need to better monitor privileged accounts, only 57 percent say they actively do so. The other 43 percent weren't sure or knew they didn't. And of those that monitored, more than half said they could get around the current controls."
And how much data ACTUALLY walks out? (Score:5, Informative)
Everyone preaches about the insider threat, even though less than 4% of all incidents come from insiders.. If you count by the number of breached records, insiders make up less than 1% of all breached records (though, arguably, they may be breaching records that are more valuable)
http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf [verizonbusiness.com]
Re:how stupid are people? (Score:5, Informative)
What the hell is wrong with the rest of you?
Nothing. We wouldn't either. But our execs and senior management apparently would. Read the summary.
Re:how stupid are people? (Score:5, Informative)
Re:Best Pratices (Score:5, Informative)
This is not a "best practice", as it is completely worthless.
There is a best practice on the opposite side that is capable to defeat your "best practice" on any day of the week and twice during the weekend, and all smart employees have figured it out long ago. It is for the employee to collect the data while they have access, and do not depend on the benevolence of the company policies after the termination decision.
Just so I am not entirely abstract, this is exactly what a certain Bradley Manning allegedly did while in employment of a certain large military organization.
Re:Simple Solution (Score:3, Informative)
It's the low-paid one which are honest
The summary isn't quite accurate. The article states that the survey was mostly IT managers and executives, and the actual report PDF mentions that about 25% were "business/admin/technical staff" (i.e. regular workers), but there is no breakdown as to which group was less honest.
Still, while I'd grant that managers might be more sociopathic, humans in general are quite corrupt. This sort of white-collar unethical behaviour is all too common as, unlike physical violence, it's very indirect as to the effects. This is why so many people cheat on their taxes, pirate software, take stationary etc. etc.
The survey was also done by a company that sells data security products, for what it's worth.
Re:Employer could always be nice (Score:4, Informative)
True, but you'd have to know that it happened. All the company has to do is say: "We're not interested at this time.", not: "We heard about what you did to the server, forget it."
Re:Employer could always be nice (Score:5, Informative)
As for still having access, I wouldn't know. That would require testing for it.
I've never been fired, but I have left jobs where I had access to sensitive information. What I did was write an distribute memo which listed everything I could think of that I needed to be locked out of, then sat down on my last day with the person who was supposed to do it and made sure it happened.
Protection is a two-way street. Not only does it protect my former employer from me, if anything happens after I leave it makes it less likely suspicion will fall on me. Besides that revenge is a juvenile act. It feels better to do the right thing and move on than to gloat over the power you wield over the people you left behind.
Re:Best Pratices (Score:5, Informative)
If I develop code, on my own time, that I reuse at the workplace, whose code is it?
Just my thoughts but, if your contact is not clear, I'd suggest getting this agreed in writing before you use it, particularly if, despite being developed on your own time, it was developed to solve a particular problem at that company. At the very least, make sure it has a licence attached, and use it in compliance with the licensing requirements, as if the company was any other third party recipient of the code — I'd aim to separate your two roles as (a) copyright owner and licensor of the code, and (b) employee of a company making use of third party code — if this means internal policy compliance of getting the licence checked out, the code use validated etc., then put the code through it..
(I'm not a developer, although this is a question I've been asked several times by developers, but I work for my employer four days and week, and spend my fifth day pursuing my own academic interests. There's a clear cross-over, since I'm fortunate to be paid to do something which interests me, and so, in reusing work I've done in my academic life, I try to be as clear as possible what is created in the course of my employment, and what is not... Any other thoughts / suggestions would be very interesting to me!)
Re:Best Pratices (Score:5, Informative)
As a developer, I was very sure to get very clear rules for this in my employment contract.
Any code that I develop in my own time belongs to me. If I choose to use that code in a project at work, the company is given a royalty-free and warranty-free licence to use that code as they see fit. They may not however sub-license it, claim it as their own, or prevent me from using it in any way. All such code must be specifically marked as such, or it is assumed I created it on company time.
My contract does however also specify that I can not compete with my employer while working here, and as such most of the code I do in private has little re-use value at work and vice-versa.
Also, I've been with the same company for 10 years and will likely stay here for the rest of my working life, so I don't actually spend too much time thinking about it - it's just a safety precaution in case something does happen.
Re:Best Pratices (Score:3, Informative)