15 April 2014


Posts relating to the information security principle "Integrity" are listed below.

07 March 2014

PCIDSS SAQ A-EP and SAQ A: Comparison of Questions

PCIDSS SAQ A-EP and SAQ A are very different in PCIDSS version 3.0, and there are some minor changes between SAQ A versions 2.0 and 3.0.

SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer's cardholder data.

In the table below, "Y" indicates the question is included in the SAQ. The question text is taken from PCIDSS v3.0, and there are some numbering differences with version 2.0 under requirement 9. There are an order of magnitude more questions on the Self-Assessment Questionnaire (SAQ) for "Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing" (SAQ-EP).

See my previous post for information about the SAQ A-EP eligibility criteria for e-commerce merchants and another post providing an introduction to the change.

Do all these questions apply to your own web site/e-commerce environment? The only answer to this is what your acquirer or payment brand requires of you, in your region (e.g. Europe). It is possibly the case that ecommerce-only merchants with fewer transactions (such as levels 3 and 4), might be asked to use the an acquirer's risk-based approach or only certain milestones in the PCIDSS prioritised approach.

And of course some questions may relate to PCIDSS requirements that are deemed not applicable to your environment, when the "N/A" option is then selected and the "Explanation of Non-Applicability" worksheet in Appendix C of SAQ A-EP is completed foreach "N/A" entry.

And to limit the PCIDSS scope, segmentation will be required to isolate the relevant e-commerce systems from other system components (see eligibility criteria), preferably also isolating as much of the non e-commerce aspects of the website. However, most of the designated PCIDSS requirements ought to be in place for security reasons anyway? Hopefully.

PCIDSS Self-Assessment Questionnaire (SAQ) Question v2.0 v3.0
1.1.4 (a) Is a firewall required and implemented at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone? Y
(b) Is the current network diagram consistent with the firewall configuration standards? Y
1.1.6 (a) Do firewall and router configuration standards include a documented list of services, protocols, and ports, including business justification (for example, hypertext transfer protocol (HTTP), Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols)? Y
(b) Are all insecure services, protocols, and ports identified, and are security features documented and implemented for each identified service? Y
1.2 Do firewall and router configurations restrict connections between untrusted networks and any system in the cardholder data environment as follows:
Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
1.2.1 (a) Is inbound and outbound traffic restricted to that which is necessary for the cardholder data environment? Y
(b) Is all other inbound and outbound traffic specifically denied (for example by using an explicit "deny all" or an implicit deny after allow statement)? Y
1.3.4 Are anti-spoofing measures implemented to detect and block forged sourced IP addresses from entering the network? (For example, block traffic originating from the internet with an internal address) Y
1.3.5 Is outbound traffic from the cardholder data environment to the Internet explicitly authorized? Y
1.3.6 Is stateful inspection, also known as dynamic packet filtering, implemented--that is, only established connections are allowed into the network? Y
1.3.8 (a) Are methods in place to prevent the disclosure of private IP addresses and routing information to the Internet?
Note: Methods to obscure IP addressing may include, but are not limited to:
* Network Address Translation (NAT) * Placing servers containing cardholder data behind proxy servers/firewalls,
* Removal or filtering of route advertisements for private networks that employ registered addressing, Internal use of RFC1918 address space instead of registered addresses.
(b) Is any disclosure of private IP addresses and routing information to external entities authorized? Y
2.1 (a) Are vendor-supplied defaults always changed before installing a system on the network?
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
(b) Are unnecessary default accounts removed or disabled before installing a system on the network? Y
2.2 (a) Are configuration standards developed for all system components and are they consistent with industry-accepted system hardening standards?
Sources of industry-accepted system hardening standards may include, but are not limited to, SysAdmin Audit Network Security (SANS) Institute, National Institute of Standards Technology (NIST), International Organization for Standardization (ISO), and Center for Internet Security (CIS).
(b) Are system configuration standards updated as new vulnerability issues are identified, as defined in Requirement 6.1? Y
(c) Are system configuration standards applied when new systems are configured? Y
(d) Do system configuration standards include all of the following:
* Changing of all vendor-supplied defaults and elimination of unnecessary default accounts?
* Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server?
* Enabling only necessary services, protocols, daemons, etc., as required for the function of the system?
* Implementing additional security features for any required services, protocols or daemons that are considered to be insecure?
* Configuring system security parameters to prevent misuse?
* Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers?
2.2.1 (a) Is only one primary function implemented per server, to prevent functions that require different security levels from co-existing on the same server?
For example, web servers, database servers, and DNS should be implemented on separate servers.
(b) If virtualization technologies are used, is only one primary function implemented per virtual system component or device? Y
2.2.2 (a) Are only necessary services, protocols, daemons, etc. enabled as required for the function of the system (services and protocols not directly needed to perform the device's specified function are disabled)? Y
(b) Are all enabled insecure services, daemons, or protocols justified per documented configuration standards? Y
2.2.3 Are additional security features documented and implemented for any required services, protocols or daemons that are considered to be insecure?
For example, use secured technologies such as SSH, S-FTP, SSL or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
2.2.4 (a) Are system administrators and/or personnel that configure system components knowledgeable about common security parameter settings for those system components? Y
(b) Are common system security parameters settings included in the system configuration standards? Y
(c) Are security parameter settings set appropriately on system components? Y
2.2.5 (a) Has all unnecessary functionality--such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers--been removed? Y
(b) Are enabled functions documented and do they support secure configuration? Y
(c) Is only documented functionality present on system components? Y
2.3 Is non-console administrative access encrypted as follows: Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
(a) Is all non-console administrative access encrypted with strong cryptography, and is a strong encryption method invoked before the administrator's password is requested? Y
(b) Are system services and parameter files configured to prevent the use of Telnet and other insecure remote login commands? Y
(c) Is administrator access to web-based management interfaces encrypted with strong cryptography? Y
(d) For the technology in use, is strong cryptography implemented according to industry best practice and/or vendor recommendations? Y
3.2 (c) ) Is sensitive authentication data deleted or rendered unrecoverable upon completion of the authorization process? Y
(d) Do all systems adhere to the following requirements regarding non-storage of sensitive authentication data after authorization (even if encrypted): Y
3.2.2 The card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) is not stored after authorisation Y
3.2.3 The personal identification number (PIN) or the encrypted PIN block is not stored after authorization? Y
4.1 (a) Are strong cryptography and security protocols, such as SSL/TLS, SSH or IPSEC, used to safeguard sensitive cardholder data during transmission over open, public networks?
Examples of open, public networks include but are not limited to the Internet; wireless technologies, including 802.11 and Bluetooth; cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA); and General Packet Radio Service (GPRS).
(b) ) Are only trusted keys and/or certificates accepted? Y
(c) Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? Y
(d) Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? Y
(e) For SSL/TLS implementations, is SSL/TLS enabled whenever cardholder data is transmitted or received?
For example, for browser-based implementations: * "HTTPS" appears as the browser Universal Record Locator (URL) protocol, and
* Cardholder data is only requested if "HTTPS" appears as part of the URL.
4.2 (b) Are policies in place that state that unprotected PANs are not to be sent via end-user messaging technologies? Y
5.1 Is anti-virus software deployed on all systems commonly affected by malicious software? Y
5.1.1 Are anti-virus programs capable of detecting, removing, and protecting against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits)? Y
5.1.2 Are periodic evaluations performed to identify and evaluate evolving malware threats in order to confirm whether those systems considered to not be commonly affected by malicious software continue as such? Y
5.2 Are all anti-virus mechanisms maintained as follows:
(a) Are all anti-virus software and definitions kept current? Y
(b) Are automatic updates and periodic scans enabled and being performed? Y
(c) Are all anti-virus mechanisms generating audit logs, and are logs retained in accordance with PCI DSS Requirement 10.7? Y
5.3 Are all anti-virus mechanisms:
* Actively running?
* Unable to be disabled or altered by users?
Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.
6.1 Is there a process to identify security vulnerabilities, including the following:
* Using reputable outside sources for vulnerability information?
* Assigning a risk ranking to vulnerabilities that includes identification of all "high" risk and "critical" vulnerabilities?
Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score and/or the classification by the vendor, and/or type of systems affected.
Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization's environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a "high risk" to the environment. In addition to the risk ranking, vulnerabilities may be considered "critical" if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems
6.2 (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches? Y
(b) Are critical security patches installed within one month of release?
Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.
6.4.5 (a) Are change-control procedures for implementing security patches and software modifications documented and require the following?
* Documentation of impact
* Documented change control approval by authorized parties
* Functionality testing to verify that the change does not adversely impact the security of the system
* Back-out procedures
(b) Are the following performed and documented for all changes: Y Documentation of impact? Y Documented approval by authorized parties? Y (a) Functionality testing to verify that the change does not adversely impact the security of the system? Y
(b) For custom code changes, testing of updates for compliance with PCI DSS Requirement 6.5 before being deployed into production? Y Back-out procedures? Y
6.5 (c) Are applications developed based on secure coding guidelines to protect applications from, at a minimum, the following vulnerabilities:
6.5.1 Do coding techniques address injection flaws, particularly SQL injection?
Note: Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
6.5.2 Do coding techniques address buffer overflow vulnerabilities? Y
For web applications and application interfaces (internal or external), are applications developed based on secure coding guidelines to protect applications from the following additional vulnerabilities:
6.5.7 Do coding techniques address cross-site scripting (XSS) vulnerabilities? Y
6.5.8 Do coding techniques address improper access control such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions? Y
6.5.9 Do coding techniques address cross-site request forgery (CSRF)? Y
6.5.10 Do coding techniques address broken authentication and session management?
Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement.
6.6 For public-facing web applications, are new threats and vulnerabilities addressed on an ongoing basis, and are these applications protected against known attacks by applying either of the following methods?
* Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, as follows:
- At least annually
- After any changes
- By an organization that specializes in application security
- That all vulnerabilities are corrected
- That the application is re-evaluated after the corrections
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
- OR -
* Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications to continually check all traffic.
7.1 Is access to system components and cardholder data limited to only those individuals whose jobs require such access, as follows:
7.1.2 Is access to privileged user IDs restricted as follows: * To least privileges necessary to perform job
* Assigned only to roles that specifically require that privileged access?
7.1.3 Are access assigned based on individual personnel's job classification and function? Y
8.1.1 1.1 Are all users assigned a unique ID before allowing them to access system components or cardholder data? Y
8.1.3 Is access for any terminated users immediately deactivated or removed? Y
8.1.5 (a) Are accounts used by vendors to access, support, or maintain system components via remote access enabled only during the time period needed and disabled when not in use? Y
(b) Are vendor remote access accounts monitored when in use? Y
8.1.6 (a) Are repeated access attempts limited by locking out the user ID after no more than six attempts? Y
8.1.7 Once a user account is locked out, is the lockout duration set to a minimum of 30 minutes or until an administrator enables the user ID? Y
8.2 In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all
* Something you know, such as a password or passphrase
* Something you have, such as a token device or smart card
* Something you are, such as a biometric
8.2.1 (a) Is strong cryptography used to render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components? Y
8.2.3 (a) Are user password parameters configured to require passwords/passphrases meet the following?
* A minimum password length of at least seven characters
* Contain both numeric and alphabetic characters
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
8.2.4 (a) Are user passwords/passphrases changed at least every 90 days? Y
8.2.5 (a) Must an individual submit a new password/phrase that is different from any of the last four passwords/phrases he or she has used? Y
8.2.6 Are passwords/phrases set to a unique value for each user for first-time use and upon reset, and must each user change their password immediately after the first use? Y
8.3 Is two-factor authentication incorporated for remote network access originating from outside the network by personnel (including users and administrators) and all third parties (including vendor access for support or maintenance)?
Note: Two-factor authentication requires that two of the three authentication methods (see PCI DSS Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.
Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.
8.5 Are group, shared, or generic accounts, passwords, or other authentication methods prohibited as follows:
* Generic user IDs and accounts are disabled or removed;
* Shared user IDs for system administration activities and other critical functions do not exist; and
* Shared and generic user IDs are not used to administer any system components?
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, and certificates, etc.), is the use of these mechanisms assigned as follows?
* Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts
* Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access
9.1 Are appropriate facility entry controls in place to limit and monitor physical access to systems in the cardholder data environment? Y
9.5 Are all media physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes)?
For purposes of Requirement 9, "media" refers to all paper and electronic media containing cardholder data.
Y (9.6) Y Y
9.6 (a) Is strict control maintained over the internal or external distribution of any kind of media? Y (9.7) Y Y
(b) Do controls include the following:
9.6.1 Is media classified so the sensitivity of the data can be determined? Y (9.7.1) Y Y
9.6.2 Is media sent by secured courier or other delivery method that can be accurately tracked? Y (9.7.2) Y Y
9.6.3 Is management approval obtained prior to moving the media (especially when media is distributed to individuals)? Y (9.8) Y Y
9.7 Is strict control maintained over the storage and accessibility of media? Y (9.9) Y Y
9.8 (a) Is all media destroyed when it is no longer needed for business or legal reasons? Y (9.10) Y Y
(c) Is media destruction performed as follows:
9.8.1 (a) Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed? Y (9.10.1a) Y Y
(b) Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents? Y (9.10.1b) Y Y
10.2 Are automated audit trails implemented for all system components to reconstruct the following events:
10.2.2 All actions taken by any individual with root or administrative privileges? Y
10.2.4 Invalid logical access attempts? Y
10.2.5 Use of and changes to identification and authentication mechanisms–including but not limited to creation of new accounts and elevation of privileges – and all changes, additions, or deletions to accounts with root or administrative privileges? Y
10.3 Are the following audit trail entries recorded for all system components for each event:
10.3.1 User identification? Y
10.3.2 Type of event? Y
10.3.3 Date and time? Y
10.3.4 Success or failure indication? Y
10.3.5 Origination of event? Y
10.3.6 Identity or name of affected data, system component, or resource? Y
10.5.4 Are logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) written onto a secure, centralized, internal log server or media? Y
10.6 Are logs and security events for all system components reviewed to identify anomalies or suspicious activity as follows?
Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6.
10.6.1 (b) Are the following logs and security events reviewed at least daily, either manually or via log tools?
* All security events
* Logs of all system components that store process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD
* Logs of all critical system components
* Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc
10.6.2 (b) Are logs of all other system components periodically reviewed--either manually or via log tools--based on the organization's policies and risk management strategy? Y
10.6.3 (b) Is follow up to exceptions and anomalies identified during the review process performed? Y
10.7 (b) Are audit logs retained for at least one year? Y
(c) Are at least the last three months' logs immediately available for analysis? Y
11.2.2 (a) Are quarterly external vulnerability scans performed?
Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).
Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.
(b) Do external quarterly scan and rescan results satisfy the ASV Program Guide requirements for a passing scan (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures)? Y
(c) Are quarterly external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV[)]? Y
11.2.3 (a) Are internal and external scans, and rescans as needed, performed after any significant change?
Note: Scans must be performed by qualified personnel.
(b) Does the scan process include rescans until: * For external scans, no vulnerabilities exist that
are scored 4.0 or higher by the CVSS;
* For internal scans, a passing result is obtained or all "high-risk" vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved?
(c) Are scans performed by a qualified internal resource(s) or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)? Y
11.3 Does the penetration-testing methodology include the following?
* Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
* Includes coverage for the entire CDE perimeter and critical systems
* Includes testing from both inside and outside the network
* Includes testing to validate any segmentation and scope-reduction controls
* Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
* Defines network-layer penetration tests to include components that support network functions as well as operating systems
* Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
* Specifies retention of penetration testing results and remediation activities results
11.3.1 (a) Is external penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)? Y
(b) Are tests performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)? Y
11.3.3 Are exploitable vulnerabilities found during penetration testing corrected, followed by repeated testing to verify the corrections? Y
11.3.4 (a) [If segmentation is used to isolate the CDE from other networks:] Are penetration-testing procedures defined to test all segmentation methods, to confirm they are operational and effective, and isolate all out-of-scope systems from in-scope systems? Y
(b) Does penetration testing to verify segmentation controls meet the following?
* Performed at least annually and after any changes to segmentation controls/methods
* Covers all segmentation controls/methods in use
* Verifies that segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.
11.5 (a) Is a change-detection mechanism (for example, file integrity monitoring tools) deployed within the cardholder data environment to detect unauthorized modification of critical system files, configuration files, or content files?
Examples of files that should be monitored include: * System executables
* Application executables
* Configuration and parameter files
* Centrally stored, historical or archived, log, and audit files
* Additional critical files determined by entity (for example, through risk assessment or other means)
(b) Is the change-detection mechanism configured to alert personnel to unauthorized modification of critical system files, configuration files or content files, and do the tools perform critical file comparisons at least weekly?
Note: For change detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is the merchant or service provider).
11.5.1 Is a process in place to respond to any alerts generated by the change-detection solution? Y
12.1 Is a security policy established, published, maintained, and disseminated to all relevant personnel? Y
12.1.1 Is the security policy reviewed at least annually and updated when the environment changes? Y
12.4 Do security policy and procedures clearly define information security responsibilities for all personnel? Y
12.5 (b) Are the following information security management responsibilities formally assigned to an individual or team:
12.5.3 Establishing, documenting, and distributing security incident response and escalation procedures to ensure timely and effective handling of all situations? Y
12.6 (a) Is a formal security awareness program in place to make all personnel aware of the importance of cardholder data security? Y
12.8 Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:
12.8.1 Is a list of service providers maintained? Y Y Y
12.8.2 Is a written agreement maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer's cardholder data environment?
Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.
12.8.3 Is there an established process for engaging service providers, including proper due diligence prior to engagement? Y Y Y
12.8.4 Is a program maintained to monitor service providers' PCI DSS compliance status at least annually? Y Y Y
12.8.5 Is information maintained about which PCI DSS requirements are managed by each service provider, and which are managed by the entity? Y Y
12.10.1 (a) Has an incident response plan been created to be implemented in the event of system breach? Y
(b) Does the plan address the following, at a minimum:
* Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum? Y
* Specific incident response procedures? Y
* Business recovery and continuity procedures? Y
* Data backup processes? Y
* Analysis of legal requirements for reporting compromises? Y
* Coverage and responses of all critical system components? Y
* Reference or inclusion of incident response procedures from the payment brands? Y
Total Number of Questions 13 14 139

Well, sorry this page is so long. When I began I thought it was a useful idea, and once started I wanted to complete the list. It is useful to me if no-one else.

Posted on: 07 March 2014 at 15:24 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

07 March 2014

PCIDSS SAQ A-EP for Partially Outsourced E-Commerce Merchants

On Friday last week, the Payment Card Industry Security Standards Council released of the remaining supporting documents for use with version 3.0 of the Payment Card Industry Data Security Standard (PCIDSS) and Payment Application Data Security Standard (PA-DSS).

Title page from the PCIDSS SAQ A-EP 'Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing'

The PCIDSS related documents were the Report on Compliance (RoC) template, attestations of compliance (AoC) for merchants and service providers, and the new self-assessment questionnaires (SAQs). Included with the updated SAQs is a new SAQ for "Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing".

This is important for e-commerce website operators. The e-commerce information supplement published last year described how many types of integration with third party payment providers involve shared responsibilities, and are not "completely outsourced".

SAQ A v2.0 for "All cardholder data functions outsourced - No Electronic Storage, Processing, or Transmission of Cardholder Data" has been used by some e-commerce merchants with third-party hosted payment pages (HPPs), but this new SAQ A-EP makes it clear that SAQ A is not always sufficient.

SAQ A-EP is applicable to e-commerce merchants with web sites that do not store, process or transmit cardholder data, but which do affect the security of the payment transaction and/or the integrity of the page that accepts cardholder data (i.e. at the payment service provider). This is relevant to all merchants who use a hosted payment page (HPP) where the payment form is hosted by themselves (on the merchant's systems), but submits (direct HTTP post) to the payment service provider. Payment forms using the alternative embedded IFRAME, or redirection to a payment form on the PCIDSS-compliant service provider's systems, and where the page never includes any non-service provider content, appear to still be eligible for SAQ A. Some further official guidance on this would be welcome.

If you have an e-commerce payment channel for consumers, especially if you are using direct post method, review the changes are plan your PCIDSS compliance approach. But do make sure you speak with your acquirer and, if you have one, your QSA. PCIDSS version 3.0 is effective from 1st January 2014 but version 2.0 can continue to be used for assessment until 31st December 2014.

Continue to SAQ A-EP eligibility criteria.

Posted on: 07 March 2014 at 15:20 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

04 March 2014

Apple iOS Security

Apple has released an update to its previous 2012 guide to iOS security.

Cover page from the new Apple security guide to 'iOS Security' published February 2014

The new version, iOS Security, February 2014 has 50% more content, with new sections about:

  • System software Authorization
  • Secure Enclave
  • Touch ID
  • FIPS 140-2
  • A whole new section on App Security
    • App Code Signing
    • Runtime Process Security
    • Data Protection in Apps
    • Accessories
  • Single Sign-on
  • AirDrop Security
  • A another new section on Internet Services
    • iMessage
    • FaceTime
    • Siri
    • iCloud
    • iCoud Keychain

And updated content in the previously existing System Architecture, Encryption and Data Security, Network Security and Device Access sections.

Posted on: 04 March 2014 at 08:33 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

25 February 2014

SANS 2014 Report on Application Security Programmes

The SANS Institute has published the results of a survey about application security programmes.

Partial screen capture of one of the charts from the SANS report 'Survey on Application Security Programs and Practices'

The researchers Jim Bird and Frank Kim stated the goals were to discover:

  • How widespread and mature application security programs are
  • Their effectiveness
  • What tools and practices are being utilised through the development lifecycle and which are most useful
  • How training is being undertaken and its effectiveness
  • How much is being spent on application security, where and whether this is aligned with organisational risk
  • What are the organisations' future plans for application security

488 respondents provided the data summarised in the report, with a quarter of these working in very large enterprises of more than 15,000 people and 39% from organisations with 1,000 or less people. 30% of respondents had development teams with less than 25 staff, and 6% had no developers at all, with all software development being outsourced.

The published report can be downloaded free of charge at SANS Survey on Application Security Programs and Practices.

The survey found that although organisations are investing more in application security, it is not particularly effective, and that root causes are not being addressed and instead there is still a reliance on mitigating software vulnerabilities after deployment. I recommend reading the findings and conclusions in full.

There was another document referenced in the report which I was not aware of. The US-based Financial Services Information Sharing and Analysis Centre has published a useful white paper titled Appropriate Software Security Control Types for Third Party Service and Product Providers to improve software security control practices.

Posted on: 25 February 2014 at 07:15 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

21 February 2014

Next Week at OWASP Manchester

Next Thursday I will be travelling to Manchester to present an introduction to the OWASP Cornucopia Project.

Early morning photograph of the sun rising through the mist from a train window, with the railway tracks and overhead wires in the foreground

The agenda for the OWASP Manchester meeting on Thursday 27th February 2014 is:

  • Hacking Eye-Fi Cards (Paul Johnston): Eye-Fi cards ingeniously embed a WiFi transmitter within an SD card. They are very convenient for transferring pictures from your camera to your computer. But are there hidden security risks?
  • OWASP Cornucopia (myself): Microsoft's Escalation of Privilege (EoP) threat modelling card game has been refreshed into a new version more suitable for common web applications, and aligned with OWASP advice and guides. OWASP Cornucopia - Ecommerce Web Application Edition will be presented and used to demonstrate how it can help software architects and developers identify security requirements from the OWASP Secure Coding Practices - Quick Reference Guide.

The meeting is open to everyone and is free to attend. Presentation content should be useful for coders, testers, software architects and development managers. The event is being held at KPMG's offices at St James Square, Manchester M2 6DS.

Prior registration is required. Please arrive from 18:00 hrs for an 18:30 hrs start; the meeting is expected to finish by 21:00 hrs.

Update 3rd March 2014: Very useful feedback to the presentation from the packed room at OWASP Manchester, which I will share via the Cornucopia mailing list. My presentation is available here.

Posted on: 21 February 2014 at 08:00 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

19 February 2014

OWASP CISO Survey Report Published

The report detailing results from the OWASP CIDSO Survey in 2013 has been published.

Cover from the OWASP CISO Survey and Report 2013, Version 1.0 - January 2014

The survey results report provides tactical intelligence on real-world application security, and complements the recent OWASP CISO Guide that describes how CISOs can act on this intelligence to achieve the optimal information security programs for their organisations.

The CISO survey report comprises:

  • Survey methodology
  • Objectives
  • Survey and report 2013
    • Threats and risks
    • Investments and challenges
    • Tools and technology
    • Governance and control
  • Conclusions
  • References

This is an excellent resource, largely due to the effort of OWASP board member Tobias Gondrom and the survey's participants, with generous assistance from Marco Marona, Stephanie Tan, and members of the former OWASP Global Industry Committee. Although I am kindly mentioned in the acknowledgements, I only made a minor contribution to this one.

The CISO Survey Project's activities and news are announced and discussed through a mailing list. It is also possible to register to receive email notifications about future releases and updates to the OWASP CISO Survey and related CISO projects.

Posted on: 19 February 2014 at 07:44 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

14 February 2014

Web Application Security Vulnerability Scanner Comparison 2014

Commercial and open source tools and services used to scan web applications for security vulnerabilities have again been assessed and compared.

Partial screen capture of the web application scanner price and feature comparison table, updated 6th February 2014

Shay Chen has undertaken an enormous re-assessment of 63 "black box" web application security vulnerability scanners.

The work, methodology, findings and analysis are extensively documented in Shay's own blog post The Web Application Vulnerability Scanners Benchmark. The assessment involved using a collection of 1413 vulnerable test cases spanning six different attack vectors (SQL injection, reflected cross-site scripting, path traversal/line feed injection, remote file inclusion, unvalidated redirects, presence of old, backup and unreferenced files).

There is a a lot of variation, and comparisons are difficult. Getting adequate coverage by tools of your own applications can be challenging, or at least time-consuming. And, despite the large amount of effort taken to perform this comparison, not all the vulnerabilities that could be present in your own web applications will have been tested in this exercise. Furthermore, you might have non-web applications to test as well.

I am not sure I can add anything to Shay's own extensive description of the research. Read his findings and draw your own conclusions.

Posted on: 14 February 2014 at 07:55 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

11 February 2014

Notes from Gamifiers London 05 Feb 2014

Gamifiers is a quarterly London meet up, for people who use, or want to use, gamification in their team, organisation, product or service.

As mentioned previously I attended the Gamifiers meet up on 5th February.

Photograph of Toby Beresford introducing the gamifiers meet up at IBM Southbank Client Centre on Wednesday 5th February 2014

Co-organiser Toby Beresford explained the morning's agenda and started the event by describing, and debating his own ideas about game rule maturity and the growth of tournaments and leagues. Andrzej Marczewski continued the introductory part mentioning the International Gamification Confederation (GamFed) and also some information from Gartner that "80% of gamified applications will fail". I challenged this by suggesting that "100% of Gartner reports state that 80% of something will fail/not succeed/are worse/etc".

An Coppens described her Master's work on using gamification in the recruitment process. She described how there is high staff churn in on-air planner roles for TV advertising. It is a high pressure role, generally with a lack of internal promotional route and in an industry that means there is often a poor candidate fit (i.e. the role attracts the wrong people), combined with being in a heavily regulated sector. An identified the types of skills and etiquette required to stay in the job for the 18 months needed to become proficient, and created a game to screen candidates that is fun to play, but includes real job-related metrics. The idea was subsequently implemented partially by one TV broadcaster, but the concept could be applied in other sectors.

Then Ed Cervantes-Watson described how Cancer Research developed Dryathalon to increase the charity's engagement with males, and to provide another fundraising channel. The website had an extremely high conversion rate to participants, but they discovered that the volunteers who were directly recruited and were given personalised motivation emails and badges, generated 40% more income than those that had signed up via other routes that did not provide these. Ed went on to present a new game called Genes in Space, which uses game player's eyes to help identify mutations in genome data that are then investigated in more detail by the charity's scientists. Gamers plot courses through obstacles without knowing they are actually reviewing genome data.

Peter Laughton gave an insight into current game design trends, which I have summarised below:

  • Move from landscape to portrait orientation
  • From (back from) thumb to index finger
  • Multiple currency support
  • Rise of downloadable content, to get people involved in your universe
  • Make the game for less money, $1million instead of $10million dollars
  • Interaction distance from 3m back to 30cm, playing on a tablet typically
  • Multiplayer rules more important
  • Fail fast, develop 10% first, if it works build rest

After a refreshment break, I presented the application security card game OWASP Cornucopia telling the story of how the idea emerged, how it was created, and events that transpired, including support from Blackfoot. I also described how it has been promoted through social media and at other events. We then had a game of cards using an example web administrative area as the subject of our attacks.

The comments and ideas while playing the games were tremendously helpful. The participants were neither software developers nor information security folk, so it was interesting to hear the views of people who are much more experienced gamifiers. I will write up the feedback and publish it on the public Cornucopia mailing list.

Thank you to IBM Southbank for providing the venue and refreshments.

Posted on: 11 February 2014 at 09:32 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

07 February 2014

S is for Security, Spelling and Snafu

On Tuesday a net-savvy citizen (aka a cyber warrior) spotted viruses emanating from the primary NHS website NHS Choices.

A spokeswoman said a simple misplaced letter s in a domain name embedded in the code was responsible. A developer had typed googleaspis.com instead of googleapis.com

The news spread virally (i.e. was copied) by the mainstream press (e.g. here, here, here, here, etc) with good analysis and comment here).

It seems JavaScript was being loaded from "translate.googleaspis.com" rather than "translate.googleapis.com" and it had gone unnoticed for months, until a foreign rogue (aka hacker) registered the domain name and wrote a bit of code to modify the NHS Choices web pages so that links redirected to sites serving malware.

Said to be due to a "internal coding error", it sounds more like a case of missing functional testing, missing security testing, poor change control and inadequate operational monitoring (as well as the typo).

Apart from doing things professionally, as the news story in Info Security asks, why have third-party hosted code on the site at all? It's not as if anyone missed the functionality that didn't work.

Posted on: 07 February 2014 at 06:47 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

04 February 2014

Smart Grid Threat Landscape and Good Practice Guide

The European Union Agency for Network and Information Security (ENISA) has announced the publication of a new report on smart grid threats and good practices.

Smart grid asset mindmap from the ENISA report 'Smart Grid Threat Landscape and Good Practice Guide'

Smart Grid Threat Landscape and Good Practice Guide describes and enumerates smart grid assets, threats, vulnerabilities and good practices. the good practices are presented for two categories — firstly IT systems and logical networks, and secondly the supply chain.

I almost did't mention this report here, but there is some information about software assets, threats and vulnerabilities. So if smart grid is your thing, the report may be useful. The threat model presentation may be useful in other contexts.

Posted on: 04 February 2014 at 08:46 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Integrity Security Principle : Web Security, Usability and Design
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Requested by on Wednesday, 16 April 2014 at 18:05 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2014 clerkendweller.com