Endpoint //

Privacy

10/16/2018
11:20 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
100%
0%

6 Reasons Why Employees Violate Security Policies

Get into their heads to find out why they're flouting your corporate cybersecurity rules.
Previous
1 of 7
Next

Image Source: Adobe Stock (Michail Petrov)

Image Source: Adobe Stock (Michail Petrov)

Most of the time, employees break cybersecurity rules because they're trying to get their jobs done. CISOs and other security policymakers seeking better buy-in and compliance with their security policies would do well to remember that. So what exactly behind their behavior? To help improve strategies around adherence to security policies, we put together a list of six of the most common drivers for rule-breakers.

 

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Previous
1 of 7
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
10/31/2018 | 11:23:03 PM
Re: Believe it or not
Look, let's set apologism aside and get right to the point.

Security and accessibility are mortal foes. This is not a denigration of either interest in favor of the other. It is axiomatic. 100% security necessarily means 0% accessibility (because the thing is so secure that NO ONE can EVER access it NO MATTER WHAT). 0% security necessarily means 100% accessibility (because the thing is so universally accessible as to have eliminated all conceivable barriers -- security and otherwise).

Let the devs focus on features and accessibility (like they already do), and let the security people focus on security. And have someone in charge, product-wise, to balance the interests based on a risk assessment. It is not -- and should not be -- security's job to balance the interests because the security team is naturally biased. Likewise for the feature creeps.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
10/31/2018 | 12:00:48 AM
Re: Believe it or not
You wouldn't believe what I've seen (or maybe you would) in terms of employees essentially committing out-and-out fraud just to get around their company's security and compliance requirements.
3Dmerchant
0%
100%
3Dmerchant,
User Rank: Guru
10/26/2018 | 8:29:17 AM
Re: Believe it or not
To "get their job done" is right on point. I talk to people every day doing things against company policy, like using paper credit card authorization forms that have been forbidden. But these same people are held accountable when the company gets burned on a fraudulent transaction. If management doesn't provide a solution to help them comply with policy while protecting them from blow back on fraud losses, their going to find another way to get it done.
silyrics@hotmail.com
50%
50%
[email protected],
User Rank: Apprentice
10/24/2018 | 4:03:24 PM
Re: Believe it or not
With regard to this comment I would like to add the following: The Security world does not seek to restrict the user, in fact the security world has a very responsible balancing act to achieve. We are advised that a layered security archiecture is a requirement and at least one of those layers involves the uers. If users were comletely safe in all they say and do, there would be no requirement for many of the restritions imposed. Unfortunatel my experience shows the users to be the most valuable asset and the most vulnerable segment of the system picture.

If we look at protecting the system today to ensure there is a system tomorrow, many of the users inconvieniences become quite small in relation. The user opens the pandoras box at logon, i would hope the systems employed are close to transparent from there on....if not then the company may have created a budget environment, sometimes this can lead to not only overly clunky security requirements but also the creation of holes inthe security capability.

Please do not be disapointed when you cannot automatically access files, it is quite possible you are not aware of the security brief from above your head..

 
wmw
67%
33%
wmw,
User Rank: Apprentice
10/19/2018 | 1:21:58 AM
Believe it or not
The most important and missing reason is, that IT does not focus on the user. IT has the duty to support the user, not to restrict the user. In an agile world, it's also outdated to restrict the user to access only for day-to-day work. This might work in a taylorism company, but not in modern beta codex based companies. IT should be the consultant of the users, to not inhibit the work flow of innovative technologies while maintaining necessary security and mitigating risks. To be honest, there is no such thing as 100% security. IT has'n realized that its work is complexity and this is not be done by standardized processes.
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Symantec Intros USB Scanning Tool for ICS Operators
Jai Vijayan, Freelance writer,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10008
PUBLISHED: 2018-12-10
A code execution vulnerability exists in the Stapler web framework used by Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in stapler/core/src/main/java/org/kohsuke/stapler/MetaClass.java that allows attackers to invoke some methods on Java objects by accessing crafted URLs that were not intended...
CVE-2018-10008
PUBLISHED: 2018-12-10
An information exposure vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in DirectoryBrowserSupport.java that allows attackers with the ability to control build output to browse the file system on agents running builds beyond the duration of the build using the workspace br...
CVE-2018-10008
PUBLISHED: 2018-12-10
A data modification vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in User.java, IdStrategy.java that allows attackers to submit crafted user names that can cause an improper migration of user record storage formats, potentially preventing the victim from logging into Jen...
CVE-2018-10008
PUBLISHED: 2018-12-10
A denial of service vulnerability exists in Jenkins 2.153 and earlier, LTS 2.138.3 and earlier in CronTab.java that allows attackers with Overall/Read permission to have a request handling thread enter an infinite loop.
CVE-2018-10008
PUBLISHED: 2018-12-10
A sandbox bypass vulnerability exists in Script Security Plugin 1.47 and earlier in groovy-sandbox/src/main/java/org/kohsuke/groovy/sandbox/SandboxTransformer.java that allows attackers with Job/Configure permission to execute arbitrary code on the Jenkins master JVM, if plugins using the Groovy san...