4

We are currently working on implementing the PCI-DSS ruleset in our IT environment, where all of the inhouse software we use is Perl. We have a Perl dev team of about 10 people (inlcuding me) and running large applications, mostly legacy.

Now the advisor we pay to help us implement the PCI stuff is not very well versed in Perl and deems the CPAN a risk. The prebundled packages containing CPAN stuff that are available as rpms in the openSuse repository on the other hand are safe to use, according to this guy. He thinks that we should have someone from the outside audit all the code from CPAN we want to install. This person would need to have strong security background and deep knowledge of Perl. Unfortunately, they don't know anyone like that.

Addition: After the CPAN code for each individual module was security-checked, we would create our own rpm package from it (one for each CPAN module) and use these to install on our servers.

My main question is not for some-one who can be that auditor for us (although I'd happily take hints on that front), but rather how other companies working with Perl are handling this issue. As a Perl dev I feel the CPAN is one of the very reasons Perl is still around for larger projects. Not being able to use the stuff people built, documented and thoroughly tested for me feels like having my legs chopped of.

I would be very much obliged about war stories within the same context, personal experience or references to other companies that are using CPAN and are PCI compliant and might be willing to talk about this on a professional level.

simbabque
  • 143
  • 5

2 Answers2

2

Can he point out the section in the PCI DSS Requirements an Security Assessment Procedures 2.0 which he is using to justify this? It's not quite clear if the problem is the fact that it's third party code, or that it's sourced via a collectively managed repository.

If this is only a PCI-DSS audit, then argue your case:

PA-DSS does not apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant's or service provider's normal PCI DSS compliance. [page 9]

and

Note: It is not a PCI DSS requirement to use PA-DSS validated applications. [page 16]

You must review your custom code (PCI-DSS §6.3.2), not necessarily all code (PA-DSS §5.1.4).

In a strict sense, unaudited third-party code or repositories are risks. You need to demonstrably understand and manage those risks.

You should have a detailed inventory:

  • List of hardware and critical software in use in the cardholder data environment, along with description of function/use for each

To meet Requirement 6, you should have a verifiable process to use that inventory to check for, and apply in a timely manner, relevant security updates (§6.1, §6.2) for third party software. This should also be covered by your documented change control procedures (§6.4.5).

You should have a process to evaluate (not audit) modules so that features which fall under PCI-DSS are verified and understood (e.g. authentication, encryption and logging related). This probably means you need to have approved baseline versions of certain packages, and configuration guidelines (e.g. for CA stores, allowed ciphers), where it is relevant.

You should have a documented process for configuring CPAN, including but not limited to, a set of approved mirrors, requiring gpg/Module::Signature (where possible), procedures for sourcing developer signing keys, and requiring a proxy so that downloads are logged and traceable.

mr.spuratic
  • 7,937
  • 25
  • 37
  • Thank you for this argumentation. Could you please explain the difference between *evaluate* and *audit* in this context? I'm not sure I'm grasping the full meaning of these and the machine-translated versions of the PCI docs is not very usefull either. – simbabque Feb 27 '13 at 14:23
  • It should be sufficient to have a competent programmer familiar with the API and documentation determine risk based on the data that module can access. While it is useful to be able to read the code, this is not a *source code audit* exercise. In a sense you are allowed make a reasonable assumption that a module works as described, rather than trying to *prove* it works as described. – mr.spuratic Feb 27 '13 at 18:16
  • I think it is not really the *works as described* part that they are worried about, but rather the *got more than we asked for* part. They are saying there could be malicious code in there. Personally I think it is more likely that the code might contain flaws regarding security-issues. The machines we are talking about are all hosting either an ecommerce app that receives the cc data, or a CRM. I should have put that in the question... will do that shotly. – simbabque Feb 28 '13 at 08:19
1

He thinks that we should have someone from the outside audit all the code from CPAN we want to install. This person would need to have strong security background and deep knowledge of Perl. Unfortunately, they don't know anyone like that.

Well why doesn't he think the same for the rpms? It just seems riskier to him because he feels lost there. But it's just an impression and not a logical fear. In both cases, you should be able to follow up changes before updating/installing anything. However, for society to thrive, we must all depend on others and trust security systems. He seems to imply CPAN is not safe enough, without even investigating it properly. The safest way would probably to have a machine downloading from a trusted source (find out which one it is first), build a package and deploy it. Upgrade only when there is a security issue. Such a tracking system is mandatory for any important infrastructure. That was my two cents.

Now about your question, how other companies working with Perl are handling this issue. From my own experience, we used packages provided by the OS's packaging system. Simply because CPAN would prove too painful, some packages wouldn't build cleanly, some tests would fail. Outsourcing that job to the packagers seemed like a good business idea. And I'm not imagining any security benefits. Packages signatures are not availabe/enabled on all OS, so it's clearly a thing to investigate for your own systems.

So if you have one thing to remember: do not take anything for granted. There is no single right answer. OpenSuse might not provide more security than CPAN, but it could. If it all boils down to the security of the mirror you're using, you may need in both cases to ensure packages or bundles can be verified.

CPAN ships with perl, it's closer to the source from my point of view, and it has benefits too. So this is not a real issue at this point.

For what it's worth, here's OpenBSD Makefile used to build packages: http://www.openbsd.org/cgi-bin/cvsweb/ports/textproc/p5-ack/Makefile?rev=1.11;content-type=text%2Fplain. As you can see, it uses cpan. OpenBSD's well known for out-of-the-box security, I don't think OpenSuse would do anything significantly different.

Keep using CPAN only if you see an advantage to it. Security is a non-issue here, each has to be studied differently (checksum retrieval/checking, mirrors) but from my point of view one is not more secure than another.

Packages may be CPAN code + patches, patches could fix bugs or maybe create others, there is no way to tell.

Aki
  • 762
  • 4
  • 14