Don't Skip Defined Test Procedure Before Installing Software


I don't write a lot about application security because, quite frankly, I am more of an infrastructure techie today. However, at one time I was an application coder so I do understand its importance. After all, applications run on our infrastructure so we as infrastructure professionals should understand the security impact and how we can improve it.


What I specifically want to cover in this post is downloaded software and its impact on security. Let's say that the application group contacts the security group because they want to use a new Integrated Development Environment (IDE) to help them be more efficient when they write code. They want to download it and then have the security guys test it from a security perspective. It's brand new to the security group; they've never heard of the software, but the app dev group goes ahead and downloads it into their development environment, unpack it, compile it, and then tells security where it is so they can begin testing it.


I have seen this exact process repeated many times in my career. I see a few best practices being violated here that I want to point out:


  1. The software was not digitally signed. It was put on the network, though the security group was not 100 percent sure where it came from or who created it.
  2. The software was loaded into the development environment. Even though it is not on a production environment, it is still on the network. Even worse, it's on the servers that developers use to create their code.
  3. In this example, no anti-virus scan was done. This should be a given.
  4. Was a change management ticket created?
  5. Finally, what kind of test was even going to be run on the software?


Let's see how to remedy the above situation using a better process.


The application group wants to use a new IDE and contacts the security group to test the security on it. First, security insists that the app group puts in a change management ticket. This lets the entire enterprise know that there will be a change to the environment. Second, since the software was not digitally signed, and security doesn't really know exactly what is being downloaded, the security group insists that the app group contact the vendor and purchase a hard copy on CD/DVD. Next, I do not recommend loading this type of software on the network. I recommend using a sandbox off the network, or on a separate segment, until security understands what it does. Next, I would definitely run a separate anti-virus scan of the software. Even though it comes directly from the vendor, it could still be infected. Finally, the two groups need to communicate and develop a test plan. Security must talk to the application group to understand what the software does and how they plan on using it. It's not difficult: They could use the Internet to try to find a test plan or talk to other security professionals.


Today, it's very easy to download software with the click of a mouse. When IT groups skim over best practices and policies in this regard, in an effort to get things done, that same mouse click can bring a lot of pain and aggravation. Have a plan and use best practices when downloading and testing commercial software.