Deployment

Guide Table of Contents

Deployment is the first and sometimes the only experience system administrators will have with your application. Customers who buy or use your application appreciate the lower costs of securely deployed software – if their system administrators do not have to spend hours or days securing your software, they are far more likely to choose your software over an insecure competitor.

Ease of deployment is a key consideration for many highly available or highly changeable systems. Systems have a special knack of buying the farm at 3 am Monday morning before the busiest day of the year. If your application can be trivially installed at 3 am by tired and emotional system administrators, they will remember you fondly when the time comes for new software or the next version. The worst case alternative is that your customers may not be around if your software takes three days to install.

Secure deployment is essential for high value systems. High value systems require controls in excess of basic software. This chapter guides you through packaging and deployment issues.

Objective
To ensure that the application is deployed as easily and as securely as possible.

Platforms Affected
All.

Best Practices

 * Software should have automated installers and provide automated uninstallers


 * Software should deploy using a least privilege security model


 * Software should not expose any secrets once installed


 * Documentation should not contain any default accounts, nor should the installer contain any pre-chosen or default accounts

Release Management
Release management is a formal process designed to ensure that applications are released in a tested and controlled fashion.

How to identify if you are vulnerable
Is there release management in place? If so, does it cover?


 * Deployment testing


 * Acceptance testing

How to protect yourself

 * Read software quality assurance references


 * Write deployment instructions


 * Eliminate all steps that can be automated


 * Implement a deployment acceptance test

Secure delivery of code
Attackers have been known to send malicious code to end users, so it is vital that your users and customers can obtain your software in a secure fashion.

How to identify if you are vulnerable
Secure delivery of code is relatively simple to test, and even easier to rectify.


 * Pretend to be a normal customer. Obtain your software in the usual fashion.


 * Was it obtained from a retailer or other distributor in hard format? If so, does the software contain instructions on how to validate it against legitimate deliveries?


 * Does the media contain any viruses or harmful code?


 * Was it obtained from a third party download site? If so, does it contain an accurate link back to your

How to protect yourself
Secure

Easter eggs
Easter eggs are mostly small (but sometimes not) hidden features. Often they will contain the developer’s names or activate hidden advanced or developer features, but occasionally, they are more like mini-applications. For the most part, they have no business function.

Figure 7 Adobe InDesign CS SVG Easter Egg

Easter eggs are fairly popular with developers, but they are problematic from a software engineering and legal view point. Unless easter eggs have been sufficiently designed and tested, easter eggs can cause the application to crash or misbehave. For example, Word 97 contained a pinball game and Excel 97 contained a small flight simulator. If these crashed with unsaved data, the application is not acting within design parameters, opening up liability.

However, there is a case for including debug functionality, as long as it is tested, not enabled by default, and is documented within the user or administration manual.

Malicious software
The delivery of software is littered with examples of software delivered with something more than the users bargained for.

Examples include:


 * Sony’s XCP root kit is delivered on millions of audio disks, infecting at least half a million PCs. Major legal problems have ensued, and set copy prohibition technologies back at least five years


 * Microsoft through a lack of a quality assured distribution process (now resolved), distributed viruses on multiple occasions, such as Concept and Wazzu

These examples are highly embarrassing, extremely expensive (in Sony’s case, hundreds of millions of dollars) to resolve, and truly trivial to prevent.

In most countries, it is now illegal to create, distribute, and use software that acts in a surreptitious and devious manner. Users will remember any vendor attempting such criminal sabotage and never buy from such vendors again. In Australia, such criminal acts are punishable with fines of up to $250,000 per infected computer, and up to 10 years imprisonment. Similar statutes and punishments exist in most countries.

'''OWASP is not a source of legal advice; if you think your software flies close to the wind, you must seek competent legal opinion. Even better, do not create or distribute such software. Karma will bite you on the flip side. '''

How to identify if you are vulnerable
Does your software contain any malicious code, which performs unauthorized or damaging activity? This could be code like Sony’s root kit. If so remove it.

Did you check your final software image for known:


 * viruses using at least one up to date virus scanner?


 * spyware using at least one up to date spyware scanner?

Is it possible for an auditor to determine when this scan took place?

How to protect yourself
Do not create or distribute malicious software – it is illegal in most countries.

Scan your final distribution images and media with at least one up to date virus scanner and at least one spyware checker. Document in your manual the date of this scan and the software used.

Deploying applications

 * (PHP) Deploying PHP web applications with Ant:

http://www.onlamp.com/pub/a/php/2005/12/20/php_ant.html


 * (J2EE) Deploying for the web using Ant:

http://www.onjava.com/pub/a/onjava/excerpt/AntTDG_chap8/index.html

http://www.onjava.com/pub/a/onjava/excerpt/AntTDG_chap8/index1.html


 * (Apple MacOS X) Package Maker

http://developer.apple.com/tools/installerpolicy.html


 * (Many Linux distros) Redhat Package Manager (RPM)

http://www.rpm.org/


 * (Debian, and MacOS X using Fink) Advanced Packaging Tool

http://www.debian.org/doc/manuals/apt-howto/index.en.html


 * (Solaris) Application Packaging Developer’s Guide

http://docs.sun.com/app/docs/doc/806-7008/


 * (Win32, .NET, any framework where xcopy works as a deployment tool)

Microsoft Windows Installer XML (wix), a free Windows installer creator

http://sourceforge.net/projects/wix

Examples of bad deployment practices
Sony’s root kit settlement will cost Sony more than $150 million and seriously set back their anti-consumer copy prohibition agenda


 * Sony, Rootkits and Digital Rights Management Gone Too Far:

http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html


 * Sony has a voluntary recall program for XCP infected disks:

http://cp.sonybmg.com/xcp/


 * Settlement details of at least ten class action lawsuits against Sony:

http://www.eff.org/IP/DRM/Sony-BMG/


 * Microsoft distributes macro viruses on CD

http://www.f-secure.com/v-descs/wazzu.shtml

Guide Table of Contents