Applications

A thorough understanding of application security requires in-depth knowledge of the basic underlying application architecture as well as a solid understanding of the application's user base. Only then can you begin identifying the potential threat vectors. The following best practices are meant to help you review applications within your organization and assess them from a security and availability standpoint. It examines technologies used within the environment to help enhance Defense-in- Depth.ine-height:normal'>An organization can mitigate application risk by focusing on the following areas of application security:

· Deployment & Use — Load-Balancing, Clustering, Application & Data Recovery, Third Party Independent Software Vendor, Internally Developed, Vulnerabilities

· Application Design — Authentication, Password Policies, Authorization & Access Control, Logging, and Input Validation

· Data Storage & Communications — Encryption

Deployment & Use
Subcategory	Best Practices
Third-party independent software vendor (ISV)	The third-party independent software vendor (ISV) should regularly provide patches and upgrades for their application, and they should explain the purpose of patches and any impact you may expect in terms of the functionality, configuration, or security of the application being patched. The third-party ISV should clearly identify critical patches so that they can quickly be applied. The third-party ISV should explain all of the application's security mechanisms and provide up-to-date documentation. The organization should be aware of any configuration requirements necessary to ensure the highest level of security.
Vulnerabilities	All known security vulnerabilities should be identified and patched. Regularly monitor vendor and third-party security sites for new vulnerability information and available patches. If there are any known security vulnerabilities that do not have available patches, determine when a patch will be available and develop an interim mitigation plan to address that vulnerability. Consider using a third party to conduct periodic assessments to evaluate the application's security design. A third-party assessment may also turn up areas where additional security mechanisms are beneficial.

Deployment and Use - Resources
2007 Office Security Guide	As risks from malicious attack have increased, desktop application security mechanisms have evolved. The new security model in the 2007 Microsoft Office release provides new mechanisms, settings, and features that allow your organization to achieve an effective balance between protection and productivity while minimizing user disruption. You might think that such risks come from outside your organization, and can therefore be stopped by effective network security mechanisms such as firewalls, proxy servers, and intrusion detection systems. However, many of these business risks can come from internal users and unsecured systems that are at the heart of your organization. Unless securely configured, the desktop applications that your information workers rely on to send e-mail, write documents, create presentations, and analyze data can be critical pathways for attack by malicious software (malware), including spyware, Trojan horses, viruses, and worms. References http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx
Microsoft Rights Management Services for Windows Server 2003	Microsoft Windows Rights Management Services (RMS) for Windows Server 2003 is information protection technology that works with RMS-enabled applications to help safeguard digital information from unauthorized use—both online and offline, inside and outside of the firewall. RMS augments an organization's security strategy by protecting information through persistent usage policies, which remain with the information, no matter where it goes. Organizations can use RMS to help prevent sensitive information—such as financial reports, product specifications, customer data, and confidential e-mail messages—from intentionally or accidentally getting into the wrong hands. This services is built into Windows Server 2008 as Active Directory Rights Management Services (ADRMS) References http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx
Windows Server 2008 - Active Directory Rights Management Services	Windows Server 2008 - Active Directory Rights Management Services (AD RMS) is an information protection technology that works with AD RMS-enabled applications (Office 2007) to help safegaurd digital information from unauthorized use. Content owners can define who can open, modify, print, forward or take other actions with the information. References http://technet2.microsoft.com/windowsserver2008/en/library/37c240d3-8928-4267-867b-4c005b72cca21033.mspx?mfr=true
Windows Server 2008 – Clustering	Failover clustering in Windows Server 2008 can help you build redundancy into your network and eliminate single points of failure. The improvements to failover clusters (formerly known as server clusters) in Windows Server 2008 are aimed at simplifying clusters, making them more secure, and enhancing cluster stability. All of which helps reduce downtime, guard against data loss, and reduce your total cost of ownership. Because they are included in the enhanced-capability editions of Windows Server 2008, such as Windows Server 2008 Enterprise and Windows Server 2008 Datacenter, Windows Server 2008 failover clusters are much less expensive than comparable systems, which can cost thousands of dollars. Ease of deployment and affordability make Windows Server 2008 an ideal high-availability solution for organizations of all sizes. References http://www.microsoft.com/windowsserver2008/en/us/clustering-home.aspx

Application Design
Subcategory	Best Practices
Authentication	The application should implement an authentication mechanism whose strength is commensurate with requirements governing security of data or access to functionality. Applications that rely on passwords should provide for password complexity constraints that include character mix (alpha, numeric, and symbols), minimum length, history maintenance, enforced lifetime, pre-expiration, and dictionary checking. The application should log failed login attempts, excluding the password. Each component that provides access to data or functionality should verify the existence of proper authentication credentials. Administrative access to systems should be protected with the strongest forms of authentication available. Typically the restrictions around password creation for administrators should be greater than those for normal accounts. In addition to strong passwords with good password policies, for added security multifactor authentication should be considered.
Password Policies	The use of strong passwords is a basic element of Defense-in-Depth. Strong passwords should be 8 to 14 characters in length, with alphanumeric and special characters. Minimum length, history maintenance, lifetime, and pre-expiration of passwords should all be set to provide additional defenses to password strength. In general, password expiration should be set to the following: · Maximum length 90 days · New accounts must change password at login · Password history of 8 passwords (8 days minimum) Administrative access to systems should be protected with the strongest forms of authentication available. Typically, the restrictions around password creation for administrators should be greater than those for normal accounts—if normal accounts require a password length of 8 characters, then administrative accounts should have 14-character passwords. Account lockout, after 10 failed login attempts, should be enabled on all user accounts. The controls around account lockout can vary from simply being focused on blocking brute-force password attacks to as complex as requiring administrator intervention to unlock. Consider the following guidelines when implementing controls around account lockout: · Account lockout after at least 10 failed login attempts for user account · Require administrative access to re-enable accounts for critical applications and automatically re-enable regular user accounts after 5 minutes for other application · 30-minute length to cache failures for regular user accounts
Authorization & Access Control	Applications should implement an authorization mechanism that provides access to sensitive data and functionality only to suitably permitted users or clients. Role-based access controls should be enforced at the database level as well as at the application interface. This will protect the database in the event that the client application is exploited. Authorization checks should require prior successful authentication to have occurred. All attempts to obtain access without proper authorization should be logged. Conduct regular testing of key applications that process sensitive data and of the interfaces available to users from the Internet. Include both "black box" and "informed" testing against the application. Determine if users can gain access to data from other accounts.
Logging	Logging should be enabled across all applications in the environment. Log file data is important for incident and trend analysis as well as for auditing purposes. The applications should log failed and successful authentication attempts, changes to application data including user accounts, severe application errors, and failed and successful access to resources. When writing log data, the application should avoid writing sensitive data to log files.
Input Validation	The application may accept input at multiple points from external sources, such as users, client applications, and data feeds. It should perform validation checks of the syntactic and semantic validity of the input. It should also check that input data does not violate limitations of underlying or dependent components, particularly string length and character set. All user-supplied fields should be validated at the server side.
Software Security Development Methodologies	Institute to use of software security development methodologies to increase the security of your applications. When using consultants or vendors in any phase of your development cycle, ensure that they are trained on the software security development methodology your organization uses or one your organization recommends. Your organization's full development staff should be trained on the software security development methodology your organization has chosen. This includes Development Managers, Developers, Testers and Quality Assurance Staff. With the evolving security threat landscape, it is important to update your software security development methodology training and threat modeling training on an annual basis. Your development staff would be required to take updated security development training each year. The use of security software testing tools improves your team's ability to write secure code more effectively. Output from the use of your testing tools should be incorporated into your required annual training.

For more information on the SDL Process, read The Microsoft Security Development Lifecycle (SDL): Process Guidance

Data Storage & Communications
Subcategory	Best Practices
Encryption	Sensitive data should be encrypted or hashed in the database and file system. The application should differentiate between data that is sensitive to disclosure and must be encrypted, data that is sensitive only to tampering and for which a keyed hash value (HMAC) must be generated, and data that can be irreversibly transformed (hashed) without loss of functionality (such as passwords). The application should store keys used for decryption separately from the encrypted data. Sensitive data should be encrypted prior to transmission to other components. Verify that intermediate components that handle the data in clear-text form, prior to transmission or subsequent to receipt, do not present an undue threat to the data. The application should take advantage of authentication features available within the transport security mechanism. Examples of widely accepted strong ciphers are 3DES, AES, RSA, RC4, and Blowfish. Use 128-bit keys (1024 bits for RSA) at a minimum.
Encryption - Algorithm	The application should use industry-standard cryptographic algorithms with keys of appropriate sizes and cryptographic modes appropriate to the need. Industry recognized strong ciphers include 3DES, AES, RSA, Blowfish, and RC4. A minimum key size of 128 bits (1024 bits for RSA) should be used.