Security Vs. User Convenience
5 min read
I would call myself a veteran of IT security. Working in the area of security, primarily around server level and web applications, for well over 12 years. Started out as a programmer working with Cold Fusion 3 and Visual Basic 5 and moving up to the latest and greatest tool sets. I have moved out of the development work into more of an architect, design, and administration role for Enterprise level Identity and Access Management systems and have been doing that for the last 7 years or so. I have been around the block when it comes to designing and implementing security and have been on both side of the equations.
In my past locations where I have provided security services, there was a distinct line between security policy designers and application developers. However, recently, I have seen a few places where this separation does not exist and the application developers are dictating security policies under the argument of as limited user inconvenience as possible. This is a problem. First, it’s the same reason why you never have a programmer test their own code, programmer’s shouldn’t build their own security either. Second, programmers are inherently not security experts. Thirdly, application development managers are so far removed from IT reality, their decisions on what the apps do are based on their contacts with users and what they want and complain about not what’s in the best interest of the Enterprise security. The exact same methodology and arguments can be applied to server engineers, network engineers, HR, and so on. They are good at what they do, so are your security people.
Security policies drive behavior, not the other way around.
In this scenario, the security groups live in a world of exceptions. Creating toothless standards and requirements because they are not forced to be conformed to by the app/server teams and with the right email from a disconnected manager with a voice, exceptions are made all over the place. You grow to a point where security is sacrificed for user convenience.
Here are some of the whoppers I heard proposed from application development teams.
– In a federation configuration, users come into the portal and federate over to the 3rd party. The authentication system has had past problems with stability to poorly managed database and SAN components outside of the security system’s control. The solution proposed was as such… create a backdoor to the 3rd party to the 3rd party system so users could bypass in the case of an outage. Ok, maybe… BUT WAIT!!! Federated apps, user’s don’t know their credentials at the 3rd party sites (Single Sign On)… so it was proposed to send a flat file of all our user’s passwords to the 3rd party so users could login with the same user ID and password and not be others with remembering multiple passwords if the SSO system has a hiccup. – Hand to God, this was a proposed option, just give all our passwords to a non-Enterprise entity, a 3rd party… here you go…we trust you.
– Require Multi Factor but not be bothered with personal questions.
– Use your personal questions for Service Desk validation when you call… so the Service Desk agent can turn around and reset your accounts without your knowledge.
– Sessions that never expire or expire in days instead of hours. Reduce the annoyance of logins by maximizing the session life…
– Remove unncessary barriers. (The proposal says unnecessary) What are those unnecessary barriers being referred to? Special characters in passwords, password complexity rules, and secret questions.
– My favorite – The comment “If the admins want to take the data they will. Don’t bog them down with extra steps.”
Those are some of the more far out ones yet all legitimately proposed by management that made it into a considered project (some were actually deployed). Created and delivered with zero input from any one with a security responsibility. All under the guise of making applications and servers as accessible as possible and the teams to whine the least.
I fully, 100% agree with usability. Who doesn’t? I designed web applications for 5 years, I know all about making things as easy as possible… under the structure of strong security functionality however. Those suggestions are created and thought of only in the eyes of making the user’s happy and not thinking about, because they don’t know how, the Enterprise Security as whole and the serious problems that could arise from those being exposed. Like all security it comes down to assuming risk. The possibility of something happening and the damage from that. Assuming risk that exists through design and artificially creating risk through laziness are two different things…. and one will stand up in a court of law stronger than the other.
This is the Internet age. Users expect there to be security. I will bet $1,000 if properly explained why applications behave the way they do, with certain ‘inconveniences’ in place, are all for the company’s and the client’s/customer’s security of their data… not ONE person would complain and say remove it because it makes my job 250ms longer and wears my mouse down because it’s an extra click. Not one. Users want easy to use applications, but they also want to know that who they do business with has their protection in the front of their mind instead of their usability and making their admins lazier. They will understand. They will change their behavior to conform to the security policies.
Application development teams, server admins, network engineers should conform to security policies that are built for the best interest of the business’ integrity first and usability second. User’s will understand and appreciate certain steps taken to protect their data, money, photos, documents, etc… There is a line however if the site is so complex to use it’s a burden, but applications are so far from that today it’s a non issue. Going the reverse however, making it too easy by sacrificing security and data integrity, will only put you at a greater risk of being front page news.
In IT and the fluidity on how easy it is to move services from one company to another, perception is reality. It only takes one event to show how stupid some security decision or lack of decision were.
End of Line.
Binary Blogger
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.
Subscribe
Facebook Page
Follow Me On Twitter
contactme@binaryblogger.com
