Balancing Between Service and Security
Build Security and Privacy Protection into Your Help Desk
Threat of Socially Engineered Attacks
One thing is clear, successful help desks need to be highly focused on customer service, yet they can present a security risk for the same reason they are in business, helping a user, explains Barb Filkins, SANS analyst and author of a report based on its recent survey. The only real way to solve the problem is to build security into the business of help desk from user friendly but secure self service tools to training agents on ways to detect or prevent socially engineered attacks.
Nearly all organizations have a help desk regardless of industry type and size. In the survey, respondents cut across various industries, including government 18 percent, finance 15 percent and education 13 percent; healthcare, high tech and telecommunications were also well represented. Survey takers also represented a balance in terms of size of organization, with almost 20 percent supporting more than 25,000 users and 18 percent supporting 250 or fewer users.
The enterprise help desk is most often where a user turns to resolve a problem with all matters IT, access, endpoints and service, but for decades, the help desk has offered a back door to enterprise network resources through social engineering.
The good news is that awareness of and training for such attacks exists. In this SANS survey on help desk security and privacy, more than 70 percent of respondents reported that they are aware of social engineering, and some are even training their help desk staff to be suspicious. The bad news is that organizations are not factoring security into the overall help desk budget; security technologies are underutilized, and nearly 40 percent have weak or no security policy around their help desks.
Self service tools are viewed as a way to control costs associated with providing help desk services with live, but more expensive, human attendants, says Filkins. But the success of automation depends on its usability. On-line tools can be so convoluted and difficult that an end user punches 0 to reach the human on the other end, to be led by the hand through use. Of course, all savings are lost when this happens.
Do the needs of the business trump the risks imposed by password reset and other self-service provisioning? Is an agent too rushed by resolution time limits to validate a caller authenticity and successfully distinguish real users from social engineers? Can self-service and authentication be used to avoid these security risks and provide a more secure environment for those deploying such technologies?