Perimeter
6/12/2012
06:45 PM
50%
50%

Don't Blame Me, I'm Just An Employee

If you're looking for a cure for mishandling of sensitive data, then look no further than your own management team

Five years ago I remember contemplating some future day when the general workforce would come to understand the importance of securing sensitive data, taking a personal interest -- and even making a personal effort -- in support of that goal. Fast-forward to last week. While reviewing the findings of a customer's data risk assessment, I came to a personal realization: The workforce will never learn.

Not surprisingly, the results of this risk assessment were similar to the dozens before it. Despite the fact that the findings supported the need for my company's products and services, I found myself strangely deflated and disappointed. But there was also another feeling welling up inside me that I couldn't immediately identify. It was something unusual for the situation, a deeper, rawer emotion. Anger. I was officially mad.

I'd been through this process more than 100 times and had never been angry. Yet here I was sitting in front of my customer, seething inside. I couldn't let the anger show, of course, so I shouted in my mind, "Have end users learned nothing in the past five years?" We found incidents of users still sending spreadsheets with personally identifiable information, such as names and Social Security, credit card, and account numbers, to personal email accounts. Customer service reps were still replying to customer email messages in cleartext, leaving credit card numbers, expiration dates, and card security codes in place. Network and workstation drives were still chock-full of interesting and scary sensitive data saved by unwitting end users. And FTP jobs thought to be secure were still transmitting sensitive data in the clear.

As we reviewed the individual incidents and saw the usernames ascribed to each occurrence of data misuse -- billyjones, sallylu, etc. -- my anger toward the end users began to wane. Knowing this particular customer as I do, and the general lack of executive management support for data protection, suddenly it was management I found in my crosshair. A torrent of memories of working with this customer came flooding to my mind. New roadblocks seemed to appear anytime we identified an area of needed improvement. Always willing to talk a good talk, but seldom willing to put their money where their mouths were, my anger and frustration shifted entirely to the management team.

Don't get me wrong; end users must still do their part. In fact, there's a growing awareness for data security among the workforce that will certainly continue to improve. However, as much as we may wish, data security is simply not the mindset of the average end user. The breach news, if they even hear it, doesn't mean anything to them. Whether we like it or not, their focus is on completing their primary job duties, right where it should be. The ultimate responsibility for data security still rests with management.

Management must accept that responsibility and force a shift in corporate consciousness toward data security. This shift begins with attention at the executive level and filters down through the organization by means of those inconvenient data security tasks that are all too often left undone: organized training, internal awareness initiatives, and reinforcement with enforcement technologies. Until management takes action to increase awareness among its workforce, it is difficult to expect a higher level of end user care for sensitive data.

Jared Thorkelson is founder and president of DLP Experts, a vendor-agnostic VAR and consulting practice focused exclusively on data protection. He can be reached at jthork@dlpexperts.com. Jared is president of DLP Experts, a value-added reseller dedicated exclusively to data loss prevention (DLP) and other data protection technologies and services. For over twenty years Jared has held executive level positions with technology firms, with the last six years ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
senthilkumar@techweb.com
50%
50%
senthilkumar@techweb.com,
User Rank: Apprentice
8/16/2012 | 12:47:48 PM
re: Don't Blame Me, I'm Just An Employee
Excellent Article
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?