Detour, Detour

I don't think many people consciously sit down to create an application or environment thinking, "I'm going to create an insecure and potentially costly-to-remediate system today". I'm also confident that few people intentionally put their company's intellectual property or customer data at risk. That's what I'd prefer to think at least.

It's unfortunate that bad habits permeate the intricacies of technology to a point where I doubt, anyone, can attest to the actual cost of true security remediation. Potential Privileged Account misuse is a situation of "running amuck" that has to be addressed in companies, regardless of size or regulatory requirements. How many privileged accounts should there be in an environment? Should there be one super user account that is used across the enterprise? Who should have access to the privileged account information? How often should it be changed? Should it be more than 8 characters? Should the userid and password be prevented from matching? Should there be a use-on-demand policy with approval at an senior level? Would any of these help?

Let's talk about Detour. I got a call a few years ago from a former colleague who wanted to vent. Detour was the name of a service account so engrained in an environment he worked in that it would, according to the development manager, take thousands of man hours to remediate the millions of line of code Detour had been used in. Why would you want to remediate something like that? I guess I shouldn't have asked that question. The response was that the password was also "detour". Evidently every developer who had worked for the company for the previous ten years knew about Detour, detour. Additionally, it was used across an entire suite of applications for the developer's convenience. There was no supporting documentation; there had been no code review. The account had been set up in Active Directory with instructions that the password should never be changed or it would break multiple revenue generating applications.

The reason for my former colleague's frustration that particular day? An application support guy was troubleshooting an issue and tried to logon as detour, detour. Unfortunately, he kept mistyping detour when he typed in the password. The Active Directory setting for number of mistyped passwords before lock-out? 3. The Application Support guy didn't realize what he had done but monitoring screens in the Ops area turned red with all of the applications that were suddenly down. The development manager who also functioned as the application support manager called screaming bloody murder and threatening someone's job if Ops didn't figure out what was going on and get it corrected ASAP.

While there were a number of issues that needed to be corrected about the above scenario, the aspect that caught my interest the most was that there was a significant single point of failure in a company that appeared to either be undocumented or unrealized. It was obvious I didn't have to start naming the number of issues with the scenario, my former colleague got it.

• Same userid used across multiple environments
  
  • Creating no separation of duty across a suite of products
    
  • Creating a single point of failure
    
• Matching userid and password
  
  • A 5-character password made up of only letters can be hacked in nanoseconds
    
• Development and application roles being shared
  
• Developers, and thereby application support, having access to userid and passwords used in both development and production environments
  
  • Terminated employees had knowledge of this userid and password combination
    

    
     

I'm not a developer so I can't say that the development manager was exaggerating about his estimate of thousands of man hours to remediate the userid and password issue but I am fairly intelligent. I did take a few programming classes in college before I decided I wasn't interested in developing code. I have been an alpha and beta tester for multiple applications so have "some" knowledge of programming. At a minimum, I would like to see a report with the number of times the userid and password appear in the application's code. Then, someone could make an educated decision about the remediation efforts and whether the effort was greater than the potential liability. Perhaps that had already been done in the organization. Perhaps my former colleague was an alarmist who was constantly seeing threats where there were none.

 

A few steps that would help prevent this type from event from occurring in environments would include:

• Service account guidelines including password complexity and lifecycle
  
• Separation of duty between development and production environments
  
• Separation of duty between development and application support roles
  
• Risk documentation and analysis of the potential liability and threat of the perceived threat
  
• Documented SDLC (Software Development Lifecycle)
  
• Peer Reviews
  
• Architectural Reviews prior to a system going into production with sign-off and approval by multiple managers (this should include a risk matrix documenting inherent and residual risks)
  
• Accountability and consequences for non-compliance (REAL consequences and accountability not management turning a blind eye because someone says it'll take a lot of time)
  
  • I know red flags are going up for people here. In certain environments, this could be called whistle blowing. NOT if the facts are presented without an agenda other than securing the environment. If so, "it is what it is".
    
  • There should be assigned roles with responsibilities and timelines with reports to the business and IT executives until such time as the issue has been corrected. This gives the business the opportunity to be aware of the recognized risk.
    
• Privileged Use Monitoring (this can get really pricy so the cost would have to be justified by the potential liability)
  
• Maybe, a discussion with HR about appropriate behavior for managers with a bad temper.
  

  
   

While this company may never suffer a breach due to the lack of security surrounding detour, detour, doesn't it speak to an overall attitude regarding ease of support versus providing secure environments?