Security comparisons between two approaches: how to distinguish FUD from Substance?

Question

Background:

WorkerB and Tymac were discussing the pros-and-cons of using two different alternatives for extending a web content management system that is used in their company.

• Alternative one allows a developer to extend the CMS using home-grown PHP files that conform to the API of the CMS.

• Alternative two allows a developer to extend the CMS using a WebGUI-based configuration tool that generates custom SQL queries, without requiring the developer to code any PHP.

Issue:

WorkerB has pondered that alternative two might be generally "more secure", because the web-gui tools are provided by the vendor of the CMS, and it has been scrutinized extensively by the makers of the CMS.

Tymac has pondered that alternative one might be generally "more secure", because home-grown PHP files can be put into a git repository, and have every change tracked and reviewed by multiple people, as well as be audited by tools such as PHP_CodeSniffer.

Outsider opinion:

An outsider has come in and further muddied the discussion, by asserting that neither approach is inherently "more secure" because they are both Turing Complete programming interfaces, one just uses the WebGUI and the other just uses traditional text files with PHP code.

The outsider further suggests that asking which approach is "more secure" is fine if you just want to do product differentiation or marketing, but from a security standpoint, the discussion lacks substance unless you talk in terms of specific vulnerabilities and exploits.

Questions:

• 1) Is there a non-arbitrary, systematic way of comparing the security of the two approaches proposed by Tymac and WorkerB?

• 2) If the answer to 1) above is "no", how can one understand what the outsider is talking about, with the point about "Turing Completeness" and marketing vs substantive conclusions about security?

• 3) Security is a hot-button issue that can make people afraid, and fear can be a powerful motivator. Using the above example as a template, how could one understand the underlying issues and make recommendations to management while still minimizing the FUD factor?

Answer 1

Recommendations to management need to be framed in terms of effort, costs, and risks. 'Best Practices' and marketing-speak will not communicate well on their own, so defining the problem in terms of effort, costs, and risks will keep everyone focused on the realities of the situation.

Your 'outsider' is not helping the discussion with tossing around a term like 'Turing Complete', but IS helping by talking about getting specific. What are the threats you need to protect yourself from, and how does each approach help you protect yourself from those threats? How much will the protection cost, and what risks are exposed by utilizing either approach?

Home-grown code tends to have problems that are not evident to the one coding it, so vulnerabilities can be overlooked. Pre-written code from a team should have gone through code review and testing, but we have all seen instances where this is not true. Both of these comments come from general experience from other projects, and not specific to the project at hand. That means whatever solution is decided upon needs to go through the same risk mitigating processes to ensure that those risks do not harm your company. Once you incorporate a universal risk-mitigation approach to any solutions, you might find your choices of solutions are simply based on effort and cost and not on risk or security.

There is still some arbitrary elements, even with this approach (defining and quantifying risks, for instance), but it reduces the FUD and personal preferences and gets to something real and actionable.