Managing Information Technology

Week One – Case Study:

Information Security Mistakes

1. Managing IS requires learning the terminology and concepts used within the discipline. What significant new terms and concepts associated with IS and security did you discover in this reading, and how would you explain these items to another MBA student?

Information systems and security professionals have their own language and knowledge base. The reading this week was a mere scratch on the surface of all the related terminology and ideology. Although acronyms are a large part of the technical side of IT, this section will focus mainly on important concepts related to the management of systems and helpful insights into IS decisions. The following information was taken from Ed Adams paper, Biggest Information Security Mistakes that Organizations make.

Application Level Vulnerabilities: 70 to 92% of all security risks are associated with the software applications having a weakness that may be exploited (Adams, p3). Some of these weaknesses are known in other applications and should be preventable:

- Cookie Poisoning: A site plants a small information packet onto the user computer to track information and give better usability. Some features a Cookie provide are remembering usernames and passwords, bringing data from previous page (like a shopping cart remembers how many items as you surf from page to page until you are ready to checkout), and remembering data that is entered repeatedly (your zip code). Poisoning is when users (or someone posing as a user) take that information packet (cookie) and modify it. The modifications may change critical data that can open a hole in security which can be abused (de la Brassinne, p2).

- SQL (Structured Query Language) Injection: Most sites that rely on database information use SQL because it is efficient and has been fairly standardized since 1987 (Wikipedia.com). The problem arises when a user can legitimately enter a query but add additional questions that may not be legit. The information that can be ascertained in some instances can have personal information or other proprietary data like competitor pricing or costs. Additionally injection can be used to manipulate data from the outside by unauthorized users (de la Brassinne, p4).

- Cross Site Scripting: This is when scripts (small programs) are written into HTML to run on user machines that may be able to transmit personal data to a third party (de la Brassinne, p7). These scripts work because Browsers are continually running scripts for improved experience on web pages, thus it is just getting another script to run that will mine data from the user’s hard drive and sending it to a person who can use it maliciously.

Scanners: Firewalls are a type of scanner that look at data being transferred and compare it to a set of rules. If it passes the criteria it is allowed to continue on to its destination, if not it is stopped. The problem with scanners is that creating the rules to watch for all potential attacks is nearly impossible (Adams, p5). Rules, no matter how well structured, leave small gaps that can be manipulated or exploited for ill purpose.

Insider Crimes: Adams mentioned a study by the FBI which states that “over 80% of all computer crime was committed by insiders” (p8). Insiders may be employees, contractors, or partners so it is important to keep security high from all sides.

Cost of Poor Design: During software development it is important to have security part of the initial design constraints. It is easier to spend extra time with the requirements than have to go back after release and make a “patch” for a problem and to try to make one that will not negatively affect the other secure aspects of the product.

2. Based on your own work experience, can you identify first-hand real-world examples of the five mistakes. Discuss at least one and include a solution path for correcting the security problem.

Adams list five IS mistakes that are often made by organizations. Following each mistake is an example that I have experienced.

a. Over-relying on Network Defenses: In the company I work for we have over the last few years been pushing to all easier access to files and information to employees who must travel. The passwords for our company have been very weak (for example all passwords were “5555”…in fact the last workstation was changed only a month ago!) Our IT guy has been hassling us to change and would not set up any external access without increasing password strength. The assumption by most of the users in the company was that the firewall would give them enough protection to avoid the inconvenience of more difficult passwords.

b. Believing the Hype of Technology/Tools: In our engineering department we were evaluating a software add-on to the CAD package we use. It promised to improve efficiency and secure data files to ensure only one user was modifying them at a time. In essence it is a virtual data library with “check-out/check-in” features. It was also to help with revision control. After looking at all the features we discovered that we could change one aspect of the current software in the setup area and would be able to accomplish the same objectives. The “hype” about this new product was oversold and was not worth the $6200 per seat to implement it.

c. Making too Many People Assumptions: Several years ago we had an employee using internal documents to solicit interest in himself and other employees for future job offers. This forced the company to change the security features of the sensitive documents which restricted the access of some of the internal staff. Now we are shifting toward a policy of allowing access to the minimum folders and documents needed.

d. Assuming Secure Software is Costly: Actually the president of my company has made a mistake in the opposite direction. His assumption is that “canned” software was very expensive and that the solution was to create our own software. After several bids for custom applications (none of the requirements dealt with security) we decided to go with a “canned” application that had many security features built into it. We were able to get better security for a lower cost because we were capitalizing on the learning effects of others.

e. Falling into the “Recency” Trap: My company was evaluating moving our network from Novell to Microsoft to get better compatibility. Part of the change was switching email clients from GroupWise to Outlook. About three months earlier one of our customers, who uses Outlook, had a virus attack and it brought their network (and most of their business) down for about three days. For that reason alone, we stayed with GroupWise for another two years. This weekend the IT guys are trying the second attempt at migration; earlier this week they failed to have a successful transition.

3. Investigate further one of the real-world examples provided in the reading and discuss some of the details. [Use the Internet and other sources to find out more about one of the examples. Write about what you find.]

As Engineering Manager for a small design and manufacturing company I have dealt with the project management side of things for several years and have seen the importance of doing the work on the front end to eliminate huge amounts of waste long term. One of the mistakes that companies make according to Adams is that “secure software is costly”. The front end cost may be higher than if security was not a high priority from the start, but mistakes are very costly once a product has been released. “[T]he cost of fixing a defect in development was 1/15th the cost of fixing the same defect if it’s found post-deployment” (Adams, p9). The 1:10:100 rule states that if a problem is found in the early development stage it may cost one hour and $200 to fix, but if the same mistake is found during the testing phase it will cost ten hours and $2000 to fix. However, if the same problem makes it through the release phase and is discovered, fixing it will take one hundred hours and $20,000 (Kemp, p31).

Adams, Ed. Biggest Information Security Mistakes that Organizations Make: and How to Avoid Making Them. Retrieved June 12, 2008 from: http://www.issa.org/Downloads/Whitepapers/Biggest-Information-Security-Mistakes_Security-Innovation.pdf

de la Brassinne, Pierre (2002). Web Application Security for managers. SANS Institute, retrieved June 14, 2008 from: http://www.sans.org/reading_room/whitepapers/application/27.php

Kemp, Sid (2004). Project management demystified. New York: McGraw Hill.

Wikipedia.com. SQL. Retrieved June 12, 2008 from: http://en.wikipedia.org/wiki/SQL