Information Security Policy

1. Introduction

2. Information Security Policy

• Handle Company and cardholder information in a manner that fits with their sensitivity;
• Limit personal use of the Car Part Planet information and telecommunication systems and ensure it doesn't interfere with your job performance;
• Car Part Planet reserves the right to monitor, access, review, audit, copy, store, or delete any electronic communications, equipment, systems and network traffic for any purpose;
• Do not use e-mail, internet and other Company resources to engage in any action that is offensive, threatening, discriminatory, defamatory, slanderous, pornographic, obscene, harassing or illegal;
• Do not disclose personnel information unless authorised;
• Protect sensitive cardholder information;
• Keep passwords and accounts secure;
• Request approval from management prior to establishing any new software or hardware, third party connections, etc.;
• Do not install unauthorised software or hardware, including modems and wireless access unless you have explicit management approval;
• Always leave desks clear of sensitive cardholder data and lock computer screens when unattended;
• Information security incidents must be reported, without delay, to the individual responsible for incident response locally – Please find out who this is.

3. Acceptable Use Policy

• Employees are responsible for exercising good judgment regarding the reasonableness of personal use.
• Employees should ensure that they have appropriate credentials and are authenticated for the use of technologies.
• Employees should take all necessary steps to prevent unauthorized access to confidential data which includes card holder data.
• Employees should ensure that technologies should be used and setup in acceptable network locations.
• Keep passwords secure and do not share accounts.
• Authorized users are responsible for the security of their passwords and accounts.
• All PCs, laptops and workstations should be secured with a password-protected screensaver with the automatic activation feature.
• All POS and PIN entry devices should be appropriately protected and secured so they cannot be tampered or altered.
• Because information contained on portable computers is especially vulnerable, special care should be exercised.
• Postings by employees from a Company email address to newsgroups should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of the Car Part Planet, unless posting is in the course of business duties.
• Employees must use extreme caution when opening e-mail attachments received from unknown senders, which may contain viruses, e-mail bombs, or Trojan horse code.

4. Disciplinary Action

5. Protect Stored Data

• All sensitive cardholder data stored and handled by the Car Part Planet and its employees must be securely protected against unauthorised use at all times. Any sensitive card data that is no longer required by the Car Part Planet for business reasons must be discarded in a secure and irrecoverable manner.
• If there is no specific need to see the full PAN (Permanent Account Number), it has to be masked when displayed.
• PAN'S which are not protected as stated above should not be sent to the outside network via end user messaging technologies like chats, ICQ messenger etc.,

• The contents of the payment card magnetic stripe (track data) on any media whatsoever.
• The CVV/CVC (the 3 or 4 digit number on the signature panel on the reverse of the payment card) on any media whatsoever.
• The PIN or the encrypted PIN Block under any circumstance.

6. Information Classification

• Confidential data might include information assets for which there are legal requirements for preventing disclosure or financial penalties for disclosure, or data that would cause severe damage to the Car Part Planet if disclosed or modified.Confidential data includes cardholder data.
• Internal Use data might include information that the data owner feels should be protected to prevent unauthorized disclosure;
• Public data is information that may be freely disseminated.

7. Access to the sensitive cardholder data

• Any display of the card holder should be restricted at a minimum of the first 6 and the last 4 digits of the cardholder data.
• Access rights to privileged user ID's should be restricted to least privileges necessary to perform job responsibilities.
• Privileges should be assigned to individuals based on job classification and function (Role based access control).
• Access to sensitive cardholder information such as PAN's, personal information and business data is restricted to employees that have a legitimate need to view such information.
• No other employees should have access to this confidential data unless they have a genuine business need.
• If cardholder data is shared with a Service Provider (3rd party) then a list of such Service Providers will be maintained as detailed in Appendix B.
• The Car Part Planet will ensure a written agreement that includes an acknowledgement is in place that the Service Provider will be responsible for the for the cardholder data that the Service Provider possess.
• The Car Part Planet will ensure that a there is an established process including proper due diligence is in place before engaging with a Service provider.
• The Car Part Planet will have a process in place to monitor the PCI DSS compliance status of the Service provider.

8. Physical Security

• Employees are responsible for exercising good judgment regarding the reasonableness of personal use.
• Employees should ensure that they have appropriate credentials and are authenticated for the use of technologies.
• Employees should take all necessary steps to prevent unauthorized access to confidential data which includes card holder data.
• Employees should ensure that technologies should be used and setup in acceptable network locations.
• A list of devices that accept payment card data should be maintained.
• The list should include make, model and location of the device.
• The list should have the serial number or a unique identifier of the device.
• The list should be updated when devices are added, removed or relocated.
• POS devices surfaces should be periodically inspected to detect tampering or substitution.
• Personnel using the devices should be trained and aware of handling the POS devices.
• Personnel using the devices should verify the identity of any third party personnel claiming to repair or run maintenance tasks on the devices, install new devices or replace devices.
• Personnel using the devices should be trained to report suspicious behaviour and indications of tampering of the devices to the appropriate personnel.
• A "visitor" is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the premises for a short duration, usually not more than one day.
• Keep passwords secure and do not share accounts. Authorized users are responsible for the security of their passwords and accounts.
• Media is defined as any printed or handwritten paper, received faxes, floppy disks, back-up tapes, computer hard drive, etc.
• Media containing sensitive cardholder information must be handled and distributed in a secure manner by trusted individuals.
• Visitors must always be escorted by a trusted employee when in areas that hold sensitive cardholder information.
• Procedures must be in place to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. "Employee" refers to full-time and part-time employees, temporary employees and personnel, and consultants who are "resident" on the Car Part Planet sites. A "visitor" is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the premises for a short duration, usually not more than one day.
• Network Jacks located in public and areas accessible to visitors must be disabled and enabled when network access is explicitly authorised.
• All POS and PIN entry devices should be appropriately protected and secured so they cannot be tampered or altered.
• Strict control is maintained over the external or internal distribution of any media containing card holder data and has to be approved by management.
• Strict control is maintained over the storage and accessibility of media.
• All computer that store sensitive cardholder data must have a password protected screensaver enabled to prevent unauthorised use.

9. Protect Data in Transit

• Card holder data (PAN, track data etc) must never be sent over the internet via email, instant chat or any other end user technologies.
• If there is a business justification to send cardholder data via email or via the internet or any other modes then it should be done after authorization and by using a strong encryption mechanism (i.e. – AES encryption, PGP encryption, IPSEC, GSM, GPRS, Wireless technologies etc.,).
• The transportation of media containing sensitive cardholder data to another location must be authorised by management, logged and inventoried before leaving the premises. Only secure courier services may be used for the transportation of such media. The status of the shipment should be monitored until it has been delivered to its new location.

10. Disposal of Stored Data

• All data must be securely disposed of when no longer required by the Car Part Planet, regardless of the media or application type on which it is stored.
• An automatic process must exist to permanently delete on-line data, when no longer required.
• All hard copies of cardholder data must be manually destroyed as when no longer required for valid and justified business reasons. A quarterly process must be in place to confirm that all non-electronic cardholder data has been appropriately disposed of in a timely manner.
• The Car Part Planet will have procedures for the destruction of hardcopy (paper) materials. These will require that all hardcopy materials are crosscut shredded, incinerated or pulped so they cannot be reconstructed.
• The Car Part Planet will have documented procedures for the destruction of electronic media. These will require:
• All cardholder data on electronic media must be rendered unrecoverable when deleted e.g. through degaussing or electronically wiped using military grade secure deletion processes or the physical destruction of the media;
• If secure wipe programs are used, the process must define the industry accepted standards followed for secure deletion.
• All cardholder information awaiting destruction must be held in lockable storage containers clearly marked "To Be Shredded" - access to these containers must be restricted.

11. Security Awareness and Procedures

• Review handling procedures for sensitive information and hold periodic security awareness meetings to incorporate these procedures into day to day company practice.
• Distribute this security policy document to all company employees to read. It is required that all employees confirm that they understand the content of this security policy document by signing an acknowledgement form (see Appendix A).
• All employees that handle sensitive information will undergo background checks (such as criminal and credit record checks, within the limits of the local law) before they commence their employment with the Company.
• All third parties with access to credit card account numbers are contractually obligated to comply with card association security standards (PCI/DSS).
• Company security policies must be reviewed annually and updated as needed.

12. Network security

• Firewalls must be implemented at each internet connection and any demilitarized zone and the internal company network.
• A network diagram detailing all the inbound and outbound connections must be maintained and reviewed every 6 months.
• A firewall and router configuration document must be maintained which includes a documented list of services, protocols and ports including a business justification.
• Firewall and router configurations must restrict connections between untrusted networks and any systems in the card holder data environment.
• Stateful Firewall technology must be implemented where the Internet enters the Car Part Planet Card network to mitigate known and on-going threats. Firewalls must also be implemented to protect local network segments and the IT resources that attach to those segments such as the business network, and open network.
• All inbound and outbound traffic must be restricted to that which is required for the card holder data environment.
• All inbound network traffic is blocked by default, unless explicitly allowed and the restrictions have to be documented.
• All outbound traffic has to be authorized by management (i.e. what are the whitelisted category of sites that can be visited by the employees) and the restrictions have to be documented.
• The Car Part Planet will have firewalls between any wireless networks and the cardholder data environment.
• the Car Part Planet will quarantine wireless users into a DMZ, where they will be authenticated and firewalled as if they were coming in from the Internet.
• A topology of the firewall environment has to be documented and has to be updated in accordance to the changes in the network.
• The firewall rules will be reviewed on a six months basis to ensure validity and the firewall has to have clean up rule at the bottom of the rule base.
• The Car Part Planet have to quarantine wireless users into a DMZ, where they were authenticated and firewalled as if they were coming in from the Internet.
• No direct connections from Internet to cardholder data environment will be permitted. All traffic has to traverse through a firewall.

13. System and Password Policy

• A system configuration standard must be developed along industry acceptable hardening standards (SANS, NIST, ISO).
• System configurations should be updated as new issues are identified (as defined in PCI DSS requirement 6.1).
• System configurations must include common security parameter settings.
• The systems configuration standard should be applied to any news systems configured.
• All vendor default accounts and passwords for the systems have to be changed at the time of provisioning the system/device into the Car Part Planet network and all unnecessary services and user/system accounts have to be disabled.
• All unnecessary default accounts must be removed or disabled before installing a system on the network.
• Security parameter settings must me set appropriately on System components.
• All unnecessary functionality (scripts, drivers, features, subsystems, file systems, web servers etc.,) must be removed.
• All unnecessary services, protocols, daemons etc., should be disabled if not in use by the system.
• Any insecure protocols, daemons, services in use must be documented and justified.
• All user must use a password to access the company network or any other electronic resources.
• All user ID's for terminated users must be deactivated or removed immediately.
• The User ID will be locked out if there are more than 5 unsuccessful attempts. This locked account can only be enabled by the system administrator. Locked out user accounts will be disabled for a minimum period of 30 minutes or until the administrator enables the account.
• All system and user level passwords must be changed on at least a quarterly basis.
• A minimum password history of four must be implemented.
• A unique password must be setup for new users and the users prompted to change the password on first login.
• Group, shared or generic user account or password or other authentication methods must not be used to administer any system components.
• Where SNMP is used, the community strings must be defined as something other than the Standard defaults of "public," "private" and "system" and must be different from the passwords used to log in interactively.
• All non-console administrative access will use appropriate technologies like ssh,vpn etc or strong encryption is invoked before the administrator password is requested.
• System services and parameters will be configured to prevent the use of insecure technologies like telnet and other insecure remote login commands.
• Administrator access to web based management interfaces is encrypted using strong cryptography.
• The responsibility of selecting a password that is hard to guess generally falls to users. A strong password must:
• Be as long as possible (never shorter than 6 characters).
• Include mixed-case letters, if possible.
• Not be based on any personal information.
• Not be based on any dictionary word, in any language.
• If an operating system without security features is used (such as DOS, Windows or MacOS), then an intruder only needs temporary physical access to the console to insert a keyboard monitor program. If the workstation is not physically secured, then an intruder can reboot even a secure operating system, restart the workstation from his own media, and insert the offending program.
• To protect against network analysis attacks, both the workstation and server should be cryptographically secured. Examples of strong protocols are the encrypted Netware login and Kerberos.

14. Anti-virus policy

• All machines must be configured to run the latest anti-virus software as approved by the Car Part Planet. The preferred application to use is of Anti-Virus software, which must be configured to retrieve the latest updates to the antiviral program automatically on a daily basis. The antivirus should have periodic scanning enabled for all the systems.
• The antivirus software in use should be cable of detecting all known types of malicious software (Viruses, Trojans, adware, spyware, worms and rootkits).
• All removable media (for example floppy and others) should be scanned for viruses before being used.
• All the logs generated from the antivirus solutions have to be retained as per legal/regulatory/contractual requirements or at a minimum of PCI DSS requirement 10.7 of 3 months online and 1 year offline.
• Master Installations of the Antivirus software should be setup for automatic updates and periodic scans.
• End users must not be able to modify and any settings or alter the antivirus software.
• E-mail with attachments coming from suspicious or unknown sources should not be opened. All such e-mails and their attachments should be deleted from the mail system as well as from the trash bin. No one should forward any e-mail, which they suspect may contain virus.

15. Patch Management Policy

• All Workstations, servers, software, system components etc. owned by the Car Part Planet must have up-to-date system security patches installed to protect the asset from known vulnerabilities.
• Where ever possible all systems, software must have automatic updates enabled for system patches released from their respective vendors. Security patches have to be installed within one month of release from the respective vendor and have to follow the process in accordance with change control process.
• Any exceptions to this process have to be documented.

16. Remote Access policy

• It is the responsibility of the Car Part Planet employees, contractors, vendors and agents with remote access privileges to the Car Part Planet's corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to the Car Part Planet.
• Secure remote access must be strictly controlled. Control will be enforced by two factor authentication via one-time password authentication or public/private keys with strong pass-phrases.
• Vendor accounts with access to the Car Part Planet network will only be enabled during the time period the access is required and will be disabled or removed once access is no longer required.
• Remote access connection will be setup to be disconnected automatically after 30 minutes of inactivity.
• All hosts that are connected to the Car Part Planet internal networks via remote access technologies will be monitored on a regular basis.
• All remote access accounts used by vendors or 3rd parties will be reconciled at regular interviews and the accounts will be revoked if there is no further business justification.
• Vendor accounts with access to the Car Part Planet network will only be enabled during the time period the access is required and will be disabled or removed once access is no longer required.

17. Vulnerability Management Policy

• All the vulnerabilities would be assigned a risk ranking such as High, Medium and Low based on industry best practices such as CVSS base score.
• As part of the PCI-DSS Compliance requirements, the Car Part Planet will run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
• Quarterly internal vulnerability scans must be performed by the Car Part Planet by internal staff or a 3rd party vendor and the scan process has to include that rescans will be done until passing results are obtained, or all High vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.
• Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by PCI SSC. Scans conducted after network changes may be performed by the Company's internal staff. The scan process should include re-scans until passing results are obtained.

18. Configuration standards:

• Information systems that process transmit, or store card holder data must be configured in accordance with the applicable standard for that class of device or system. Standards must be written and maintained by the team responsible for the management of the system in conjunction with the Information Security Office.
• All network device configurations must adhere to the Car Part Planet required standards before being placed on the network as specified in the Car Part Planet configuration guide. Using this guide, a boilerplate configuration has been created that will be applied to all network devices before being placed on the network.
• Before being deployed into production, a system must be certified to meet the applicable configuration standard.
• Updates to network device operating system and/or configuration settings that fall under the Company standards are announced by the Information security Office. Updates must be applied within the time frame identified by the Information security Office.
• Administrators of network devices that do not adhere to the Car Part Planet standards (as identified via a previous exception) must document and follow a review process of announced vendor updates to operating system and/or configuration settings. This process must include a review schedule, risk analysis method and update method.
• All network device configurations must be checked annually against the configuration boilerplate to ensure the configuration continues to meet required standards.
• Where possible, network configuration management software will be used to automate the process of confirming adherence to the boilerplate configuration.
• For other devices an audit will be performed quarterly to compare the boilerplate configuration to the configuration currently in place.
• All discrepancies will be evaluated and remediated by Network Administration.

19. Change control Process

• Changes to information resources shall be managed and executed according to a formal change control process. The control process will ensure that changes proposed are reviewed, authorised, tested, implemented, and released in a controlled manner; and that the status of each proposed change is monitored.
• The change control process shall be formally defined and documented. A change control process shall be in place to control changes to all critical company information resources (such as hardware, software, system documentation and operating procedures). This documented process shall include management responsibilities and procedures. Wherever practicable, operational and application change control procedures should be integrated.
• All change requests shall be logged whether approved or rejected on a standardised and central system. The approval of all change requests and the results thereof shall be documented. A documented audit trail, maintained at a Business Unit Level, containing relevant information shall be maintained at all times. This should include change request documentation, change authorisation and the outcome of the change. No single person should be able to effect changes to production information systems without the approval of other authorised personnel.
• A risk assessment shall be performed for all changes and dependant on the outcome, an impact assessment should be performed.
• The impact assessment shall include the potential effect on other information resources and potential cost implications. The impact assessment should, where applicable consider compliance with legislative requirements and standards.
• All change requests shall be prioritised in terms of benefits, urgency, effort required and potential impact on operations.
• Changes shall be tested in an isolated, controlled, and representative environment (where such an environment is feasible) prior to implementation to minimise the effect on the relevant business process, to assess its impact on operations and security and to verify that only intended and approved changes were made. (For more information see System Development Life Cycle [citation here]).
• Any software change and/or update shall be controlled with version control. Older versions shall be retained in accordance with corporate retention and storage management policies. (For more information see System Development Life Cycle [citation here])
• All changes shall be approved prior to implementation. Approval of changes shall be based on formal acceptance criteria i.e. the change request was done by an authorised user, the impact assessment was performed and proposed changes were tested.
• All users, significantly affected by a change, shall be notified of the change. The user representative shall sign-off on the change. Users shall be required to make submissions and comment prior to the acceptance of the change.
• Implementation will only be undertaken after appropriate testing and approval by stakeholders. All major changes shall be treated as new system implementation and shall be established as a project. Major changes will be classified according to effort required to develop and implement said changes. (For more information see System Development Life Cycle [citation here])
• Procedures for aborting and recovering from unsuccessful changes shall be documented. Should the outcome of a change be different to the expected result (as identified in the testing of the change), procedures and responsibilities shall be noted for the recovery and continuity of the affected areas. Fall back procedures will be in place to ensure systems can revert back to what they were prior to implementation of changes.
• Information resources documentation shall be updated on the completion of each change and old documentation shall be archived or disposed of as per the documentation and data retention policies.
• Specific procedures to ensure the proper control, authorisation, and documentation of emergency changes shall be in place. Specific parameters will be defined as a standard for classifying changes as Emergency changes.
• All changes will be monitored once they have been rolled-out to the production environment. Deviations from design specifications and test results will be documented and escalated to the solution owner for ratification.

20. Audit and Log review

• This procedure covers all logs generated for systems within the cardholder data environment, based on the flow of cardholder data over the Car Part Planet network, including the following components:
• Operating System Logs (Event Logs and su logs).
• Database Audit Logs.
• Firewalls & Network Switch Logs.
• IDS Logs.
• Antivirus Logs.
• Cctv Video recordings.
• File integrity monitoring system logs.
• Audit Logs must be maintained for a minimum of 3 months online (available for immediate analysis) and 12 months offline.
• Review of logs is to be carried out by means of the Car Part Planet’s network monitoring system (the Company to define hostname), which is controlled from the Car Part Planet console (the Company to define hostname). The console is installed on the server (the Company to define hostname / IP address), located within the Car Part Planet data centre environment.
• The following personnel are the only people permitted to access log files (the Company to define which individuals have a job-related need to view audit trails and access log files).
• The network monitoring system software (the Company to define) is configured to alert the Car Part Planet [RESPONSIBLE TEAM] to any conditions deemed to be potentially suspicious, for further investigation. Alerts are configured to:
• A dashboard browser-based interface, monitored by the Company [RESPONSIBLE TEAM].
• Email / SMS alerts to the Car Part Planet [RESPONSIBLE TEAM] mailbox with a summary of the incident. The Company [ROLE NAME] also receives details of email alerts for informational purposes.
• The following Operating System Events are configured for logging, and are monitored by the console (the Car Part Planet to define hostname):
• Any additions, modifications or deletions of user accounts.
• Any failed or unauthorised attempt at user logon.
• Any modification to system files.
• Any access to the server, or application running on the server, including files that hold cardholder data.
• Actions taken by any individual with root or administrative privileges.
• Any user access to audit trails.
• Any creation / deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)
• The following Database System Events are configured for logging, and are monitored by the network monitoring system (the Car Part Planet to define software and hostname):
• Any failed user access attempts to log in to the Oracle database.
• Any login that has been added or removed as a database user to a database.
• Any login that has been added or removed from a role.
• Any database role that has been added or removed from a database.
• Any password that has been changed for an application role.
• Any database that has been created, altered, or dropped.
• Any database object, such as a schema, that has been connected to.
• Actions taken by any individual with DBA privileges.
• The following Firewall Events are configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname):
• ACL violations.
• Invalid user authentication attempts.
• Logon and actions taken by any individual using privileged accounts.
• Configuration changes made to the firewall (e.g. policies disabled, added, deleted, or modified).
• The following Switch Events are to be configured for logging and monitored by the network monitoring system (the Company to define software and hostname):
• Invalid user authentication attempts.
• Logon and actions taken by any individual using privileged accounts.
• Configuration changes made to the switch (e.g. configuration disabled, added, deleted, or modified).
• The following Intrusion Detection Events are to be configured for logging, and are monitored by the network monitoring system (the Company to define software and hostname):
• Any vulnerability listed in the Common Vulnerability Entry (CVE) database.
• Any generic attack(s) not listed in CVE.
• Any known denial of service attack(s).
• Any traffic patterns that indicated pre-attack reconnaissance occurred.
• Any attempts to exploit security-related configuration errors.
• Any authentication failure(s) that might indicate an attack.
• Any traffic to or from a back-door program.
• Any traffic typical of known stealth attacks.
• The following File Integrity Events are to be configured for logging and monitored by (the Company to define software and hostname):
• Any modification to system files.
• Actions taken by any individual with Administrative privileges.
• Any user access to audit trails.
• Any Creation / Deletion of system-level objects installed by Windows. (Almost all system-level objects run with administrator privileges, and some can be abused to gain administrator access to a system.)
• For any suspicious event confirmed, the following must be recorded on F17 - Log Review Form, and the Car Part Planet informed:
• User Identification.
• Event Type.
• Date & Time.
• Success or Failure indication.
• Event Origination (e.g. IP address).
• Reference to the data, system component or resource affected.

21. Secure Application development

• The Secure Application development policy is a plan of action to guide developers' decisions and actions during the software development lifecycle (SDLC) to ensure software security. This policy aims to be language and platform independent so that it is applicable across all software development projects.
• The adherence to and use of Secure Application Development Coding Policy is a requirement for all software development on the Car Part Planet information technology systems and trusted contractor sites processing the Company data.
• Each phase of the SDLC is mapped with security activities, as explained below:
• Design
• Identify Design Requirements from security perspective
• Architecture & Design Reviews
• Threat Modelling
• Coding
• Coding Best Practices
• Perform Static Analysis
• Testing
• Vulnerability Assessment
• Fuzzing
• Deployment
• Server Configuration Review
• Network Configuration Review
• Development of code shall be checked and validated with the most current versions of the Car Part Planet Coding Standards for Secure Application Development. All code developers shall verify that their code is in compliance with the most recent and approved coding standards and guidelines.
• Only validated code shall be implemented into the Car Part Planet production environment. A review and validation ensures that code exhibits fundamental security properties to include correctness, predictability, and attack tolerance.

• Ensure code meets the level of confidence that software is free from exploitable code vulnerabilities, regardless of whether they are already designed into the software or inserted later in its life cycle.
• Ensure code provides predictable execution or justifiable confidence and that the software, when executed, will provide security functionality as intended.
• Coding techniques must address injection flaws particularly SQL injection,buffer overflow vulnerabilities, cross site scripting vulnerabilities, improper access control (insecure direct object reference, failure to restrict URL access, directory traversal etc.,), cross site request forgery (CSRF), broken authentication and session management
• Never rely on the client to store sensitive data no matter how trivial.
• Disable Error messages that return any information to the user.
• Use object inheritance, encapsulation, and polymorphism wherever possible.
• Use environment variables prudently and always check boundaries and buffers.
• Applications must validate input to ensure it is well-formed and meaningful.

22. Penetration testing methodology

• In this section should be listed the risks inherent in conducting penetration testing over the information systems of the Car Part Planet. Additionally, it should be noted for each mitigation measures that will be taken. Examples might be:

• Key staff involved in the project by the organization will be listed:
• Technical Project Manager.
• Chief Information Security Officer.
• Chief Information Officer.
• Head of Communications.
• Responsible for web site www.carpartplanet.com.

• External intrusion tests will be performed remotely from the supplier's premises .Internal intrusion tests will be conducted in the office the Car Part Planet of the Organization. Audit team must to have access to the Organization's network. It must manage access permissions to the building early enough to ensure that the audit team can access without problems during planning period.
• All the tests will be conducted from the equipment owned by the audit team so no equipment for the execution of the tests is required. The only requirement in this regard will be to have an active network connection for each member of the audit team. Those connections must provide access to the target network segment in every case.
• If an incident occurs during the execution of the tests that have an impact on the systems or services of the organization, the incident should be brought immediately to the attention of those responsible for incident management in the project
• It should be noted that in order to comply with PCI DSS the scope of the test should include, at least the following:
• All systems and applications that are part of the perimeter of the cardholder data environment card (CDE).

23. Incident Response Plan

24. Roles and Responsibilities

24. Roles and Responsibilities

26. User Access Management

27. Access Control Policy

28. Wireless Policy