I find that legacy code poses a unique challenge for organizations rolling out a new security process.  Often, the resources dedicated to maintaining older code are a small fraction of those devoted to new features or products.  Furthermore, the original developers for such features have often moved on, leaving no subject matter experts to drive reviews.  The astute reader will ask “How do I apply the principles of the Microsoft SDL to legacy code when I have no development resources and nobody knows how it works?”

The answer is “Start small, and build expertise over time.”

A Rising Tide Lifts All Boats

The best thing a security engineering team can do to improve security in the short term is to drive code quality, and the first step in this process is to define and enforce a secure coding standard.  This helps on two fronts: 

1.       It will improve code quality and reduce implementation flaws across the entire code base.  Unlike other security processes, driving a secure coding standard is relatively easy to accomplish across an entire code base, regardless of the code’s age, by a focused security team.  That is not to say that it is easy without qualification – a large batch of spaghetti code will require a lot of work to untangle!  Such an effort can only be called “easy” when compared to, say, comprehensive identification and remediation of design flaws across legacy features.  Even so, improving code quality through the use of secure coding standards offers a unique combination of high impact, applicability to features, and ability to be carried out by a core team that makes it a sensible first step.

2.       The security team might notice that some sections of code have more standards violations or outright flaws than others.  This is an instance of vulnerability clustering, a concept that has been used to predict vulnerability rates and improve quality in the functional realm.  The evidence is anecdotal, but it stands to reason that portions of code that consistently violate secure coding standards are good places to start looking for other classes of security flaw.  These are security hotspots, and should be high on the prioritized list for further review.

Security testing may also be applied to legacy code, but initial activities should be considered on a case-by-case basis based on the expected return on investment.  Such testing ranges from using inexpensive off-the-shelf tools to exercise common interfaces to rather expensive custom testing and formal analysis.  It is worthwhile to begin with off-the-shelf tools, such as those that target file parsers or web applications, and tools created as part of your greater secure development efforts.  These can help identify easily-found flaws and suggest improvements to the coding standards.  Comprehensive security testing, on the other hand, is best tackled after the Legacy Security Push.

The Legacy Security Push

Coding standards and basic testing provide bang for the buck, but formal security processes seek to provide security assurance.  The challenge for legacy code is that it needs to play catch-up.  Security processes that occur early in the development cycle, such as requirements analysis, design review, and threat modeling, are particularly difficult to achieve years after the fact.  The main goal of the Legacy Security Push is to create the deliverables from these efforts, the most important of which are security requirements and a full risk analysis.

It may sound trivial, but security requirements are essential.  Not only do they define proper operation for the system in question, they also define assumptions that are suitable for relying systems.   It is very common to find security flaws in legacy systems that arise from well-intentioned but incorrect assumptions such as “I assume that the Foo authenticates server Bar when initiating a bank transfer.”  It stands to reason that Foo would do so for such an important activity, but this assumption must be validated.  It is very common for older features to have been deployed in and written for different environments where the security assumptions that are "obvious" today just didn't apply at the time.

When reviewing legacy systems, the first step is to identify such requirements.  If the original architects, developers or managers are available, they can provide valuable insight at this stage.  More often than not this is not the case, and analysis must instead rely on what documentation is present and interaction between the software and its consumers.  The goal is the same as in requirements analysis during project inception, except that in this case one must turn the process on its head and reverse engineer requirements from system behavior.  At the conclusion of this effort, requirements can be theorized – “Foo must authenticate its server Bar before initiating a bank transfer.” 

Risk analysis can be performed once a plausible set of requirements have been identified.  Threat modeling is a more structured means of performing such an analysis, with the eventual goal of identifying means by which requirements can be violated by an attacker. 

As with requirements analysis, original developers would be a valuable resource to consult.  With or without such help, the first step is to identify how the software works.  In many cases, help is not available and performing this task requires a great deal of effort.  For features of moderate size, this author has spent upwards of a month reading code, using process profiling tools, and walking through the software with a debugger to identify program flow and security-sensitive functionality.

Once completed, actual system behavior should be documented and compared against the requirements theorized.   It might be that the requirements should be re-evaluated (New requirement:  Do not assume that Foo requires server authentication) or the system may need to be changed (New bug:   Foo does not verify the CN for Bar).  At the end, this information should be sufficient to support a comprehensive threat modeling exercise where security requirements, risks, and their mitigations can be documented.

Next Steps

Bringing a legacy feature up to par with its newer kin requires a relatively small number of items:  improved code quality, clear security requirements, and a thorough threat model.  As we have seen, performing even these tasks is quite the effort!  I am sure that it is little comfort to be reminded that accomplishing these tasks has simply laid the foundation, and that the true benefit is that the newly-reviewed legacy feature is able to participate fully in the security processes that remain: reviewing cross-component security requirements and assumptions, comprehensive testing, and incident planning, to name a few.

Unfortunately, there is no silver bullet in security assurance.  The soundness of the design and implementation of legacy software is just as important as in newer software, which is why any complete secure software development process will look backwards as well as forwards.  Feature by feature, from higher priority to lower, the overall security of the software improves as legacy code receives the full security treatment it deserves.

Ten days before VMworld and VMware still can’t get good press. First their CEO, Diane Greene, gets ousted, then a high-profile licensing bug is found and now the Director of R&D, Richard Sarwal, leaves his $1.25 million salary after just 7 months. (Note to self: get into R&D) It will be interesting to take the pulse of the VMware community at the show and in person. And in the meantime, Microsoft Hyper-V comes out of the gate with customers already touting its benefits.

The hypervisor is the “new” operating system. If you didn’t think that before, take a look at Red Hat’s purchase of Qumranet for $107 million. With Qumranet, Red Hat gets KVM, described by CTO Brian Stevens as an extension to the Linux kernel that allows it to be used as a bare-metal hypervisor, running directly on the underlying hardware and hosting guest operating systems. But according to Brian Madden, the “press” around the purchase is all focusing on the not-so-interesting part. Along with KVM, the SolidICE product includes Spice, a remote display protocol for VDI.

I wonder if this will be like Symantec buying Altiris or Microsoft buying Softricity, where the portion that we care about sort of loses focus as The Borg concentrates on the parts of the acquired technology that are more relevant to them?

(I’m a sucker for quotes that reference The Borg)

Network World publishes “10 open source companies to watch”. On the list, Qumranet!

Also on the list: Kickfire, Marketcetera, Vyatta, Sonatype, Untangle, XAware, SnapLogic, Acquia and Openmoko. What’s best about the list: Matt Asay gives it a thumbs up.

• Untangle makes money from software by selling
  proprietary, for-profit extensions to our core open source code. We
  have targeted these extensions to appeal to larger, commercial
  customers. Our core software is open-source, full-featured, and free.
  Period.
• Untangle optionally packages its software on Pentium-based server appliances.
  We sell these servers at “cost-plus,” and so this is deliberately
  positioned as a convenience to our customers and channel and not as a
  core money-making strategy.
• Untangle sells tech support services, primarily to larger commercial customers, but also some of the larger schools and non-profits

So lets have a look. First off, if you don't know Untangle has a UTM that is aimed squarely at the "S" in the SMB market. It is open sourced and free and is made up of modules based on open source security tools. I get the upsell of extensions or premium features for some modules and premium modules, that is a no brainer. I don't disagree with the off the shelf hardware justification either, though there are many companies selling off the shelf appliances for a significant mark up over cost and it is a profit center for them. Untangle seems to be writing that revenue stream off. Than Bob says they are selling tech support services to larger customers. Again there is nothing earth shattering on that. Maybe sharing the revenue with local implementation partners? Again sounds like a VAR play, nothing special.

Here is where I think Bob and Untangles model could be in trouble. Bob assumes that the underlying software Untangle uses will be free, because it is free to them. But Untangle is using a Heinz 57 mix of open source security software of which it owns little if any of the copyrights. Yes, much of the software is today open source under GPL. But what happens if the copyright holders of the software and the project owners decide that Untangle is profiting from their software and hard work. What happens if they decide to dual license the software to anyone repackaging it in a UTM or other commercial product or for profit entity. Than what does Untangle do? Their whole business model goes down the tubes. From what I know of Untangles downloaded user base and their conversion rate to paying customers and what they charge, I don't think they have the margin to pay for any software. They could fork the software and develop it themselves or hope to develop a community to continue development, but I haven't seen that pulled off very often, if at all.

To stay with Bob's money for nothin theme, if he does not protect against this, Untangle could find themselves in dire straits.