Security for Security's Sake

In my first post, I want to discuss what I think are the generic industries approach to security. My experience is that security is kind of like the US Military spending and the budget in three key ways.

1. Everyone knows they need security just like we need a strong military - duh. 
2. Everyone also thinks more security is better, just like more military must be better. 
3. If you try to question security measures of spending, you will be accused of not trying to protect important data, risking hackers, data theft, etc, just like if you question military spending then you aren't a patriot or don't care about soldiers, etc.

In both cases, we avoid having real discussions or analysis on what is appropriate and what is not appropriate because of fears of things that people don't even try to quantify. Failure to properly assess and address security concerns is one of the biggest wastes of time, money, and resources in the IT industry in my opinion. It might be easy to say something like "how is this unique, everyone says security is the biggest issue?". That would be correct, but I have sort of a slightly different take on it. To me, IT leadership has become complacent and too easily just becomes reactive whenever anyone says "security concern". As an industry, we often replace analysis and thoughtful action with reaction and immediate action primarily taken with a CYA motivation. Instead of training and trusting IT leaders to evaluate, manage and make decisions with an understanding of risks, we are training them to throw time and money at problems that in many cases are overblown and poorly understood. This not only wastes time and money that could be better spent elsewhere, but gives a false impression of security and often times ignores other more realistic concerns.

So you might be saying that this all sounds good, but what do you mean / what are some examples. From my own career, here are a couple of the more egregious examples in my opinion:

Example #1: Security for a Content Only Website

While working on a Government contract, I managed the development and deployment of a couple of websites that were really just content aggregation. We allowed users to register their accounts, but just generically register (i.e. no names, addresses, or other identifiable information). At the time, the government had a restriction on the usage of cookies for any sites (very laborious process to get the usage approved), so our only option for this was to have users register and create a user ID and password. We had standard challenge questions to password retrieval and of course a change password function, but since this was all just planning information and customizing the looks of a few pages a user could just as easily create a new profile with just a few clicks.


So what is wrong with this? Well, if it had just stayed like this, then probably nothing. The problem was that since site was published by a government agency, our client mandated that we require users to change their password every 90 days. This basically took the usability of the customizations down to nothing really quickly. A user was basically just setting up a couple of searches and calendar highlights of key dates based on their age and a projected schedule with nothing on the site to identify them in any way (we didn't even allow profile pictures at the time and their email address was never displayed). Think of this like an app for the Army (it wasn't, but the same idea holds) where you have some very generic information out there for potential recruits like:

1. Searching for different MOS's
2. Suggested timeline for joining (i.e. talk to a recruiter in 11th grade, research jobs to discuss with the recruiter, and preparation for basic training suggestions).

• Nothing about this account gives your name
• Nothing about this account is visible to your recruiter, school counselor, or anyone else
• Nothing about this is even verified in any way (the site wouldn't know or care whether this was for John Smith from New York or V Putin from Moscow)

For this site with basically ZERO information about the user, they were required to have a complex password (at the time, something like 12-24 characters that were a combination of upper case, lower case, numbers, and special characters) and change that password every 90 days. The same target users weren't required to ever change their email passwords, facebook or other social media passwords, and at the time most banks didn't even require them to change passwords. All of this was done because some IT decision maker decided it was easiest to apply normal internal network security requirements on all websites rather than take a "risk" on deciding what actually made sense given the data collected and presented on the site to the user and the agency.


The end result (although it's not fair to say completely because of absurd security requirements) was that a potentially useful tool for users basically died within a year rather than being something that could have been built upon. It wasn't the entire reason, but the fact that we could see account usage substantially drop for accounts almost as soon as they hit that password change date. Users were able to make their own decision - the generic content you are providing me isn't worth me having to create a new complex password every 90 days (oh, and not reuse any of the last 20) when I don't even have to do that for my other on-line accounts.

The only benefit to the agency (in my humble opinion at least) was that no one ever had to take responsibility and say "I reviewed the site, functionality, and data available, and based on the risks presented determined that this site did not require the same security set-up as other sites we have built. What we implemented was designed to be appropriate for the usage.".

Example #2: Account Expirations

With the same contract, we build a site that was a general reporting application for the agencies customers. The site did have more sensitive data that was collected and a true business function, so all the account requirements were mentioned above and were enterprise standards did make sense. No arguments there, since you can debate certain merits of enterprise standards, but whatever an enterprise decides on for their business function applications should be adhered to. So what was the issue? Well, this was a bit more complicated and specific. The particular application was an annual reporting application with basically 2-3 uses for most users. It's not that the application wasn't available other times, but that there was really no purpose for users to use it. Rather than understand the usage of the application and adjust requirements based on the business use (it was the business after all that decided this was important enough to build), the IT security team took a hard stand that accounts not used within 90 days had to be disabled and deleted if not used within 180 days. In the pre-single-sign-on days for this agency, this basically meant that probably 70+% of the users had their accounts deleted and had to register for a new account the next year. We couldn't even give them the same user name because of other restrictions at the time, so you might have a single user using the application 3 years in a row with user names JSmith, JSmith1, and JSmith2. 

We proposed simple solutions to this that would have solved this, such as having an administrator at their organization (which we already had identified) validated that the user still needed the account and keep it active or keeping the account active so the user could login, but restrict access to detailed data until the administrator confirmed their accounts. Both options were rejected because that would be "different" than how other accounts are handled and would require special approval.

So What Causes many of these Problems?

In my view, the causes of these types of problems often is one of the following:

1. Lack of understanding of "risks" and impacts
2. Adherence to policy, regardless of whether it makes sense or not
3. Security "Experts" who aren't really experts and mostly just try to exert power by saying no or having teams jump through hoops for simple requests
4. Managers and leadership just being afraid of being blamed for anything and taking the easy way out - basically lazy leadership teams that don't want to listen or trust their teams

In follow-on posts, I will try to outline how I think an organization would be best off handling these issues and implementing security in their IT department.