Some thoughts on PTPE

In recent years there has been much discussion about the use of Point-To-Point Encryption (PTPE or P2PE) as a method for minimising the scope of compliance requirements for merchants. Effectively this works as follows: 

- Merchant has a Point of Interaction such as a PIN Entry Device which encrypts cardholder data using keys to which the merchant has no access.

- Encrypted cardholder data is transmitted from the merchant environment to the service provider’s environment

- Encrypted cardholder data is decrypted by the service provider using a HSM and sent for authorisation

Authorisation message is sent back to the merchant

In the above process, the merchant has no access to cardholder data or any of the keys that do any of the encryption, at any time.   This is a hugely important part of the process, as a number of discussions were had about using other types of encryption for securing the data.  In a PTPE environment the card data confidentiality is maintained using encryption and responsibility for the key management techniques is transferred to a third party.   According to the current release from the PCI Council, only a hardware to hardware implementation of the above solution can achieve scope reduction. This means that all encryption takes place within a PTS validated terminal which is approved for SRED (Secure Read and Exchange of Data) and Open Protocols (if using IP communications) modules and all decryption takes place within a Host Security Module (HSM) in the service provider’s environment.

I’ll go further into the P2PE requirements overview in a moment but it’s worth pointing something out here.

A service provider can provide a solution to a merchant whereby cardholder data is encrypted in the terminal and decrypted in the service provider’s environment. The merchant and service provider can be PCI DSS compliant and the service does not have to be validated and certified as a PTPE solution. The benefit of a validated PTPE solution is that a merchant can effectively write off their face to face channel’s PCI scope and much of the risk while relying on the service provider’s validated solution. If a merchant uses a PTPE solution which is not listed with the SSC, that merchant will need to complete an applicable SAQ depending on the environment or a RoC depending on transaction volumes.

The PTPE requirements are split across 6 domains. In a nutshell, these are as follows:

Domain 1: a POI which is PTS (PIN Transaction Security) 2.0 or PTS 3.0 validated with the SRED module validated and enabled and Open Protocols listed and enabled if the terminal uses IP must be used as part of a P2PE solution.

Domain 2: any application on the PTS PED (PIN Entry Device) must be validated by a PA-QSA (PTPE). Such validation must be performed for applications which do and which do not handle cardholder data.

Domain 3: the POI (Point Of Interaction) device must be secured at all times. This includes inventories, physical security and transport controls.

Domain 4: this domain covers segmentation between encryption and decryption environments and is not currently in scope as the standard is hardware/hardware only. This will be elaborated upon for hybrid environments when such may be approved.

Domain 5: the decryption environment must be PCI DSS compliant and must use secured and approved decryption devices. Physical security and inventories are again prominent here.

Domain 6: management of encryption keys is detailed here and is far more complete than you may be familiar with from requirement 3 of the PCI DSS.

Domain 6 also contains 2 annexes:

Annex A: Cryptographic Key Operations for Symmetric-Key Distribution using Asymmetric Techniques

Annex B: Cryptographic Key Operations for Key-Injection Facilities

The PCI SSC has clearly put a lot of work into this standard and there is pretty much no room for interpretation. The exams are a test of knowledge much more so than the standard QSA exams. While there are currently no validated PTPE solutions as yet, this will be an interesting areas to watch develop.

My considerations are:

Service providers able to provide this service in Europe may become an oligopoly (at least in Europe). I’ve heard rumours of terminal providers restricting the ability to install custom applications.

However, this could also become a very disruptive technology in the market, allowing smaller terminal manufacturers to team up with smaller payment processors and enter the face to face payment market.

There is an opt-out clause available to merchants whereby they can disable the encryption mechanism in the PTPE solution. This is effectively a ‘KILL’ switch and requires the merchant to accept responsibility to use alternative controls and/or processing method. I imagine the problem threshold to affect this should be pretty high and controlled! There’s not much detail as to how this would work in practice.

Information Security, Reputation and FUD.

Often I hear sales people use brand and reputation damage to secure information security investment.  Typically done without example, real context or evidence this is a shameless use of FUD. For the uninitiated that's Fear, Uncertainty & Doubt.

FUD is the tool of choice for bad sales people in the information security world, "you might be subject to this, This or even THIS!!".  If you hear these cries you are probably talking to a bad sales person.  Honest consultants will help you manage and understand information security risks.  They may even get to the point where they tell you that some risks can't be quantified using traditional methods and then frame advice using good practice references.  Sensible historical evidence shows how breaches have occurred and we need to learn lessons from these by being open about their cause, target and outcome.  Too many people are suffering preventable breaches at the moment.

However, focusing only on damage to your reputation may lead you astray.  Reputational value is very difficult to quantify in real terms.   Information security professionals should deal in risks based on facts, and how those risks can really impact a businesses.  I wanted to explore a couple of examples after  Dark reading put out an article recently on the "6 Biggest Breaches of 2012".  This looks like a skewed list towards the US but I'm going to pick out three of the commercial organisations on the list.

All arguably big names in their respected sectors.  All have suffered breaches that have been publicly announced one way or another.  All are still trading.  Lets look at some financial indicators :-

Global Payments (data from Google Finance stock feeds)

If you were shown the YTD graph on Global Payments(NYSE: GPN) you could be forgiven for thinking that "the breach" caused an ever increasing share price to drop suddenly and dramatically (in reality the graph scale makes this look worse).   However the graph above shows a full one year of their NYSE price and shows that in July 2011 they also had a big share price dip and that the price has been fairly volatile until recent months.  However, share price != reputation.  Lets look at the other key stats and ratios that are considered. In 2012 Global Payments mean quarter on quarter sales estimates were up, estimated earnings per share were up, compared with 2011.

So is it fair to say their reputation was damaged by a security breach?  Perhaps,  there were a number of articles in the press, a lot of fairly scathing commentary. In reality though whilst their share price took a bit of a knock it was small really.  GPN had similar price drops.  Key business indicators seem to show a company that is holding up fairly well in tough economic times.  Most CEO incentives are geared around financial performance, and not on reports about the company.

Zappos.com Inc is privately owned and so digging up financial data again isn't as straight forward.  They are apparently the number one seller of shoes online.  Gross revenues appear to be circa $1bn with an approximate margin of 10%<unverified!>.  So we would perhaps expect Zappos to be  über  brand concious and take intellectual property management seriously as part of their information security processes....  Well maybe they do, I don't know I've never worked with them.  A good friend of mine worked in the fashion industry as an information security manager and told me that culturally that's just not how the industry works.  Lots of designers see the design IP as "theirs" until its actually made into a product that is sold.  Designers flit between companies with their ideas and are given free reign to do as they please.  Anything that seems to put restrictions on them is met by huge barrage of reasons why not to do it and senior management "accepting the risk".  His organisation put a lot of effort into shutting down counterfeiters instead.

Zappos is a retailer though, and perhaps run by people who are only interested in selling product and making margin.  Their senior management probably isn't going to be too interested in information risk management practices (or wasn't).  One would expect their information security to be focused on the risks that will really affect overall margin, logistics and the ability to actually deliver the product and customer service expected.  A denial of service or a breach that took down call centres or heavily disrupted the customer service would likely get people's attention.  Trying to convince someone in this space that information security protects reputation misses the point.  Their reputation isn't made from security, its made from good service.

And then there was Linkedin... You might even be reading this because I posted it on my Linkedin status! Linkedin suffered a breach that was widely seen as embarrassing within the information security community. However, Linkedin are still online, traded and doing business. It will be interesting to see if the breach is ever properly disclosed and if anyone discontinues the service. That being said the Linkedin service has value, and its reputation is built on other things.

Looking at the LinkedIn 1yr stock graph doesn't really show us much either. Hand on heart you can't look at that graph and say "ta da! thats the breach announcement day".

LinkedIn show the same sort of key stat information as Global Payments, key revenue estimates are all higher. Although it is interesting that Linkedin's share price is more than double Global Payments despite them generating lower revenue.

So, next time you hear someone pulling out the FUD gun trying to tell you "its all about reputation" - its fairly clear its all about "them not getting the facts straight".

Security breaches do damage the reputation of companies, but that's not what its all about. Those companies have data which affects others, card numbers, personal data etc. This causes both the business and the consumer to be affected. Businesses can and do recover; in some cases with limited share price damage. Consumers, can and do recover, though are left with having to cancel cards, argue with banks, or check credit reference agencies in case their identity has been stolen.

SME companies can suffer more acutely, typically throwing the problem at IT they are suddenly hit with un-budgeted consultancy, audit, and a lot of new processes to implement and technology to buy. A breach might not leave their reputation in tatters but it could come as a financial and operational burden. Suffering a breach and not having the tools or talent to deal with it can be an expensive exercise. Another reason for having information security management with some degree of strategic oversight.

Andy

Advice for Parents - Photos in school

Being married to a teacher and having a number of teachers in my family I'm sad to say that I've seen a number of over zealous Headteachers particularly in primary schools who get a little bit carried away quoting the data protection act at Parents, almost always incorrectly.

It normally happens like this :-

Parent whips out a camera to take a picture of little Johnny as he crosses the finish line at the school sports day.  Headteacher comes running over citing all sorts of data protection related reasons why Parent can't take a photo of little Johnny.  Parents get annoyed and frustrated, upset that the Headteacher is denying them the opportunity to take photos of their child.  

This kind of frustration is shared by many parents who unknowingly forego the opportunity to take photos/videos because of an over aggressive and ignorant application of the Data Protection Act.

So... what does the Information Commissioners Office "ICO" actually have to say on the matter.  Well as you might expect they have issued a specific guidance note on just this topic.  A note that on occasion I have actually sent to headteachers so they are aware of what the rules are.

"Recommended Good Practice

The Data Protection Act is unlikely to apply in many cases where photographs are taken in schools and other educational institutions. Fear of breaching the provisions of the Act should not be wrongly used to stop people taking photographs or videos which provide many with much pleasure.

Where the Act does apply, a common sense approach suggests that if the photographer asks for permission to take a photograph, this will usually be enough to ensure compliance.

Photos taken for official school use may be covered by the Act and pupils and students should be advised why they are being taken.

Photos taken purely for personal use are exempt from the Act."

Yes you read that correctly.  Photos taken purely for personal use are exempt from the Act.  So what typically happens is a head assumes that because THE SCHOOL(!) may have data protection issues to deal with when taking photos of pupils and students, that those same rules may apply to Parents taking photos for personal use.

The ICO guidance even gives specific examples for complete clarity.

"Examples

Personal use:

A parent takes a photograph of their child and some friends taking part in the school Sports Day to be put in the family photo album. These images are for personal use and the Data Protection Act does not apply.

Grandparents are invited to the school nativity play and wish to video it. These images are for personal use and the Data Protection Act does not apply.

Official school use:

Photographs of pupils or students are taken for building passes. These images are likely to be stored electronically with other personal data and the terms of the Act will apply.

A small group of pupils are photographed during a science lesson and the photo is to be used in the school prospectus. This will be personal data but will not breach the Act as long as the children and/or their guardians are aware this is happening and the context in which the photo will be used.

Media use:

A photograph is taken by a local newspaper of a school awards ceremony. As long as the school has agreed to this, and the children and/or their guardians are aware that photographs of those attending the ceremony may appear in the newspaper, this will not breach the Act

"

The only way I can see a school can enforce the none taking of photos at any school event is if somehow the parents have signed up to some sort of contract that prohibits it.  That is different (and I am not a lawyer).  If someone starts swinging the Data Protection Act at you and tells you to switch off your camera.  Well at least you know where you stand now.

Guidance paper quoted can be downloaded from the ICO here.

Documentation in a Business Environment

Documentation is just as important as correctly securing a technology, without it the details can stay inside peoples heads, which can lead to it being forgotten or easily leaving an organisation.  Let’s look at how to do it, so it is both useful and meets our compliance or regulatory requirements.

Before looking any further it is important to understand the different types of documentation, so you can understand what a standard such as PCI DSS is actually requires from you:

Policy: Policy is management’s way to direct staff to do something, or to set expectations for something such as a certain level of control.    An information security policy is the starting point of an organisations commitment to managing security risks. 

Procedure: A procedure is defined as a detailed description of the steps necessary to perform specific operation.  To take this further a procedure is how you as a business are going to implement the desired level of control.  This can be seen as the business response to the management objective set in a policy.  A procedure can also be the operation of a specific control.  In some cases a specific procedure to detail the correct way a set of actions should be performed.

Standard: A standard is a set of rules or specifications that, when implemented together define a software or hardware asset.  The make it compliant blog has already completed a guide on defining configuration standards; this forms a really good basis for a standards document (but I may be biasedJ).  A key point to note with standards is there should be a defined exception handling and authorisation process; because we all know that it is not always possible to implement every detail all the time. 

Guidelines:  These are suggested actions or recommendations related to an area of a policy that may supplement a procedure.  Unlike a standard, implementation of guidelines may be at the reader’s discretion.  For example a policy statement may state that employees are required to wear identification at all times, a guideline may outline that the acceptable wearing is either on a neck tie or a pass holder; often directing the user where to request or find supplies of these.

Form: A policy may state a requirement for records to be maintained of control implementation, the best way to record this is through the completion of a form.  A procedure would define the level of detail required to be completed within a form and the required management authorisations to be captured.  Forms can be paper based or electronic, but they are useless if they are not maintained.

Presenting an auditor or assessor with a good set of structured documentation is an excellent way to start presenting your business as meeting the spirit and intent of many compliance and certification requirements.  If your documentation is a mess, one’s first impression is that your environment is going to reflect this. 

Some believe that having a 100 page policy document is not a good move, and some will argue if it is the one source of information people always know where to look.  I think that this is never going to be resolved, especially here.  The truth is it doesn’t really matter as long as the target audience can navigate it and understand it, and the key to this is referencing. 

A policy document should identify supporting procedure documentation when required; a procedure should identify the applicable standards, and so on.  If you have a 100 page policy document you should reference procedures as you go.  If you have independent documentation, then these can be referenced at the end. 

Assigning an owner to a document is a requirement to show that controls are owned, this creates accountability within the business.  Controls are only ever implemented when people are informed and aware of their responsibilities..  This is why hierarchy is important in documentation, and assignment of responsibilities starts at the executive level, tone at the top is important to ensure that staff at all levels understand the business requirements, especially for security.  A simple responsibilities matrix across the documentation of a business can be an excellent tool to help capture and define accountability and responsibility.

Make it clear who the target audience for the document is, make sure it is available to them, they know where to find it and can reference it easily.  Making documentation that is applicable to the staff and can be maintained by them is important.  Documentation for compliance is not a one off exercise; it must be demonstrably maintained during the year. 

Documentation should also identify the expected frequency of the control’s operation and associated reporting criteria.  The reporting criteria should include metrics that allow the effectiveness of the control(s) to be measured.  Having good management information about compliance before assessments ensures that there are no surprises.  If there has been notification about control failure or a noted issue, management can prepare a response. 

Management of exceptions is especially important when dealing with a control based assessment such as PCI DSS, if a control is not in place non-compliance must be noted.  The PCI DSS allows for compensating controls to be noted to assist in areas of non-compliance; however these are not just documentation. The compensating controls should produce evidence to show that you have been managing the risk, and will continue to do so once the assessment has finished.

Documentation should also identify where management information on controls are reported.  Not all information is required at Executive level. To ensure effective sponsorship and engagement in information security only relevant information should be provided.  Control failure tolerances should be defined this too can impact on reporting lines.  Some people only need to know about failure.  The most important part is that someone knows and is taking the necessary action.  This is the control owners’ responsibility to delegate, either to individual functions or the governance structures of a business, such as a security committee or risk committee. 

Restricting root shell and root user access through sudo

One of the issues I’ve encountered a number of times in assessments of Linux and AIX environments is the provision of excessive permissions using sudo. This article is an attempt to highlight those issues and provide some guidance as to practical resolution.

It is typical in a secured Windows environment that the administrator username is not used for standard business and that those users who require elevated privileges are members of the “Domain Admins” Organisation Unit.  The generic windows administrator account would be renamed, given a randomised long and complex password which would then be physically secured and access restricted.  In Windows, audit trails can be maintained against each user and users do not execute commands as other users.  This is somewhat different in a Linux environment.

In Linux, it has become more standard to use sudo to substitute user and do commands. Sudo in its default implementation is generally in place as (example from CentOS)

wheel ALL = (ALL) ALL

In Red Hat and CentOS, the members of the wheel group are provided full sudo privileges. In Ubuntu or Debian this would be the members of the sudoers group or the admin group.

The above means that a user who is a member of the wheel group can execute ALL commands as ALL users from ALL terminals. In other words, a member of the wheel group can masquerade as other users or can drop to a root shell and no longer have a full audit trail against him.

Users often drop to a root shell to avoid typing sudo before any command. Dropping to a root shell is usually done doing su -, sudo –i, sudo –s, sudo bash etc. In order to prevent sudoers from dropping to a root shell, the shell commands can be removed from the executable files available to the users. This can be done by editing the sudoers file as follows:

Cmnd_Alias SHELLS

SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, /usr/local/bin/tcsh, usr/bin/rsh, /usr/local/bin/zsh

Cmnd_Alias SU

SU = /usr/bin/su

wheel ALL = ALL, !SHELLS, !SU

In the above members of the wheel group can execute all commands on all systems except those commands listed in SHELLS and SU. Sometimes it is necessary for users to drop to a shell when performing administrative functions. Using the above, you could have a configuration with 1 or 2 users permitted to have root abilities with other domain admins having the above.

admin ALL = (ALL) ALL

wheel ALL = ALL, !SHELLS, !SU

Limit access to the admin group in the same way you might limit access to the administrator account in Windows.