Accepting payments is getting harder • Hacker News Board

Re: Accepting payments is getting harder

#121

Post by borski » Sat, May 09, 2015, 12:00 AM UTC

akshatpradhan wrote: post #120

borski wrote: post #118

Earlier quoted context omitted.

Show me where it suggests automated testing as a regular part of your SDLC. It recommends applying patches, coding to secure guidelines / best practices, doing code reviews, and running an automated or manual pen test at least once a year. Nowhere does it state in Requirement 6 that you should build automated testing into your SDLC. Reference: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pd...

Just so we're clear, what do you define as automated testing? Let me know.

Scheduled testing that happens on an automatic basis, or that occurs whenever code is deployed or committed. For example, whenever you would run your unit tests or integration tests, you should also run security tests.

It's the difference between doing an automated or manual penetration test every 12 months and testing your application for vulnerabilities with every deploy.

Re: Accepting payments is getting harder

#122

Post by akshatpradhan » Sat, May 09, 2015, 12:51 AM UTC

borski wrote: post #121

akshatpradhan wrote: post #120

Earlier quoted context omitted.

Just so we're clear, what do you define as automated testing? Let me know.

Scheduled testing that happens on an automatic basis, or that occurs whenever code is deployed or committed. For example, whenever you would run your unit tests or integration tests, you should also run security tests. It's the difference between doing an automated or manual penetration test every 12 months and testing your application for vulnerabilities with every deploy.

It's 6.5.1-6.5.10 of PCI v3.1. That's all security testing. You can use a static analyzer like Brakeman to speed things along instead of doing it manually.

Re: Accepting payments is getting harder

#123

Post by borski » Sat, May 09, 2015, 2:03 AM UTC

akshatpradhan wrote: post #122

borski wrote: post #121

Earlier quoted context omitted.

Scheduled testing that happens on an automatic basis, or that occurs whenever code is deployed or committed. For example, whenever you would run your unit tests or integration tests, you should also run security tests. It's the difference between doing an automated or manual penetration test every 12 months and testing your application for vulnerabilities with every deploy.

It's 6.5.1-6.5.10 of PCI v3.1. That's all security testing. You can use a static analyzer like Brakeman to speed things along instead of doing it manually.

Those requirements [1] state the following:

 Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

 Develop applications based on secure coding guidelines.

It says nothing about automated testing, which is precisely my point. The requirement is that you attempt to follow security best practices and train your employees well. My point is that even the best-trained employees make mistakes.

The reason unit tests exist is to make sure you didn't accidentally break stuff when you write code. I'm arguing that automated security tests should exist for the same reason, and that's what we're trying to offer and build.

Incidentally, section 6.6 does state that you should use manual or automated testing at least annually; PCI 3 added a new clause which states 'after any changes.' Also, it explicitly specifies that you need /either/ automated or manual testing, /or/ a WAF. WAFs, as you're likely well aware, miss things very often. [2] WAFs are a good stopgap, but should not be relied upon to provide actual security; they should only be relied upon to attempt to prevent an attack while you are in the process of fixing the vulnerabilities underneath.

Because penetration testing is so expensive, typically, I suspect it will be more common for people to go with the WAF than to do a pentest with every deploy. I don't have stats to back that up, since PCI 3.1 hasn't actually been enforced yet, but I strongly suspect that will be true.

[1] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1....

[2] http://www.slideshare.net/zeroscience/cloudflare-vs-incapsul...

Re: Accepting payments is getting harder

#124

Post by ukigumo » Sat, May 09, 2015, 11:57 AM UTC

akshatpradhan wrote: post #89

ukigumo wrote: post #64

Well, I guess it won't hurt if I offer my services for PCI guidance for startups here :-) One thing to keep in mind is that PCI is a bare-minimum of security "best practices" that aims at validating that a company transacting with payment cards has an understanding of data classification and protection.

If compliance is bare minimum and not enough, what is a comprehensive approach available right now to reasonably protect our sensitive data? The security professionals will tell you Risk Assessments and Pentesting often is the best alternative [1] Their answer is to specifically switch to Risk Assessment and PenTesting often, which is Requirement 11 and Requirement 12 of PCI. Each one of the bullets written is specif…

The most comprehensive approach is to have an InfoSec policy portfolio which permeates into every corner of your organisation and dictates secure operating behaviours and mandates logical and physical security practices. This will include regular vulnerability scans on your code, your application stack and your infrastructure but it will also include instructions on how to classify data and how to handle data according to that classification.

Compliance is a achieved by marking a checklist which is why is fairly easy to botch it up. Sure you can do a subset of the checklist and have compensating controls for everything you've missed but the risk of non-compliance is not being able to do business (at best) and jail time (at worst) so you tell me what is your motivation to fail to meet the bare minimums of security best practices in card payment industry, aka, PCI-DSS.

Think of a castle; It will have several walls, towers, heavy doors, guards etc. It will also be placed in a hill, a mount or otherwise hard to access area (never in a vale for instance). It will also have the largest possible distance between the treasure hall and the front door. The threats your castle faces will continuously evolve, and the walls that stood up against bows and arrows are useless against turrets or cannons, so if you want to keep your treasure you do your best to be one step ahead and you don't get that by making sure your original walls are still in place or any other base requirements are still met.

Re: Accepting payments is getting harder

#125

Post by vbezhenar » Sun, May 10, 2015, 7:45 AM UTC

borski wrote: post #38

For what it's worth, PCI compliance as it stands today is complete BS. It provides a false sense of security and most of the PCI ASVs are the scourge of infosec. I can't tell you how many customers we have that use the cheapest possible PCI ASV for "compliance," but then use us in addition for "real security," despite the fact that we aren't an ASV. We've intentionally stayed away from becoming one thus far, actually…

The real security audit should be done by hackers the same way browser and OS vendors do it. Vendor lists his website on some platform and specifies money he's willing to pay for found vulnerability. Hackers trying to find vulnerabilities. 3-rd party verifies vulnerability and ensures that hackers are paid. More money vendor offers for vulnerability — more hackers trying to crack his site — more confidence clients have.