This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Deployment"

From OWASP
Jump to: navigation, search
 
Line 1: Line 1:
 +
[[Guide Table of Contents]]__TOC__
 +
 +
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
 +
 +
 +
 +
==Code signing  ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
 +
 +
 +
 +
==Permissions are set to least privilege ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
==Automated packaging ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
 +
 +
==Automated deployment ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
==Automated removal ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
==No backup or old files ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
==Unnecessary features are off by default ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
==Setup log files are clean ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
==No default accounts ==
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===How to protect yourself ===
 +
 +
==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.
 +
 +
===How to identify if you are vulnerable ===
 +
 +
===It’s almost impossible to prevent clever  ===
 +
 +
===How to protect yourself ===
 +
 +
 +
 +
==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.
 +
 +
==Further Reading ==
 +
 +
===Deploying applications  ===
 +
 +
* (PHP) Deploying PHP web applications with Ant:
 +
 +
<u>http://www.onlamp.com/pub/a/php/2005/12/20/php_ant.html</u> 
 +
 +
* (J2EE) Deploying for the web using Ant:
 +
 +
<u>http://www.onjava.com/pub/a/onjava/excerpt/AntTDG_chap8/index.html</u>
 +
 +
<u>http://www.onjava.com/pub/a/onjava/excerpt/AntTDG_chap8/index1.html</u>
 +
 +
* (Apple MacOS X) Package Maker
 +
 +
<u>http://developer.apple.com/tools/installerpolicy.html</u>
 +
 +
* (Many Linux distros) Redhat Package Manager (RPM)
 +
 +
<u>http://www.rpm.org/</u>
 +
 +
* (Debian, and MacOS X using Fink) Advanced Packaging Tool
 +
 +
<u>http://www.debian.org/doc/manuals/apt-howto/index.en.html</u>
 +
 +
* (Solaris) Application Packaging Developer’s Guide
 +
 +
<u>http://docs.sun.com/app/docs/doc/806-7008/</u>
 +
 +
* (Win32, .NET, any framework where xcopy works as a deployment tool)
 +
 +
Microsoft Windows Installer XML (wix), a free Windows installer creator
 +
 +
<u>http://sourceforge.net/projects/wix</u>
 +
 +
===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:
 +
 +
<u>http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html</u>
 +
 +
* Sony has a voluntary recall program for XCP infected disks:
 +
 +
<u>http://cp.sonybmg.com/xcp/</u>
 +
 +
* Settlement details of at least ten class action lawsuits against Sony:
 +
 +
<u>http://www.eff.org/IP/DRM/Sony-BMG/</u>
 +
 +
* Microsoft distributes macro viruses on CD
 +
 +
<u>http://www.f-secure.com/v-descs/wazzu.shtml</u> 
  
  
 
[[Guide Table of Contents]]
 
[[Guide Table of Contents]]
 
[[Category:OWASP_Guide_Project]]
 
[[Category:OWASP_Guide_Project]]

Revision as of 17:35, 22 May 2006

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


Code signing

How to identify if you are vulnerable

How to protect yourself

Permissions are set to least privilege

How to identify if you are vulnerable

How to protect yourself

Automated packaging

How to identify if you are vulnerable

How to protect yourself

Automated deployment

How to identify if you are vulnerable

How to protect yourself

Automated removal

How to identify if you are vulnerable

How to protect yourself

No backup or old files

How to identify if you are vulnerable

How to protect yourself

Unnecessary features are off by default

How to identify if you are vulnerable

How to protect yourself

Setup log files are clean

How to identify if you are vulnerable

How to protect yourself

No default accounts

How to identify if you are vulnerable

How to protect yourself

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.

How to identify if you are vulnerable

It’s almost impossible to prevent clever

How to protect yourself

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.

Further Reading

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

Retrieved from "https://wiki.owasp.org/index.php?title=Deployment&oldid=3102"