The Blog on Cyberterror is now up. This blog is made by the same person who runs the War on Cyberterror Web site, an informational site which attempts to pool together information related to security and security efforts.
The purpose of the Blog on Cyberterror is to give me a place to vent and talk about things going on. This is a very informal setting; I may get into observations that I have little grasp on about efforts not very broadly displayed, and may make errors about the magnitude of such efforts. Still, I try to be right all the time. :)
I may blog multiple times in one session. This is because I do not believe in batching together multiple topics in a single blog; if five things go on, then five blog posts will be made. This keeps everything nice and separated for those of you wishing to share news with your friends.
This blog is centered heavily around Linux and Open Source Software (OSS). I am a Linux user, and I believe that from a security standpoint OSS is the only player in its class. The reason for this is that closed source software cannot be combed for security bugs by the general population, or augmented with new security features.
While blackhats may encounter exploits by disassembling, tracing, or pure experimentation, whitehats tend to be more focused on source code auditing. Finding the bugs in the source means having the code available to write up a quick fix and submit it. This is feasible with OSS, requiring no NDA contracts or legal negotiations. There are several projects which do exactly this, such as the Debian Security Audit Project.
With no statistical backup, my intuition tells me that hiding the source code will deter whitehats more than blackhats from discovering security flaws, which means that flaws are more likely to be exploited before they are found. Closed source software may have more or fewer security holes than OSS, but I believe those flaws will have a longer lifetime. Because of this, the window of attack is widened; attackers can spend more time feeling out what they believe to be exploits and learning how exactly to trigger and use them without worrying that somebody else will find and fix the bugs.
Sometimes newer security features can disbar existing bugs. If these features interfere with a piece of OSS, then those supporting these new features can correct the problem to aid with the deployment of new security technology. Features such as stack guarding and proper managment of memory protections can be deployed in OSS freely; recompilations and source code tweaks are both feasible.
Closed software is updated at the leisure of the developers, whenever they want to make a new release, and only if they actually decide it's worth their time to support such software. Sometimes the developers do not care to expend their resources on correcting what they believe is an obscure bug that probably can't be exploited in any useful way, at least not until somebody exploits it. It's even more likely that adapting the code to fix an incompatibility with a new system will be a low priority task, especially if that system is not mandatory and can be disabled for the program.
Aside from this, the same principles apply to the overall quality of the software. If we're going to work on enhanced security, we should do it with better software. OSS is easily accessable as a research base; but it's also capable of being very high quality. OSS is more capable of being both relativly bug-free and highly featureful.
Anyone can find and fix bugs in OSS. The code is available and all are welcome to modify it. These modifications normally go upstream, especially if they involve bugfixes. As a notable example of the impacts of this, the Linux kernel has fewer bugs than most software. Any popular OSS will have lots of eyes scanning for bugs, meaning that bugs will have a higher chance of being fixed. Thus, as a general trend, OSS is more likely to be genuinely more stable and more secure.
Anyone can add a feature to OSS without first evaluating it for marketability and lobbying for company resources. If the feature is disinteresting, it will be removed later. If it's interesting but poorly implemented, the implementation will be enhanced. Resources can be external and automatic; an interested developer may appear with a patch for a new feature after working on it independently. Thus, OSS is more likely to contain mid- to high-demand features and some nifty but low-demand features, rather than simply high-demand features or features which are predicted to become high-demand.
Because of all these things, I believe that security research is both best suited and more beneficial primarily in Open Source Software. It's a lot easier to research what you can actually examine freely; and it's better to apply enhancements first to the better environment and allow the worse one to atropy or catch up.