Research

How do we know our code is bug free? What makes us believe that our application is always going to work? Ultimately, we don’t. We test as best we can. Software vendors spend a significant percentage of their development budget on Quality Assurance. Over the years we have gotten better at it. We test more, we test earlier, and we test at module, component, and system levels. We write scripts, we buy tools, we help mentor our peers on better approaches. We do white box testing, we do black box testing. We have developers write some tests. We have QA write and run tests. We have 3rd party testing assistance. We perform auto-builds and automated tests. We may even have partners, beta customers, and resellers test so that our code is as high quality as possible. We have learned that the earlier in the process we find issues, the less money we spend fixing them (see Deming, Kaizen, Six Sigma, etc.). We have even altered the basic development processes from waterfall to things like extreme and agile methodologies to better assist with quality efforts. We have taken better advantage of object oriented programming to reuse trusted code, as well as distill and simplify code to ease maintenance issues. This did not happen overnight, but has been a gradual process every year I have been part of the industry. We continually strive to get a little better every release, and we have generally gotten better, and done so with fewer resources. None of these strategies were typical 20 years ago when developers were still testing their own code. We have come a very long way. So what, you say? I say software security is no different. We are on the cusp of several large changes in the security industry and this is one of them. Security will come to the “common man” programmer. I was discussing this with Andre Gironda from ts/sci at the SunSec gathering a couple of weeks ago, and how process has positively affected quality as well as how it is starting to positively affect security, along with some of the challenges in setting up suitable security test cases at the component and module levels. Andre put up a nice post on “What Web Application Security Really Is” the other day and he touches on several of these points. Better security needs to come from wholesale and systemic changes. Hackers spend most of their time thinking about how to abuse systems, and your programming team should too. Do we do this well today? Obviously the answer is ‘no’. Will we get better in 10 years, or even 2 years from now? I am certain we will. Mapping security issues into the QA processes, as a sub-component of quality if you will, would certainly help. The infrastructure and process is already present in the development organization to account for it. The set of reports and statistics that we gather to ‘measure’ software quality would be similar in type to those for security … meaning they would both suck, but we’ll use them anyway because we do not have anything better. We are seriously shy on education and training. It has taken a long time for security problems, security education, and security awareness to even percolate into the developer community at large. This has been getting a lot of attention in the last couple of years with the mind-boggling number of data breaches that have been going on, and the huge amount of buzz lately with security practitioners with PCI 6.6 requiring code reviews. There is a spotlight on the problem and the net result will be a slow trend toward considering security in the software design and implementation phases. It will work its way into the process, the tools, the educational programs, and the minds of typical programmers. Not overnight. Like with quality in general, in slow evolutionary steps. Share:

This is a very scary thing. I wrote a blog post last year about this type of thing in response to Rich’s post on lax wireless security. I was trying to think up scenarios where this would be a problem, and the best example I thought of is what I am going to call the “Pink Slip Virus 2008”. Consider a virus that does the following: Once installed, the code would periodically download pornography onto the computer, encrypt it, and then store it on the disk. Not too much, and not too often, just a few pictures or small videos. After several weeks of doing this, it would un-encrypt the data, move it to “My Documents” or some subdirectory, and then uninstall itself. It could be programmed to remove signs that it was present, such as scrubbing log files to further hide from detection. The computer could be infected randomly through a hostile web site or it could be targeted through an injection attack via some insecure service. It could even be targeted by a co-worker who installed this on your machine when you were at lunch, or loaned you an infected memory stick. A virus of this type could be subtle, and use so minimal CPU, network, and disk resources so as to go unnoticed both by the owner of the computer and the IT department. Now what you have is presumed guilt. If the downloads are discovered by IT, or someone like the malicious co-worker were to proactively mention to HR “I saw something that looked like …” on or after the date the virus uninstalled itself, a subsequent search would reveal pornography on the machine. Odds are the employee would be fired. It would be tough to convince anyone that it was anything other than the employee doing what they should not have been doing, and “innocent until proven guilty” is a legal doctrine that is not applied to corporate hiring/firing decisions. I was discussing this scenario with our former Director of Marketing at IPLocks, Tom Yates, and he raised a good point. We routinely use Occam’s Razor in our reasoning. This principle states that the simplest explanation is usually the correct one. And the simple explanation would be that you were performing unauthorized browsing with your computer, which could have negative legal consequences for the company, and is almost always a ‘fire-able’ offense. How could you prove otherwise? Who is going to bring in a forensic specialist to prove you are innocent? How could you account for the files? I have had a home computer infected with a BitTorrent-like virus storing such files on a home computer in 2003, so I know the virus part is quite feasible. I know that remote sessions can be used to instigate activity from a specific machine as well. It is a problem to assume the person and the computer are one and the same. We often assume that you are responsible for specific activity because it was your IP address, or your MAC address, or your account, or your computer that was involved. Your computer is not always under your control, passwords are usually easy to guess, and so it is a dangerous assumption that the official user is responsible for all activity on a computer. Almost every piece of software I have ever downloaded onto my machine takes some action without my consent. So how would you prove it was some guy looking at porn and not spammers, hackers and/or the malicious co-worker? Share: