The question of code quality is always a difficult one, since in FOSS it’s 
public and often found lacking, but in private source you may never know. In 
these cases I rely on the vendor’s public statements about their development 
processes and certifications (e.g., ICSA). Commercial products often disclose 
their development processes and even run in-house security threat research 
groups that publish to the community.

There are also outside certifications. For example, 
www.icsalabs.com<http://www.icsalabs.com> lists certifications by vendor for 
those that have passed their test regimen, and both Dell SonicWall and Fortinet 
Fortigate are shown to be current. PFSense isn’t listed, and although it is 
theoretically vetted by many users, there is no guarantee of recency or 
thoroughness of the test regimen.

This brings up the question of whether PFSense can meet regulatory requirements 
such as PCI, HIPAA, GLBA and SOX. While these regulatory organizations don’t 
require specific overall firewall certifications, they do require various 
specific standards, such as encryption strength, logging, VPN timeouts, etc. I 
don’t know if PFsense meets these requirements, as they don’t say so on their 
site. Companies like Dell publish white papers on their compliance with each 
regulatory organization.

-mel


On May 6, 2016, at 11:05 AM, Aris Lambrianidis 
<effulge...@gmail.com<mailto:effulge...@gmail.com>> wrote:

amuse wrote:
One question I have is:  Is there any reason to believe that the source
code for Sonicwall, Cisco, etc are any better than the PFSense code?  Or
are we just able to see the PFSense code and make unfounded assumptions
that the commercial code is in better shape?
Perhaps not. In fact, probably not, judging by the apparent lack of
audit processes for say,
OpenSSL libraries re-used in commercial products.

It still doesn't detract from the value  of what people are aware of, in
this case,
pfSense code quality.

Aris

Reply via email to