3

I am a programmer by day and I am working on a project that is focused around risk management based on PCI-DSS controls within an organisation.

I have been thinking lately that a lot of PCI-DSS controls are focused on software patches, network diagrams and end of life dates etc but if the organisation create their own software should we be adding software code analysis into this area to find possible vulnerabilities and exploits before it goes live?

I know all code should be tested and you can get pen testers to check software but why shouldn't code go through an analysis toolkit before it is released to give you a possible threat level?

  • there are tons of automated tools but that are being used by penTesters and coders... But human beats machine simply... There are way to many false positives etc... btw, probably this is a dublicate. – cengizUzun Feb 20 '14 at 12:48
  • Do the output/reports from these tools get put into control evidence or is it just to fix issues before they go live ? – OliverBS Feb 20 '14 at 13:04
  • it is up to the developer i assume. some of them must get fixed while others may not cause such a big risk but needs a big change to fix? – cengizUzun Feb 20 '14 at 13:08
  • 1
    Hi Oliver - while I think the core of your question is very on-topic, we don't do product recommendations. It is very easy to find comparisons between static code analysis tools, but as the others have commented, it should be seen as a first step in a wider set of tests. – Rory Alsop Feb 20 '14 at 16:02
  • 1
    @OliverBS Yes and no. What I am trying to say is, without a human testing it manually, you can not be sure of outputs of an automated program. You may only check outputs of the automated tools to eliminate false positives, rather than running a full manual test. But, you can not trust the automated tool. (well sometimes you can but oh well...there is always exceptions and these exceptions are not by program but by vuln. type) – cengizUzun Feb 21 '14 at 8:47
3

Your reference to software patches, network diagrams, and end-of-life dates is true with regards to the PCI DSS as a whole, but there are very specific and relevant requirements regarding your question:

  • 6.3.2: Review of custom code prior to release to production...to identify any potential coding vulnerability
  • 6.4: Follow change control processes
  • 6.5: Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities...

Section 6 of the PCI DSS focuses a lot on the security of the coding process but you are right that it does not require a specific implementation. An analysis toolkit would fall under 6.3.2 that requires review of the code either through manual or automated means. Also, you should have a process in place to prevent all classes of vulnerabilities as referenced between requirements 6.5.1 and 6.5.9.

There are many overlapping processes that should be used to mitigate vulnerabilities and ensure that they don't make their way into production code. If you seriously address section 6 of the PCI DSS and meet all requirements with processes that work for your organization and make sense security-wise, you will be in a good place.

  • Is here a list of approved analysis tools to identify any potential coding vulnerabilities ? – OliverBS Feb 24 '14 at 9:23
  • PCI doesn't endorse or require the use of any specific tools and as such, has no list. If you are using a tool to help you meet section 6, you will want to compare the capabilities of the tool against the list of vulnerabilities you need to be mitigating according to PCI: requirements 6.5.1-6.5.10. These include injection flaws, buffer overflow, insecure cryptographic storage, insecure communications, insecure error handling, and all of the typical web application vulnerabilities (if applicable). – freb Mar 25 '14 at 2:30
3

There is no reason it shouldn't, in fact, that's a great way to do an initial check. The reason it isn't specifically listed is because the pen testing and manual analysis should do a much better job than an automated analysis (and may well include one as part of the review.) The point is that automated testing alone isn't sufficient.

  • I wonder if we could add pen testing reports to control evidence ? – OliverBS Feb 20 '14 at 14:57
  • 1
    Pen test reports should be usable as evidence of a point in time assessment against a scope of vulnerabilities at a point in time - so I generally recommend they are used to confirm a stated set of controls – Rory Alsop Feb 20 '14 at 16:07
2

Ignore PCI DSS. It's useless (also see: BlackPOS).

What's important is business process management and a deep understanding of your high-value output chains. The problem of information/data/app security is that low-value input chains can allow adversaries to wiggle their way into high-value output chains. Cover your chains by tracing the data flow through your organization.

Identify critical elements and build an apparatus to assure all of your appropriate input chains. Buy cyber insurance that equates to your BPM system. Appeal to your audit teams, regulatory counsels, district attorneys, and the FTC (or wherever your jurisdictions lie) for self assessment by way of alternate frameworks. If you want my suggestion on a framework, I'd recommend VisibleOpsSec over, say, ISO 27001/27002, PCI DSS, IT COBIT, FISAP, CIP, et al.

Appsec is dead simple. You integrate Microsoft TFS (or Atlassian JIRA/Confluence) with process templates that map to organization needs (roughly) and that work with existing process templates such as EssUP, Agile, Scrum, Waterfall, or whatever little process template tweaks your product management team coordinates with your business/org owners. If you have a third party doing any piece of your software product, you include them (obviously) and hold them to the same standards.

Then, you perform Simulation and Red Team Analysis, as well as some typical Delphi Method Analysis to gather opinions and understand results before they play out in real life. You integrate these concepts into your Application Lifecycle Management (ALM) through bdd-sec and bug hunts. Many bdd-sec and bug hunt toolage relies on Burp Suite Professional, so you make sure everyone has a copy, but also arm them with IronWASP and OWASP ZAP. If you run a JEE shop (probably Atlassian for ALM) then you'll want a good WebDriver (or O2) automated test harness combined with Contrast Security. If you have a Microsoft shop, check out a lot of the standard VisualStudio (or O2) tools -- perhaps adding Fortify or Checkmarx on spot projects that require intermediate or continuous mitigation. Other frameworks do require some unusual tweaks, but nothing too fancy or "out there". If you are running mobile projects then Appium harnesses combined with Clang asan (for iOS) or Coverity (for Android) plus an Appthority spot check will likely work fine.

It's important that this is backed by ENISA and US-CERT quality incident handling and response programs. Staffing or retaining talented DFIR personnel is always your biggest infosec problem. Adding process and tools to that program is your second biggest infosec problem. After that, appsec, datasec, "netsec" (haha, as if that even exists!), and risk management will be a walk in the park.

  • 1
    Great answer thank you very much @atdre for your time :) – OliverBS Feb 20 '14 at 18:39
  • 4
    Saying that PCI-DSS is useless and one should forget it, well, you are definitely missing the point on standards. Of course it's not perfect, far from it, and there are way better standards out there, but everyone should be happy that, at least, it doest exist. You have to be pragmatic when it comes to security, because living in an utopic world where every dev team use TFS, performs pentest/red-team and is aware of every standard, well it's not gonna help anywhere. – ack__ Feb 20 '14 at 21:24
  • 1
    As ack pointed out, if you store card data, you Cabot ignore PCI, no matter what you think of it. – Rory Alsop Feb 20 '14 at 23:30
  • You guys obviously missed my section on self assessment! Try to read! – atdre Feb 21 '14 at 8:51
  • 1
    I don't have to start a good answer. I just have to finish one. – atdre Feb 21 '14 at 17:11
1

As mentionned, there is no reason it shouldn't. One of the reason it is not is the lack of maturity of industry practice concerning code review / audit, not just in a PCI context. There is no well-established standard for what and how you should check for vulnerabilities in software source code, no formalized way to conduct such assessments and, as of today, the existing solutions to perform them are immature and the market is completely unclear for customers. Add a constant lack of specialized engineers that understand how this works and here you are.

  • That is my feelings at the moment. but how can we change this current situation though ? surely as more code is written as security professionals we should be looking at how we can monitor the distribution of code and the quality of it ? – OliverBS Feb 21 '14 at 10:21
  • Well this is not something we can force change, that will come with time and experience from both sides, security practicioners and customers as well. Standards are becoming more and more present, and even if they are still immature and often disconnected from the reality, that will definitely help. Secure SDLC is something that has been totally overlooked in my opinion, although it's usually way more valuable to a customer compared to pentest / audit / whatever. – ack__ Feb 21 '14 at 10:51
  • Yeah totally agree with have the tools on both sides and the knowledge I guess we just need the glue to bring them together. – OliverBS Feb 21 '14 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.