guidance_for_requirements_5_and_6_-_maintain_a_vulnerability_management_program [Control]

GUIDANCE FOR REQUIREMENTS 5 AND 6: MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM

Requirement 5: Use and regularly update anti-virus software or programs

Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans—enters the network during many business approved activities including employees' e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

Requirement		Guidance
5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).		There is a constant stream of attacks using widely published exploits, often “0 day” (published and spread throughout networks within an hour of discovery) against otherwise secured systems. Without anti-virus software that is updated regularly, these new forms of malicious software can attack and disable your network. Malicious software may be unknowingly downloaded and/or installed from the internet, but computers are also vulnerable when using removable storage devices such as CDs and DVDs, USB memory sticks and hard drives, digital cameras, personal digital assistants (PDAs) and other peripheral devices. Without anti-virus software installed, these computers may become access points into your network, and/or maliciously target information within the network. While systems that are commonly affected by malicious software typically do not include mainframes and most Unix systems (see more detail below), each entity must have a process according to PCI DSS Requirement 6.2 to identify and address new security vulnerabilities and update their configuration standards and processes accordingly. Trends in malicious software related to operating systems an entity uses should be included in the identification of new security vulnerabilities, and methods to address new trends should be incorporated into the company's configuration standards and protection mechanisms as needed. Typically, the following operating systems are not commonly affected by malicious software: mainframes, and certain Unix servers (such as AIX, Solaris, and HP-Unix). However, industry trends for malicious software can change quickly and each organization must comply with Requirement 6.2 to identify and address new security vulnerabilities and update their configuration standards and processes accordingly.
5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.		It is important to protect against ALL types and forms of malicious software.
5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.		The best anti-virus software is limited in effectiveness if it does not have current anti-virus signatures or if it isn't active in the network or on an individual's computer. Audit logs provide the ability to monitor virus activity and anti-virus reactions.

Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.
Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

Requirement		Guidance
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.		There are a considerable amount of attacks using widely published exploits, often “0 day” (published within the hour) against otherwise secured systems. Without implementing the most recent patches on critical systems as soon as possible, a malicious individual can use these exploits to attack and disable the network. Consider prioritizing changes such that critical security patches on critical or at-risk systems can be installed within 30 days, and other less risky changes are installed within 2-3 months.
6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.		The intention of this requirement is that organizations are kept up-to-date with new vulnerabilities so they can appropriately protect their network, and incorporate newly discovered and relevant vulnerabilities into their configuration standards.
6.3 Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices and incorporate information security throughout the software development life cycle. These processes must include the following:		Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment.
6.3.1 Testing of all security patches, and system and software configuration changes before deployment 6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) 6.3.1.2 Validation of proper error handling 6.3.1.3 Validation of secure cryptographic storage 6.3.1.4 Validation of secure communications 6.3.1.5 Validation of proper role-based access control (RBAC)		Ensure all installations and changes are performing as expected, and that they do not have any functions that are unexpected, unwanted, or harmful.
6.3.2 Separate development/test and production environments		Often development and test environments are less secure than the production environment. Without adequate separation, the production environment and cardholder data may be at risk due to vulnerabilities or weak internal processes.
6.3.3 Separation of duties between development/test and production environments		This minimizes the number of personnel with access to the production environment and cardholder data, and helps ensure that access is limited to those who truly need that access.
6.3.4 Production data (live PANs) are not used for testing or development		Security controls are usually not as stringent in the development environment. Use of production data provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data).
6.3.5 Removal of test data and accounts before production systems become active		Test data and accounts should be removed from production code before the application becomes active, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data.
6.3.6 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers		Custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or are released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data.
6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle required by PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.		Security vulnerabilities in custom code are commonly exploited by malicious individuals to gain access to a network and compromise cardholder data. Those with knowledge of secure coding techniques should review code to identify vulnerabilities.
6.4 Follow change control procedures for all changes to system components. The procedures must include the following:		Without proper software change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced. If related personnel policies for background checks and system access controls are not adequate, there is a risk that untrustworthy and untrained individuals may have unrestricted access to software code, terminated employees may have the opportunity to compromise systems, and unauthorized actions may not be detected.
6.4.1 Documentation of impact		The impact of the change should be documented so that all affected parties will be able to plan appropriately for any processing changes.
6.4.2 Management sign-off by appropriate parties		Management approval indicates that the change is a legitimate and authorized change sanctioned by the organization.
6.4.3 Testing of operational functionality		Thorough testing should be performed to verify that all actions are expected, reports are accurate, that all possible error conditions react properly, etc.
6.4.4 Back-out procedures		For each change, there should be back-out procedures in case the change fails, to allow for restoring back to the previous state.
6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.		The application layer is high-risk and may be targeted by both internal and external threats. Without proper security, cardholder data and other confidential company information can be exposed, resulting in harm to a company, its customers, and its reputation.
6.5.1 Cross-site scripting (XSS)		All parameters should be validated before inclusion. XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws.		Validate input to verify user data cannot modify meaning of commands and queries. Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality. This is also a popular way to conduct fraudulent transactions on commerce-enabled web sites. Information from web requests should be validated before being sent to the web application - for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.
6.5.3 Malicious file execution		Validate input to verify application does not accept unexpected filenames or files from users. Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
6.5.4 Insecure direct object references		Do not expose internal object references to users. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
6.5.5 Cross-site request forgery (CSRF)		Do not reply on authorization credentials and tokens automatically submitted by browsers. A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
6.5.6 Information leakage and improper error handling		Do not leak information via error messages or other means. Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks. Also, incorrect error handling provides information that helps a malicious individual compromise the system. If a malicious individual can create errors that the web application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server. For example, the message “incorrect password provided” tells them the user ID provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like “data could not be verified.”
6.5.7 Broken authentication and session management		Properly authenticate users and protect account credentials and session tokens. Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
6.5.8 Insecure cryptographic storage		Prevent cryptographic flaws. Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
6.5.9 Insecure communications		Properly encrypt all authenticated and sensitive communications. Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
6.5.10 Failure to restrict URL access		Consistently enforce access control in presentation layer and business logic for all URLs. Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: * Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes * Installing a web-application firewall in front of public-facing web applications		Manual or automated vulnerability security assessment tools or methods that review and/or scan for application vulnerabilities can be used to satisfy this requirement Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured. See Information Supplement: Requirement 6.6 Application Reviews and Web-Application Firewalls Clarified (www.pcisecuritystandards.org) for more information.

You could leave a comment if you were logged in.