18 May 2015


Posts relating to the category tag "standards" are listed below.

12 August 2014

Application Security Verification Standard 2.0

Application Security Verification Standard (ASVS) for web applications version 2.0 has been published by OWASP. The ASVS standard provides a basis for verifying application technical security controls, as well as any technical security controls in the environment that are relied on to protect against application security vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection.

Partial view of a page from the OWASP Application Security Verification Standard 2.0

ASVS Web Application Standard 2.0 has been comprehensively reviewed, reassessed and updated primarily by Sahba Kazerooni, Daniel Cuthbert, Andrew van der Stock and Krishna Raja, along with a dozen or so other contributors and reviewers.

The standard can be used to define application security requirements based on an assessment of risk, and to assist application security verification activities. Three new classes of requirement have been defined that did not exist in the previous 2009 edition:

  • V15 Business Logic verification requirements
  • V16 Files and Resources verification requirements
  • V17 Mobile verification requirements.

Furthermore, the following classes no longer exist, to focus on the application requirements, and also due to the merging of encoding/escaping within the input validation section:

  • V1 Security Architecture documentation requirements
  • V6 Output Encoding/Escaping verification requirements
  • V12 Security Configuration verification requirements
  • V14 Internal Security verification requirements.

For organisations already using the previous version, the numbering of matching requirements has not changed, but it does mean that there are also new requirements within each section, and some gaps in numbering where a previous requirement has been removed.

The standard defines verification requirements for three levels of verification, labelled opportunistic, standard and advanced. Appendix A of the document provides some example scenarios for the ASVS level that might be used for different industry sector.

If you have only read the OWASP Top 10, ASVS should be your next read. Expect to see mappings from ASVS 2.0 to the OWASP Testing Guide.

Posted on: 12 August 2014 at 17:38 hrs

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

20 June 2014

CBEST Threat-Led Penetration Testing for UK Financial Services Sector

The Bank of England announced a cyber security penetration testing framework earlier this month.

Partial view of the CBEST logo on the cover of the open source  CBEST Implementation Guide

The CBEST threat intelligence-led cyber security testing framework for financial institutions was revealed by Andrew Gracie (Executive Director, Resolution, Bank of England) speaking at the British Bankers' Association Cyber Risk Conference on 10th June. The scheme is backed by accreditation standards for threat intelligence and penetration testing.

The framework was developed in conjunction with Her Majesty's Treasury, and the Financial Conduct Authority, vendor Digital Shadows and impartial vendor-led accreditation quango CREST. There are a good range of CBEST-related quotations on Bob's Guide, some comment at The Register, a short description on the Digital Shadows web site, and CREST also outlines the framework. CREST lists additional documents which can be obtained under a non disclosure agreement (NDA).

The following open source documents, licensed under the Creative Commons Attribution 4.0 International Licence, have been published on the Bank of England website:

The name CBEST does not appear to be an abbreviation or acronym of anything in particular, other than perhaps a simple modification of the word CREST.

Posted on: 20 June 2014 at 10:34 hrs

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

10 June 2014

PAS 754 on Software Trustworthiness

Publicly Available Specification (PAS) 754 - "Software Trustworthiness - Governance and management - Specification" has been launched at an event at the BIS Conference Centre in London today.

Photograph of the blue display screen on a cash ATM showing the words 'Please take your card and try again later - DO NOT ENTER YOUR PIN' written in white text

The Trustworthy Software Initiative (TSI) is funded by the UK Government as part of the National Cyber Security Programme and is sponsored by BIS and CPNI. It aims to improve the trustworthiness of software. It has created educational materials for use by colleges and universities to promote the concept of software trustworthiness to their students.

PAS754 is built around five aspects of software trustworthiness: safety, reliability, availability, resilience and security.

Further details on the TSI website and the PAS itself can be bought from the BSI Shop for £55. I have a copy ordered and will blog again on receipt.

Posted on: 10 June 2014 at 16:02 hrs

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

03 June 2014

Personal Data Protection in Online Systems - Part 2/2 Security Controls

Yesterday I described the new report from the ICO, Protecting Personal Data in Online Services: Learning From the Mistakes of Others. Below is a list of the matching security controls for each issue mentioned in the report.

Examining the ICO report in greater detail, provides additional clues about the requirements expected in each class of vulnerability. The report "is not aimed at experienced security professionals", but rather at those responsible for the security of the online systems, and hopefully this list will be useful to those individuals.

My breakdown of the matching security controls, based on my interpretation of the report's text, are listed below.

Issue from ICO Security Report Derived Security Controls
Failure to keep software security up to date
  • Create and maintain a policy for software patching
  • Maintain a list of all software, including components (e.g. third-party libraries, frameworks), their versions, source and method of monitoring for security patches and other updates
  • Define who is responsible for the patching of each software component
  • Create, use and maintain a procedure for assessing security patches and other software updates, that includes a risk assessment
  • Apply software security patches in a timely manner
  • Do not use software that is no longer supported by the supplier/vendor/development company; or limit its use and undertake a risk assessment and apply additional controls
  • Create, maintain and operate a process for checking that security patches have been applied to all software components, or those that have not been applied have adequately justified, documented and applied mitigating controls
Lack of protection from SQL injection
  • Create and maintain a process for other people and organisations to report security issues about your applications
  • Create and maintain a procedure for assessing and fixing security flaws in custom application code, and include these issues in the software patching documentation (see above), and if SQL injection is found in one place, examine similar code elsewhere
  • Identify who is responsible for preventing SQL injection in each custom coded application (e.g. software such as websites developed by/for the organisation)
  • Require the default to be to use the safest server-side method for database queries supported by the API or framework
  • Ensure the prevention, detection and remediation of SQL injection vulnerabilities are included at multiple stages of the software development lifecycle (e.g. coding standards, peer/independent code review with audit trail, automated code review, automated vulnerability assessment, penetration testing before going live)
  • Use the software patching policy and processes (see above) for software components used by the custom applications
  • Include a requirement in contracts with third party development to build security into their development practices and inform you when they become aware critical vulnerabilities like SQL injection, and then provide patches
  • Use automated application vulnerability assessments (scanning) to help identify SQL injection, but ensure these cover all the application (e.g. for authenticated customers and administrators too)
  • Undertaking penetration testing in the production/live environment of custom-built applications (external and internal-facing) that interact with databases and other data stores, and repeat periodically
Exposure of unnecessary protocols & services
  • Do not use insecure protocols such as Telnet and plain FTP
  • Implement access control for all protocols (e.g for secure FTP disallowing anonymous access, preventing SMTP being used as an open relay)
  • Use firewalls to prevent external access to internal services
  • Remove, disable or block un-necessary services (see also decommissioning below)
  • Limit remote access to trusted IP addresses and enforce access using an encrypted method
  • Segment services so that a compromise of one does not lead to wider system compromise
  • Consider using a Virtual private Network (VPN) using strong credentials (such as two-factor authentication) for all remote access
  • Scan ports of all system components periodically to verify that only the intended services are available externally, internally, and from particular other locations
  • Document and periodically review all the services allowed
Exposure of decommissioned software/services
  • Maintain a schedule of all software/services in use
  • Ensure all system components (hardware, software, configuration files, databases, files, services, ports, DNS records, etc) are decommissioned when no longer needed, and maintain a record of how this was undertaken
  • Test/audit that decommissioned components no longer exist and cannot be accessed
  • For hardware disposal, ensure data is securely removed
Insecure storage of passwords
  • Create and maintain a password policy for all types of system users
  • Encourage, and allow, users to choose stronger passwords
  • Discourage users from having the same password on multiple systems
  • Discourage or prevent commonly used passwords
  • Never store or send passwords in plain text
  • Never encrypt passwords unless there are extremely robust key protection and key management processes in place
  • Use one-way hashing of passwords with a long salt value, unique for each user
  • Use a hashing method that is slow (e.g. PBKDF2, bcrypt or scrypt)
  • Do not use weak hashing methods such as MD5 or SHA-1
  • Review hashing best practice periodically, and build in considerations to allow future changes to the hashing method
  • Ensure password breaches are included in incident report planning
Failure to encrypt online communications
  • Identify and record all information that should be encrypted in transit
  • Ensure the encryption method (e.g. SSL/TLS) is configured correctly and that certificate are valid
  • Maintain a list of all certificates and ensure they are renewed before expiry
  • Consider using Extended Validation (EV) digital certificates to provide a higher level of identity assurance to users
  • Do not use SSL v2, and preferably enable TLS 1.2), disable weak ciphers (i.e.enable ciphers with 128 bi strength or greater) and avoid weak ciphers (e.g. RC4) or those that provide no encryption or no authentication i.e. null ciphers)
  • Ensure the information cannot be accessed without encryption
  • When web pages are sent over SSL/TLS, ensure every single component in the page (e.g. images, style sheets, scripts and third-party hosted content) is also sent over SSL/TLS
  • Never send session identifiers (e.g. cookies identifying an authenticated user) over unencrypted connections
  • Ensure SSL/TLS websites are only accessible by hostnames included in the certificate, and not by IP address)
  • Consider making websites completely "SSL/TLS only
  • Review transport encryption best practice periodically and update configurations as required
Processing data in inappropriate locations
  • Identify and maintain an inventory of all locations where personal data is stored, processed and transmitted
  • Do not allow unauthorised access (e.g. public access) to personal data
  • Do not use production data in development and test systems
  • Incorporate personal data access into systems design processes
  • Use network segmentation to assist with limiting access to personal data (e.g. segregate non production systems, segregate teams or departments with access to sensitive personal data)
  • Use redundancy/diversity to protect against accidental loss or destruction of, or damage to, personal data
  • Create and maintain policies for the storage, processing and transmission of personal data
  • Create, maintain and use procedures for transfers of personal data
  • Do not place copies of personal data in unprotected locations
  • Enforce appropriate access control in custom applications (e.g. websites)
  • Provide training about the access, use and transfers of personal data
  • Monitor transfers of personal data
Use of default credentials including passwords
  • Change all default passwords across all system components
  • Disable or remove guest and demonstration accounts
  • Use strong passwords to replace default ones (see above)
  • Avoid hard coding of access credentials (and never in software code), but use encryption if possible if necessary to store elsewhere (e.g. configuration files)

So, not such a short list. It is a combination of technical, administrative and physical controls, and not just applicable to online systems, but all electronic systems that store, process and transmit personal data, and generally regardless of whether it is sensitive personal data or not.

Posted on: 03 June 2014 at 07:48 hrs

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

02 June 2014

Personal Data Protection in Online Systems - Part 1/2 Security Vulnerabilities

The UK's Information Commissioner's Office (ICO) published a report in mid May about the most common classes of IT security vulnerabilities in online systems that result in failures to secure personal data.

The cover from the ICO report

The seventh data protection principle requires organisations to take appropriate measures to safeguard personal data. It states "Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data".

Protecting Personal Data in Online Services: Learning From the Mistakes of Others describes the issues most commonly found to have been the root causes of inadequate protection of personal data in online systems.

There are some issues clearly related to poor management control such as incorrect decommissioning of business processes and inappropriate locations for processing of data. The other issues are more technical but are all the types of things well-organised and careful organisations ought to be getting right already.

I was interested to check which of these relate to infrastructure (I/S) components and which to applications (Apps). For the latter, also whether the latter appear in the OWASP Top Ten most critical risks.

Issue ICO Security Report Component OWASP Top Ten 1013
I/S App
Failure to keep software security up to date Y Y A9 Using components with known vulnerabilities
Lack of protection from SQL injection Y A1 Injection
Exposure of unnecessary protocols & services Y - -
Exposure of decommissioned software/services Y Y - -
Insecure storage of passwords Y A6 Sensitive data exposure
Failure to encrypt online communications Y Y A6 Sensitive data exposure
Processing data in inappropriate locations Y - -
Use of default credentials including passwords Y Y A5 Security misconfiguration

We can see there is a mixture of infrastructure and application security issues, and that some issues span both of these categorisations.

Simon Rice, ICO Group Manager, blogged about the release of the report, password storage, SQL injection, and answers questions about the report in a video interview.

Tomorrow, I will list the security controls for each issue, as discussed in the report.

Posted on: 02 June 2014 at 07:40 hrs

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

30 May 2014

Cloud Security Guidance from HM Government

The UK government's National Technical Authority for Information Assurance (CESG) has updated its guidance on cloud security.

Screen capture of the gov.uk cloud security guidance collection published by CESG

Cloud security guidance was updated this month and now includes:

The principles and new risk management guide are intended for public sector organisations to help them understand and manage the risks associated with cloud services. The implementation guide outlines different approaches that can be taken to meet the individual security principles and explains the risks associated with each.

These may also be of use for non public sector organisations.

Posted on: 30 May 2014 at 07:28 hrs

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

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 (2) | Permalink | Send Send | Post to Twitter

07 March 2014

PCIDSS SAQ A-EP and SAQ A: Comparison of Eligibility Criteria

In my previous post I summarised the new SAQ A-EP self-assessment questionnaire for PCIDSS e-commerce merchants with a partially outsourced payment environment.

SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

I have compared the eligibility criteria for SAQ A (versions 2.0 and 3.0) and SAQ A-EP (version 3.0 only). In the table "Y" indicates the criteria is included in the SAQ. The criteria text is taken from PCIDSS v3.0 and matched to v2.0 where necessary, except for the two v2.0-only criteria.

The criteria ordering is mixed up slightly to place similar criteria adjacent to each other.

To continue using SAQ A for a hosted payment page (HPP), the clues are in the criteria below. Using a direct order post, where the payment form is hosted by the merchant but submits to the third party payment provider, is clearly SAQ A-EP. But it seems IFRAMEs (HPP within a merchant's page) and redirects to a payment form on the payment provider's systems will still be eligible for SAQ A. Further guidance from the PCISSC, payment brands and acquirers might clarify this.

PCIDSS Self-Assessment Questionnaire (SAQ) Eligibility Criteria v2.0 v3.0
Merchant does not store, process, or transmit any cardholder data on merchant systems or premises but relies entirely on third party service provider(s) to handle these functions; Y
Merchant does not electronically store, process, or transmit any cardholder data on merchant systems or premises, but relies entirely on a third party(s) to handle all these functions; Y Y
Merchant has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and Y Y Y
Merchant does not store any cardholder data in electronic format; [and] Y
Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically. Y Y Y
Merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions); Y
Merchant accepts only e-commerce transactions; Y
All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers; Y Y
Merchant has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored; Y
Additionally for e-commerce channels: The entirety of all payment pages delivered to the consumer's browser originates directly from a third party PCI DSS validated service provider(s). Y
Merchant's e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor; Y
Merchant's e-commerce website is not connected to any other systems within merchant's environment (this can be achieved via network segmentation to isolate the website from all other systems); Y
If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider); Y
All elements of payment pages that are delivered to the consumer's browser originate from either the merchant's website or a PCI DSS compliant service provider(s); Y
Total Number of Criteria 4 7 9

Continue to a comparison of the questions in the three SAQs.

Posted on: 07 March 2014 at 15:22 hrs

Comments Comments (4) | 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 (1) | 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

More Entries

Standards : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by on Tuesday, 1 December 2015 at 07:24 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 https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk