Brian Pennington

A blog about Cyber Security & Compliance



PCI Security Standards Council publishes card production security requirements

The PCI Security Standards Council (PCI SSC), has announced the publication of a standard for secure payment card production.

The standard consists of two sets of requirements:

  1. PCI Card Production Physical Security Requirements
  2. PCI Card Production Logical Security Requirements

Together, these documents provide card vendors with a comprehensive source of information describing the security requirements to follow for card production activities including card manufacture, chip embedding, magnet-stripe encoding, embossing, card personalization, chip initialization, chip personalization.

Formerly managed as separate requirements by each payment card brand, the Council aligned these requirements and solicited feedback from the PCI community to produce one set of criteria recognized across the industry. The resulting standard is designed to secure the components and sensitive data involved in the production of payment cards and protect against the fraudulent use of card materials.

It’s broken down into two core areas:

  1. Physical security requirements – for all card vendors, these requirements address the presence, movement, and accountability of a card, including tangible features such as the security of the premises, personnel access to secure areas, and CCTV surveillance.
  2. Logical security requirements – for card personalization vendors, these requirements address threats to the confidentiality of personalization data during data transfer, access, storage, and destruction; and all aspects associated with cryptographic key management, including the protection of issuer keys used in the personalization process.

The security requirements are available for immediate download here. Vendors should work with the individual card brands to confirm timing for when future security reviews must be performed against the new PCI Card Production Security Requirements.

In line with other PCI Standards, the requirements will be updated on a three-year lifecycle, based on feedback from the PCI community.

There are a lot of pieces involved in securely producing payment cards, from design all the way through delivery,” said Bob Russo, general manager, PCI Security Standards Council. “The publication of these requirements gives card vendors one set of criteria to follow, and as we’ve seen with our other standards, will help drive improved security across the payments chain

Merchants are complacent about PCI DSS, report reveals.

Verizon logo
Image via Wikipedia

Verizon have launched their 2011 Payment Industry Compliance Report which draws on their experiences as a QSA company and previous annual reports.

Extracts from the report are below.

Unchanged from last year, only 21 % of organizations were fully compliant at the time of their Initial Report on Compliance (IROC). Verizon commented with “This is interesting, since most were validated to be in compliance during their prior assessment”.

  • Organizations met an average of 78% of all test procedures at the IROC stage
  • 20% of organizations passed less than half of the DSS requirements
  • 60 % scored above the 80 % mark

Organizations struggled most with the following PCI requirements:

  • 3 (protect stored cardholder data)
  • 10 (track and monitor access)
  • 11 (regularly test systems and processes)
  • 12 (maintain security policies).

The PCI Requirements showed the highest implementation levels were:

  • 4 (encrypt transmissions over public networks)
  • 5 (use and update anti-virus)
  • 7 (restrict access to need-toknow)
  • 9 (restrict physical access)

Organizations do not appear to be prioritizing their compliance efforts based on the PCI DSS Prioritized Approach published by the PCI Security Standards Council even less so than in the previous year.

A mini-study comparing governance practices to the initial compliance score suggests that the way organizations approach compliance significantly factors into their success.

Once again, organizations that suffered data breaches were much less likely to be compliant than a normal population of PCI clients. Analysis of the top threat actions leading to the compromise of payment card data continues to exhibit strong coverage within scope of the PCI DSS. For most of them, multiple layers of relevant controls exist across the standard.

In the pool of assessments performed by Verizon QSAs included in this report

  • 21% were found fully compliant at the completion of their IROC
  • This is just 1% less than in their last report, and effectively the same number

The lack of change is a disappointing, as many in the industry were hoping to see an increase in overall compliance as the PCI DSS became more familiar to an increasing number of organizations.

79% of organizations were not sufficiently prepared for their initial assessment

Having established that only 21% “passed the test” the next question becomes “what was their score?”

  • On average, organizations met 78% of all test procedures defined in the DSS at the time of their IROC.
  • Down 3% from Verizon’s last report; but again, the difference is nominal.

Therefore, the baseline set by the PCI DSS must not reflect the baseline set by the companies themselves. For most organizations, to achieve compliance they must do things they were not previously doing (or maintaining).

Another common Achilles heel of merchants and service providers in the PCI assessment process is over confidence

 “It was painful, but we made it through last year, so this year should be a breeze”

is a typical sentiment with which many organizations approach the yearly assessment. That can be a costly mistake. When the QSA arrives on-site, a mere 1/5th of businesses are found to be compliant, even when given the extra time between the on-site visit and completion of the IROC.

Complacency and fatigue are two additional drags that make maintaining compliance year over year difficult. Too many businesses approach PCI from the point of view that “what was good enough last year will be good enough this year.” But unless someone’s been babysitting a process, such as documenting and justifying all services allowed through the firewalls, things can easily be forgotten in the haste to get business done.

When examining the percentage of organizations passing each requirement at the IROC phase.

  • Some requirements show percentages dipping below 40%, while others exceed the 70% range.
  • Six of the twelve show an increase over last year, and the average is up two points.
  • However, the average number of test procedures met within each requirement is down 4%.
  • None of these numbers is indicative of a clear change given the size and makeup of the dataset, but it certainly reinforces the notion that
  • organizations continue to struggle (at varying degrees) in all areas of the DSS.

How do organisations perform against the 12 Requirement? The four highest rated Requirements are:

  • 4 (encrypt transmissions)
  • 5 (AV software)
  • 7 (logical access)
  • 9 (physical access)

Requirement 10 (tracking and monitoring) boasted the highest gain+13 %

Requirement 5 (AV software) may lose its place in the top three, which is an odd development, since AV software has for so long been among the most basic and widespread of security controls.

Requirement 4 (encrypt transmissions) showed a marked improvement which may indicate that administrators are deciding it’s easier to direct all Internet traffic containing credit card data over SSL.

Requirement 7 (logical access) showed a slight improvement, which could mean more strict attention is being paid to who is given access to cardholder data.

Requirements 3 (stored data) and 11 (regular testing) are once again in the bottom tier, while Requirement 12 (security policies) ousted 10 (tracking and monitoring) from the bottom. This suggests that the encryption of data at rest continues to be a major headache for organizations, especially the more detailed portions, such as annual key rotations.

Requirement 11’s low showing reminds us why ‘set and forget is a very bad bet’ should be a core mantra of the security profession. The fact that security policies rank among the lowest of the low is not a good sign since policy drives practice.

Requirement 1 remains virtually unchanged since last year, at 44% compliance, compared to the 46% in the last report. Only 63% of companies met Requirement 1.1.5 regularly

Compliance is the continuous state of adhering to the regulatory standard. In the case of the PCI DSS there are daily (log review), weekly (file integrity monitoring), quarterly (vulnerability scanning), and annual (penetration testing) activities that an organization must perform in order to maintain this continuous state of compliance

The entire report can be found on the Verizon web site here.


Could you save 50% on the cost of your Firewall Change Requests?

Tufin, a “Security LifeCycle Management solutions company” claim that with effective Firewall change management a business could reduce the cost of its Firewall management by 50%.

Tufin use research from Frost and Sullivan to support their claim.

Frost & Sullivan reports that “The process of implementing a change request to a firewall is a combination of many tasks that are in most cases manual, unclear and time-consuming. [Tufin] SecureChange TM Workflow automates the request process, substantially reducing the overall IT costs associated with change requests by half annually.”

What is undeniable is the need for effective change management processes and controls for Firewalls if a Firewall, or any other security solution, is to remain efficient and secure.

Firewall change management is a mandated requirement in several legislative and compliance standards, for example the Payment Card Industry Data Security Standard (PCIDSS) has a list of specific controls that should be in place and should be provable, a sample list from the standard is below:

1.1 Obtain and inspect the firewall and router configuration standards and other documentation specified below to verify that standards are complete. Complete the following:

1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.

1.1.2.a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all connections to cardholder data, including any wireless networks.

1.1.2.b Verify that the diagram is kept current.

1.1.3.a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1.1.3.b Verify that the current network diagram is consistent with the firewall configuration standards

1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.

1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service.

1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.

1.1.6.b Obtain and examine documentation to verify that the rule sets are reviewed at least every six months.

1.2 Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:

1.2.1.a Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

1.2.3 Verify that there are perimeter firewalls installed between any wireless networks and systems that store cardholder data, and that these firewalls deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to determine that there is no direct access between the Internet and system components in the internal cardholder network segment

1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). (Only established connections should be allowed in, and only if they are associated with a previously established session.)

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization’s network, have personal firewall software installed and active.

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers.

6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows:

  •  Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
  •  Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.

The day to day operation of a business can mean “quick changes” are made to firewalls and other security solutions and are not be recorded but could significantly impact on the businesses security level and the organisation’s ability to maintain compliance.

A spreadsheet could be an answer but configuration changes often involve several tasks, for example testing the change prior to going live. Changes across multiple devices may involve several people as security devices need highly skilled security professionals to manage them. Without an effective process or solution an organisation could be wasting the time of expensive resources and may incur unexpected and costly downtime.

To meet these challenges in a cost-effective manner, Tufin recommends that organizations need to extend IT automation into the domain of network security configuration. Automating the security change lifecycle can help companies to: 

  • Improve network security and uptime
  • Enforce corporate governance
  • Manage risk effectively and proactively
  • Increase operational efficiency
  • Comply with industry and regulatory standards
  • Audit security infrastructure quickly and accurately
  • Improve service levels

Tufin believe the key to effective security change automation solution is a combination of both workflow and security technologies. Generic ticketing and helpdesk systems can route requests to security administrators, but since they have a limited understanding of security processes and compliance policies, they cannot automate and enhance each of the stages in a configuration change, from request and design, through implementation and auditing. A comprehensive security change automation solution will work either alone, or in concert with a standard ticketing system, to provide: 

  • Multiple, customizable change workflows tightly coupled with security and network infrastructure, directory services and compliance policies
  • Automated, proactive risk and compliance analysis as an integral part of the change process
  • Configuration change advisory and automatic verification to reduce the risk of errors and shorten ticket resolution time
  • Separation of duties and enforcement of IT governance
  • A comprehensive audit trail with integrated reporting
  • SLAtracking and high-level monitoring tools to ensure continuous improvement 

The security change lifecycle represents a holistic view of an organization’s security configuration change processes.

A typical security change lifecycle could include the following stages: 

Request: A business user requests a service, most commonly access to an application or network, or IT requests connectivity changes for a new or modified server or application. 

Business Approval: The request is sent for approval to an IT manager to ensure that it is justified. 

Technical Design: An engineer translates the request from its business context into a specific implementation plan on the affected firewalls or devices. 

Risk Analysis: A security manager performs risk analysis and checks the change for compliance. 

Implementation: The change is actually implemented on the network infrastructure by one or more administrators. 

Verification: The user checks that his/her request has been fulfilled. At this stage, a manager can also verify that the implementation was in accordance with the approved design. 

Audit: Periodically, all changes must be audited in order to demonstrate sufficient security levels and compliance with standards. 

Other firewall solutions are available from companies like Firemon and many Firewall vendors have introduced their own solutions for example Check Point. 

Download the Tufin White Paper here.


90 Percent of Businesses Fell Victim to a Cyber Security Breach

The Ponemon Institute has released the the results of a study conducted to determine what IT and IT security practitioners in the US, UK, France and Germany think about how well their organizations are responding to threats against network security. Sponsored by Juniper Networks, they believe the research is important because “it can provide insights from those who are dealing daily with the prevention and detection of these attacks. Specifically, what do they think about the current threat landscape and what are the most effective strategies to keep networks secure”.

Some of the topics addressed include:

  • Are threats to network security increasing in frequency and sophistication?
  • Is their organization’s IT infrastructure secure enough to prevent successful attacks?
  • What is the nature of the attacks and are the attackers and attack vectors known?
  • Do organizations see complexity as a barrier to effective enterprise-wide network security?

They surveyed 583 IT and IT security practitioners in there US with an average of 9.57 years of experience. More than half (51 percent) are employed by organizations with more than 5,000 employees.

The study found the number of successful network security breaches over the past 12 months were:

None 10%
1 time 21%
2 to 3 Times 32%
4 to 5 Times 18%
More than 5 times 9%
Cannot determine 10%

Some of the most salient findings are as follows:

The financial impact of a security breach can be severe. According to 41% of respondents, the financial impact of these breaches was $500,000 or more. However, 16% cannot determine the amount. Respondents were asked to consider cash outlays, internal labor, overhead, business disruption, revenue losses and other expenses.

Security breaches most often occur at off-site locations but the origin is not often known. Mobile devices and outsourcing to third parties or business partners seem to be putting organizations at the most risk for a security breach. 28% say the breaches occurred remotely and 27% say it was at a third party or business partner location.

Attacks are coming from external agents but insider abuse is prevalent. External agents and insiders (employees) are most commonly behind the security breaches according to 55% and 49% of respondents, respectively. Respondents also report that multiple sources can be blamed for the breaches.

Employee mobile devices and laptops are seen as the most likely endpoint from which serious cyber attacks are unleashed against a company. 34% of respondents say attacks occurred from infected laptops or remotely due to an employee’s insecure mobile device. Further, the top two endpoints from which these breaches occurred are employees’ laptop computers (34%) and employees’ mobile devices (29%). 28% say it is employees’ desktop computers.

Complexity and availability of resources are the most serious challenges to combating cyber attacks. 48% cite complexity as one of their biggest challenges to implementing network security solutions. The same percentage of respondents 48% says it is resource constraints. These challenges are followed by lack of employee awareness, which contributes to the insider risk. In addition to simplifying their security operations and increasing available resources, organizations should consider the importance of training and awareness.

Attacks are becoming more frequent and severe. IT practitioners in the study are worried about continuing and more serious attacks. 78% of respondents say there has been a significant increase in the frequency of cyber attacks during the 12 months, and 77% say these attacks have become more severe or difficult to detect, or contain.

Given the current threat landscape, organizations should make prevention and detection of security breaches a primary focus. Only 32% of respondents say their primary focus or approach to network security is on preventing attacks. 16% say it is on fast detection and containment and 15% say it is on network intelligence. 23% say their network security strategy is to baseline their approach against best practices and 14% say it is IT governance.

Ponemon’s Conclusions

They believe their research provides evidence that many organizations are lacking the right strategy to prevent cyber attacks against networks and enterprise systems. Their study suggests conventional network security methods need to improve in order to curtail internal and external threats.

They believe organizations should consider incorporating the following recommendations in their network security strategy:

  • Understand the risk employees’ mobile devices create in the workplace. In addition to problems created when inappropriately being connected to the network, breaches involving lost or stolen laptop computers or other mobile data-bearing devices remain a consistent and expensive threat. According to Ponemon Institute’s 2010 Annual Cost of a Data Breach Study, 35 percent of organizations report that a lost or stolen mobile device caused the data breach they experienced.
  • Create a comprehensive policy (including detailed guidelines) for all employees and contractors who use mobile devices in the workplace. The policy should address the risks associated with each device and the security procedures that should be followed. Guidelines can range from such topics as to what types of data should not be stored on these devices, how to determine if an application can be safely downloaded and how to report a lost or stolen device.
  • Improve ability through expertise and enabling technologies to detect and prevent breaches. Understanding the source of the breaches can help organizations strengthen their cyber security strategy.
  • Address the insider threat through the creation of an enterprise wide security policy that includes the responsibilities of employees to help protect network security. The policy should be easily accessible. In addition, there should be a training and awareness program to ensure employees understand the various risks to the network and how they can contribute to preventing security breaches.
  • Complexity is recognized as a barrier to effective network security strategy. Organizations should assess their current procedures and technologies to understand how best to streamline their approach and have an end-to-end (holistic) approach to network security. The studies consistently show that the cost of cyber attacks is increasing. Reducing an organization’s vulnerability to such attacks through the combination of proper staffing, enabling technologies and training programs can help prevent the pattern of multiple breaches experienced by so many in our study.

The full study can be downloaded here


How to Secure Mobile Devices

Drew Robb in his article ” How to Secure Mobile Devices” has created an excellent guide to thinking about the security of mobile devices, not just for consumers but for the enterprise.

The article is recreated below:

“More and more frequently, employees are linked to sensitive data via a number of different devices, providers, and operating systems,” said Will Hedrich, a security architect at CDW-G. “If laptops, tablets, and smartphones are left unattended for even a few minutes, you are at risk.”

Anyone can download an application for $50 to $150, for example, that will allow them to listen to phone conversations, listen to anything around that phone even when it’s not on a call, view the camera, swipe files from the phone, or access the corporate network. They can download, view, or listen to this information wirelessly using the phone’s public IP address, Bluetooth or Wi-Fi. After the program is downloaded on to it, the person would never know it is on his or her phone.

Recently, for example, an employee of a large enterprise left a smartphone in the car while shopping. The phone, which was stolen, contained the social security numbers and other personal information of company employees. Because the phone was not equipped with any security measures, the information was easily accessed.

Most company employees do not even have basic firewall or password protections on their phones, so they are risking this kind of data loss on a regular basis.

The financial consequences can be severe. The government fines companies $204 or more per piece of personal information leaked, such as a social security number, credit card information, and other personally identifiable information (PII) or payment card industry (PCI) compliance information.

“It is important to have a mobile management security strategy in place to prevent data loss and malicious attacks,” said Hedrich. “The strategy should extend to devices, the data center, and cellular carriers.”

He added that a comprehensive solution for locking down the mobile workforce did not exist until recently. Such solutions, now becoming available from a variety of vendors, should encompass a four-pronged approach.

Physical security

Devices accessing the network need data encryption and multi-factor authentication, which includes a user name, password, and a series ofPINnumbers, such as a four digit personalPINand a six digit code that is generated automatically and changes every minute. Device certificates are also important.

Content security

If appropriate security protocols are in place, anyone trying to access information via the public IP address of an encrypted device will find that the information is completely scrambled. A combination of anti-malware, content filtering, encryption, data loss prevention (DLP) software, and intrusion prevention software installed on all devices will prevent unauthorized access to data.

“If a phone, tablet, or other device falls into the wrong hands, you want to be sure that data on it cannot be accessed,” said Hedrich. “Data encryption and multi-factor authentication are crucial to ensuring that only the authorized user can access the information on the device.”

Device management

Organizations should also set access levels and permissions for each person or group on the network, such as legal, marketing, IT, etc. These access policies control the data they can access via their devices and the functions they can perform remotely.

“Centralized device management allows IT to update access rights as well as roll out updates to operating systems and applications from one central console,” said Hedrich. “And, if a device is lost or stolen, the IT manager can wipe the device remotely to prevent data loss.”


Call Centre Security and PCI Compliance

An Indian call center
Image via Wikipedia

Credit Card data is the Crown Jewels for hackers and the financial lifeblood of many companies. An Account Data Compromise, also known as a breach can lead to bad press and a bad reputation, you only need to Google or Lush to see the impact.

With the 18th March 2011 launch of the PCI Councils “Protecting Telephone Based Payment Card Data” on Call Centres it is worth noting that, according to research from Connected World 36.7% of contact Centres claimed to be fully compliant with the Payment Card Industry Data Security Standard (PCI DSS).

However, the majority (89%) admitted to not understanding PCI DSS, the requirements nor penalties.

There are many business and regulatory requirements that impact Call Centres, especially the recording of telephone calls, for example in the United Kingdom, the Financial Services Act.

The act of recording a call can break the rules of PCI DSS as most calls will involve the recording of ALL the data. Data such as, CAV2, CVC2, CVV2 or CID, which should never be recorded. Storing the PAN and Expiry data is acceptable so long as the data is encrypted and the Merchant has acted on all the questions within SAQ D or undertaken a formal Audit if they are a level 1 Merchant.

The number one piece of advice for Call Recording is DO NOT DO IT unless you really have to.

However, the recording of the calls and storing of Credit Card Data in an encrypted format are small parts of the issue facing Call Centres.

By considering the following points and reviewing the documents on the PCI Resource page  you can go a long way towards achieving a PCI compliant Call Centre.

  • Employee vetting is the first step in ensuring a secure Call Centre.
  • There needs to be a formal employee induction programme where employees learn about the company’s policies (rules) and the ramifications of breaching the policies.
  • Specifically, there needs to be a documented Policy on how employees handle Calls and Data resulting from the Calls, especially Credit Card Data?
  • The Merchant needs to communicate the Policy to all employees that have access to Credit Card Data.
  • Do employees regularly receive training on the Policy and its importance? They should do.
  • Are employees made aware of their IT Security responsibilities?
  • Security Awareness training needs to be provided, for example, how to deal with the threat of computer viruses, how to report suspicious activity, etc
  • Security Awareness has to be promoted, for example, on posters and in newsletters.
  • Do supervisors/managers enforce a clear desk Policy? For example, no MP3 players, no note pads or any other methods to record information.
  • Access to photocopiers and scanners needs to be restricted.
  • Restricting physical access to the Call Centre should be considered.
  • Call Centres should be restricted to employees only and visitors need to be escorted.
  • All paperwork leaving the Call Centre should be shredded to avoid the unnecessary risk or Personally Identifiable Information (PII) finding its way into the public domain.
  • Consideration should be made to CCTV
  • Do all employees have unique logon identities?
  • Are strong passwords enforced?
  • Are passwords changes enforced every 30 days, or less?
  • Are password changes significantly different after every change? For example, not simply adding a 1 or a 2 at the end of previous password.
  • Home and remote workers need to have local security installed, for example, personal Firewalls and Anti Virus.
  • Do systems and servers that store credit card data, for example, CRMs and Databases, have access restricted on a need to know basis?
  • Are logs taken and stored for system and networks where data is stored?
  • Is the Merchant’s network and systems attached to the network adequately protected against viruses, hackers and other threats?
  • Are these systems regularly scanned and patched for vulnerabilities. PCI DSS requires that all systems and networks with the scope of the card data environment be scanned by an Approved Scanning Vendor at least quarterly.
  • Is the Merchant’s security regularly tested? For example, by having Penetration Tests.
  • Does the Merchant have a plan on how to deal with a breach and is this plan tested? This is often called an Incident Response Plan and can be tuned to deal with all types of breaches for example, the Epsilon Email Breach.

In summary, PCI DSS is not the only area on compliance affecting the Call Centre but PCI DSS does help focus the business on what security, processes and procedures are required to achieve best practice.


Cloud Computing Risk Assessment from ENISA

European Network and Information Security Agency
Image via Wikipedia

In November 2009 The European Network and Information Security Agency (ENISA) published a document title “Cloud Computing Risk Assessment” the “Benefits, risks and recommendations for information security“.

The document maybe 15 months old but it is an excellent starting point for any organisation looking to invest in the CLOUD.

The official ENISA wording is below.

ENISA, supported by a group of subject matter expert comprising representatives from Industries, Academia and Governmental Organizations, has conducted, in the context of the Emerging and Future Risk Framework project, an risks assessment on cloud computing business model and technologies. The result is an in-depth and independent analysis that outlines some of the information security benefits and key security risks of cloud computing. The report provide also a set of practical recommendations.Produced by ENISA with contributions from a group of subject matter expert comprising representatives from Industry, Academia and Governmental Organizations, a risk assessment of cloud computing business model and technologies. This is an in-depth and independent analysis that outlines some of the information security benefits and key security risks of cloud computing. The report provide also a set of practical recommendations. It is produced in the context of the Emerging and Future Risk Framework project.

Download the document from the ENISA site here.

77% of Hospitality Sector Mistakenly Believe They Are PCI Compliant

Orthus Limited, on the 7th March 2011, released the results of a survey conducted of 1000 Level 4 Merchants in the United Kingdom hospitality sector to verify their PCI DSS compliance status. 

The survey indicates 77% of 1000 Level 4 Merchants were compliant to PCI DSS when in fact they were not compliant:

The rest of the survey and its finding are below:

  • Of the respondents claiming to be PCI compliant, 94% stated they had conducted the required vulnerability assessment scanning.
  • Of the respondents claiming to be PCI compliant, only 36% stated they had conducted required security penetration testing.
  •  Of the respondents claiming to be PCI compliant, only 9% stated they had security policies.
  • Of the respondents claiming to be PCI compliant, not 1 had conducted the required wireless scanning.
  • Only 24% of the respondents stated they had executed a self assessment questionnaire (SAQ).
  • Of the 24% who had executed a SAQ, less than 50% had stated they had submitted it to their Acquirer.

“The results of the survey are disturbing and indicate that businesses do not understand the PCI DSS requirements and what constitutes compliance. Almost all of the Level 4 Merchants surveyed who mistakenly believed they were compliant stated that they were told by a vendor that compliance entailed conducting vulnerability scanning. Upon completing the scanning, the Merchants understood themselves to be compliant and therein lay the problem. Merchants are getting their information primarily from vendors who have a vested interest in selling their product.”

“Misinformation is a significant problem in the market.  Vendors are selling their products as facilitating PCI compliance and buyers are not doing their homework” says Orthus Data Compliance Specialist, Courtney Bryan.  “If the vendors are affiliated with an Acquiring Bank their products are even perceived as required for compliance so after a Merchant purchases them, they naturally assume they are now compliant” states Bryan.  

“Something has to be done about this problem. Merchants need unbiased advice and assistance with implementing this risk management framework to prevent card data theft and fraud. There is a real knowledge void in the market about what constitutes PCI DSS compliance and until it’s addressed – vendors will continue to exploit it while the Merchants carry the risks” says Bryan.

Orthus can be found at and the press release for the survey “PCI Compliant: Are You Really Sure?” has as the contact

Lush Cosmetics is once again trading online

Lush the company that has suffered “security issues” over the last few months is up and running again.

The Lush website states “The Lush IT team have worked with our security advisers and bank providers

The site also states “Should you choose to make a purchase, you will see that our payment page now takes you away from the Lush website and directly to our card providers site, where your payment is safely in the hands of the big boys at the money institutions. You can shop with confidence knowing that your details will be safe.”

Hopefully, the lessons have been learnt and they will be trading as well as they did in the past.

Read about the original UK and Australia Hacks here

Eight must-fix flaws prior to an application penetration test

An excellent article by Neil O’Connor for SearchSecurity.

 The full article is HERE but Neil’s Eight must fix flaws are listed below:-

 1.         Trusting client-side validation

2.         Blacklisting for input validation

3.         Improper error handling

4.         Forgotten/change password functionality

5.         Unencrypted communications/authentication

6.         Lack of auditing and logging

7.         Not reusing good security API or already tested code

8.         Not following Microsoft best practice development guides

For PCI DSS the guidance for requirement 6.6 is:-

Attacks on web-facing applications are common and often successful, and are allowed by poor coding practices. This requirement for reviewing applications or installing web application firewalls is intended to greatly reduce the number of compromises on public facing web applications that result in breaches of cardholder data.

  • Manual or automated vulnerability security assessment tools or methods that review and/or scan for application vulnerabilities can be used to satisfy this requirement


  • Web-application firewalls filter and block non-essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.

Low security awareness found across IT

Extract from the Computerworld article:


The survey, polled 430 members of the Oracle Application Users Group (OAUG) conducted by Unisphere Research and sponsored by Application Security Inc.


About 22% of respondents claimed to be extensively involved in security functions


60% claimed a limited or supporting role, and the rest said they were not involved with security at all.


About 100 respondents belonged to companies with more than 10,000 employees.


Just 4% admitted to being fully informed about security breaches within their organizations.


About 80% of those who said their organizations had suffered a data breach in the past year were unable to tell which IT components might have been impacted by the breach.

 Low security awareness found across IT – Computerworld.

Create a free website or blog at

Up ↑

%d bloggers like this: