Almost every company today has a presence on the web. These websites are much more complex from yesteryear’s simple set of static pages. Today, a company’s site is a growing collection of support documents, forums, various search tools, user login and management, and more. And I’m only talking about sites like those for car manufacturers or consumer electronics.
Companies that produce web-based services, like Amazon or Salesforce, have a much deeper and much broader website, providing much more functionality to the site’s visitors. Every new piece of functionality brings along the potential for attacks from black hats. Innovative startups and small companies are trying new things, potentially exposing themselves to new functionality, tools, and processes that could be subverted by the black hats.
However, any good security researcher will tell you that your system design and operations are the best way to protect your website, much more than the tools used to implement that design. PCI Level 2 Compliance may be a terribly burdensome process, but once you have been audited to that level, then your confidence in your site security will be much higher.
Similar design processes can apply to any web site: controlling access to data, limiting exposure to subsystems, audit trails, and more. A well-designed system expects and limits its own security vulnerabilities.
The second-most important aspect of creating a secure website is keeping the technology and tools updated. A site will always be subject to “zero day” exploits, but automatic updates will minimise your exposure over time. Once a fix is released, then your site can automatically deploy the change. In some cases, you may need sophisticated deployment processes to release a change, but your monitoring and paging systems should be configured to immediately alert you of new security fixes that need to be deployed.
Whether these services are provided by Microsoft, RedHat, Canonical, or some other software vendor, they should be used by your operations team. You will note that the above two concerns (design, and deployment of security fixes) are completely independent of whether your tools are proprietary or open source.
Empirical research shows that vulnerabilities are about as common to each type of licensing. Proprietary vendors will tell you, “black hats will research open source code to find vulnerabilities”, and open source vendors will tell you, “vulnerabilities can be found and fixed before black hats exploit them”. Each vendor has a stake in the game and will be biased in their answers, but the simplest answer is that exploits are found about as frequently in each type. Choose your packages independent of the licensing model. Choose them based on how those packages fit into your overall design and operations.
Additionally, you will want to consider the maturity of the technology that you choose. That maturity level should be considered in your system design. If a component is relatively young, and not much is known about its potential security vulnerabilities, then you may want to ensure is more strongly isolated. Mature components such as the Apache HTTP Server or Microsoft’s IIS can be deployed with much more confidence.
Rest assured that the licensing of your tools, libraries, and technology has little impact on your site security. Concentrate on your system design and operations first, the implementation and maturity second, and licensing last.
Blog post by Greg Stein
Greg is a Board Member/Director, Vice Chairman, Vice President Apache Subversion, and former Chairman of The Apache Software Foundation. Widely recognised for his work on versioning systems including Subversion and WebDAV, Greg most recently was an engineering manager at Google, where he launched Google Project Hosting. He's currently focused on licensing, developer tools, and community development.