Enterprise Security and Development Teams... Friends or Foes? Part One

Wednesday, October 8, 2008 by Matt Warman

If you have ever worked for a large enterprise, you know that it can be difficult to get the tools you need to get the job done. It is always good to befriend your PC tech, but even he can’t get you unauthorized software. Why is it tough to get the things you need to do your job? There are 3 reasons for your troubles, security, standardization, and team building. Part One of this three part series will discuss Application teams and Security.

Security in the enterprise used to mean older gentlemen near the entrance greeting you and checking your badge. Today, enterprise security is on total lockdown. In the 1990's, the IT department had total control over hardware and software usage. There was, and always will be, bureaucracy and office politics, but application development teams could try out different solutions and suggest alternatives. The alternatives would lead to more Internet based applications. Things changed when the "I love you" virus hit in 2000. Until viruses started to affect businesses, Internet security was nonexistent. After the attack, the knee jerk reaction was to lock down everything. Since the viruses were introduced via the Internet, the heaviest restrictions were on Internet usage and software downloading.
Protecting personal data became an important issue in Congress. Because of initiatives like Sarbanes Oxley (SOX), the types of data on reports and in databases were restricted. Firms now are very wary on report data and the application development teams use to create them. If a SOX violation occurs, your organization gets fined.
The current round of restrictions on new technologies like IM and blogging is put in place for productivity and privacy concerns.

The results of these security policies have hit application development teams the hardest. The pace of change in IT is staggering. Major hardware and software announcements happen weekly. Imagine if GM or Ford created new car models weekly instead of yearly. Their first models released in January would have been the 1956 models (52 years ago). Think about how much cars have changed since 1956. The inability to download and use new software and technologies keeps innovation, productivity, and your business advantage from reaching its full potential. I have even seen some technical blog sites blocked from view. If application development teams can’t get the information they need to innovate, your business runs like its 1956!
I appreciate the reasons why security is in place. There are valid concerns and real issues on the software, hardware, and technology usage. Restrictions should be in place to protect your business and data, but the rules must be implemented intelligently. The security decision makers come from a time before the Internet,  SOX, and blogging. Mainframe developers had a dumb terminal, and even had to print their compile listings. They were keep away from computer. The "security by obscurity" is the only model they know. I believe they see the risks without the seeing the benefits. I also believe it is a matter of trust. Application development teams, especially Internet application development teams are usually your younger members. They grew up on the Internet. It is easier for the old guard to banish the unfamiliar, than to understand the issue and create a smart policy. Just remember, your security restrictions put in place make you safer, but you are also restricting innovation. You also could be driving away your biggest asset; your top talent.

Comments for Enterprise Security and Development Teams... Friends or Foes? Part One

Leave a comment





Captcha