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 "Maintenance"
Weilin Zhong (talk | contribs) |
m (Minor change to Objective "through out" changed to "throughout") |
||
| Line 7: | Line 7: | ||
* products are properly maintained post deployment | * products are properly maintained post deployment | ||
| − | * minimize the | + | * minimize the attack surface area throughout the production lifecycle |
* security defects are fixed properly and in a timely fashion | * security defects are fixed properly and in a timely fashion | ||
Revision as of 20:08, 26 March 2008
Guide Table of ContentsObjective
To ensure that
- products are properly maintained post deployment
- minimize the attack surface area throughout the production lifecycle
- security defects are fixed properly and in a timely fashion
Platforms Affected
All.
Relevant COBIT Topics
DS6 – Manage Changes – All sections should be reviewed
Best Practices
There is a strong inertia to resist patching “working” (but vulnerable) systems. It is your responsibility as a developer to ensure that the user is as safe as is possible and encourage patching vulnerable systems rapidly by ensuring that your patches are comprehensive (ie no more fixes of this type are likely), no regression of previous issues (ie fixes stay fixed), and stable (ie you have performed adequate testing).
Supported applications should be regularly maintained, looking for new methods to obviate security controls
It is normal within the industry to provide support for n-1 to n-2 versions, so some form of source revision control, such as CVS, ClearCase, or SubVersion will be required to manage security bug fixes to avoid regression errors
Updates should be provided in a secure fashion, either by digitally signing packages, or using a message digest which is known to be relatively free from collisions
Support policy for security fixes should be clearly communicated to users, to ensure users are aware of which versions are supported for security fixes and when products are due to be end of lifed.
Security Incident Response
Many organizations are simply not prepared for public disclosure of security vulnerabilities. There are several categories of disclosure:
- Hidden
- 0day
- Full disclosure and limited disclosure
- With and without vendor response
Vendors with a good record of security fixes will often gain early insight into security vulnerabilities. Others will have many public vulnerabilities published to 0day boards or mailing lists.
How to determine if you are vulnerable
Does the organization:
- Have an incident management policy?
- Monitor abuse@...
- Monitor Bugtraq and similar mail lists for their own product
- Publish a security section on their web site? If so, does it have the ability to submit a security incident? In a secure fashion (such as exchange of PGP keys or via SSL)?
- Could even the most serious of security breaches be fixed within 30 days? If no, what would it take to remedy the situation?
If any of the questions are “no”, then the organization is at risk from 0day exposure.
How to protect yourself
- Create and maintain an incident management policy
- Monitor abuse@...
- Monitor Bugtraq and similar mail lists. Use the experience of similar products to learn from their mistakes and fix them before they are found in your own products
- Publish a security section on their web site, with the ability to submit a security incident in a secure fashion (such as exchange of PGP keys or via SSL)
- Have a method of getting security fixes turned around quickly, certainly fully tested within 30 days.
Fix Security Issues Correctly
Security vulnerabilities exist in all software. Occasionally, these will be discovered by outsiders such as security researchers or customers, but more often than not, the issues will be found whilst working on the next version.
Security vulnerabilities are “patterned” – it is extraordinarily unlikely that a single vulnerability is the only vulnerability of its type. It is vital that all similar vulnerabilities are eliminated by using root cause analysis and attack surface area reduction occurs. This will require a comprehensive search of the application for “like” vulnerabilities to ensure that no repeats of the current vulnerability crop up.
Microsoft estimates that each fix costs more than $100,000 to develop, test, and deploy, and obviously many tens of millions more by its customers to apply. Only by reducing the number of fixes can this cost be reduced. It is far cheaper to spend a little more time and throw a little more resources at the vulnerability to close it off permanently.
How to identify if you are vulnerable
Certain applications will have multiple vulnerabilities of a similar nature released publicly on mail lists such as Bugtraq. Such applications have not been reviewed to find all similar vulnerabilities or to fix the root cause of the issue.
How to protect yourself
- Ensure that root cause analysis is used to identify the underlying reason for the defect
- Use attack surface area reduction and risk methodologies to remove as many vulnerabilities of this type as is possible within the prescribed time frame or budget
Update Notifications
Often users will obtain a product and never upgrade it. However, sometimes it is necessary for the product to be updated to protect against known security vulnerabilities.
How to identify if you are vulnerable
- Is there a method of notifying the owners / operators / system administrators of the application that there is a newer version available?
How to protect yourself
Preferably, the application should have the ability to “phone home” to check for newer versions and alert system administrators when new versions are available. If this is not possible, for example, in highly protected environments where “phone home” features are not allowed, another method should be offered to keep the administrators up to date.
Regularly check permissions
Applications are at the mercy of system administrators who are often fallible. Applications that rely upon certain resources being protected should take steps to ensure that these resources are not publicly exposed and have sufficient protection as per their risk to the application.
How to identify if you are vulnerable
- Does the application require certain files to be “safe” from public exposure? For example, many J2EE applications are reliant upon web.xml to be read only for the servlet container to protect against local users reading infrastructure credentials. PHP applications often have a file called “config.php” which contains similar details.
- If such a resource exists, does relaxing the permissions expose the application to vulnerability from local or remote users?
How to protect yourself
The application should regularly review the permissions of key files, directories and resources that contain application secrets to ensure that permissions have not been relaxed. If the permissions expose an immediate danger, the application should stop functioning until the issue is fixed, otherwise, notifying or alerting the administrator should be sufficient.
Further Reading
Howard, M., Reducing the attack surface area of applications
http://msdn.microsoft.com/msdnmag/issues/04/11/AttackSurface/default.aspx
Maintenance
This section provides guidance on maintaining ColdFusion MX. Even with securely coded applications, developers and hackers may find security flaws in the ColdFusion engine itself. Macromedia routinely performs security checks and responds to customer reported security incidents. The company provides software releases to address identified flaws and publishes security bulletins and technical briefs to provide customer notification of the issues and fixes.
The following is a partial list of software release types supported and tested by Macromedia .
| Type | Description | Delivery |
| Hot Fix | Fixes a specific problem that has been escalated through support or customer service. Requires a specific code base in order to apply. It is not guaranteed that any two Hot Fixes will work together properly. | Electronic delivery. Distributed by Support, Engineering Escalation Team (EET), or another Macromedia group. |
| Security Update | Fixes a specific security issue. Requires a specific code base in order to apply. | Electronic delivery. Distributed by Support or Engineering Escalation Team (EET) on the Security Zone. |
| Updaters | Includes all applicable Hot Fixes and Security Fixes to date. May include additional bug fixes. May include additional updates to drivers, databases, platform support, or other initiatives. Requires a specific code base in order to apply. | Electronic delivery. Usually posted on the product's Support Center. |
Security updates for all Macromedia software can be downloaded at http://www.macromedia.com/devnet/security/security_zone/index.html. Find a list of the latest product updates for all Macromedia products at http://www.macromedia.com/downloads/updates/.
Best Practice
Utilize the Macromedia Security Topic Center at http://www.macromedia.com/devnet/security
Subscribe to Macromedia Security Notification Services at http://www.macromedia.com/cfusion/entitlement/index.cfm?e=szalert
Read the published Macromedia Security Bulletins at http://www.macromedia.com/devnet/security/security_zone/
Only implement the solutions provided in any security bulletin that are applicable to your environment.
Immediately notify Macromedia if you find a bug or security vulnerability.
For security vulnerabilities use http://www.macromedia.com/devnet/security/security_zone/alertus.html
For software bugs use http://www.macromedia.com/support/email/wishform/
Utilize the Macromedia ColdFusion Support Center
Download and apply the latest ColdFusion updates
Get ColdFusion Updaters from http://www.macromedia.com/support/coldfusion/downloads_updates.html.
Review the ColdFusion hot fixes technote at http://www.macromedia.com/go/tn_17883
Only install any relevant hot fixes that are not already included in the latest ColdFusion Updater.
Search the ColdFusion Support Center for updated information from ColdFusion technical support
ColdFusion Technote Index: http://www.macromedia.com/support/coldfusion/technotes.html
Read the ColdFusion documentation: http://www.macromedia.com/support/documentation/en/coldfusion/
Release notes contain a list of identified issues and bug fixes in each ColdFusion software release. The ColdFusion release notes are posted at http://www.macromedia.com/support/documentation/en/coldfusion/releasenotes.html
The Macromedia LiveDocs provides an online version the ColdFusion MX 7 manuals (with customer comments): http://livedocs.macromedia.com/coldfusion/7/index.html
Ensure that the platform on which ColdFusion is running has the latest stable patches. This includes the operating system and web server.
