SonicWALL security standard

I have been ask by PCI QSA regarding what is SonicWALL using for PCI industry hardening standard.

I have been searching the internet and talking to SonicWALL support but couldn’t get the answer. So I will try here.

Anyone know this information or any PCI expert here that can tell me what to do with PCI Req 2.2 regarding system hardening standards?

Please advise.

Thank you
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Blue Street TechLast KnightCommented:
Hi Collin,

For req 2.2 of PCI DSS 3.2 states,
Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
It is saying that there are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses. Here are some examples for guidance,, and,, and product vendors.

There is nothing specific, per se, to firewall configs like there are with other requirements for firewalls such as req 1, 6.6, 10.5.4, 10.6.1, 10.8, 11.2, 12.10.5, 12.11, 12.11.1, and other Appendixes, whichever applies to your SAQ score.

Here are some testing procedures you can do that are specific for req 2.2. All firewall related items are denoted in bold below.

In general, keeping the firmware up-to-date. Vulnerabilities by manufacturers will be prevented and thwarted by firmware updates. It is also very important to read the Release Notes prior to installing firmware updates that way you will understand the known vulnerabilities, workarounds and possible known bugs and how to avoid them and set better mission-critical expectations. Aside from the comments in bold below, other hardening techniques are achieved in other requirements.

a) Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards.
b) Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in req 6.1.
c) Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.
d) Verify that system configuration standards include the following procedures for all types of system components:
      • Changing of all vendor-supplied defaults and elimination of unnecessary default accounts - Applicable to firewalls - this one is ridiculously obvious and insulting to all IT professionals but if you find a device with default creds...stop and re-analyze your methodology - furthermore, you should not allow remote access for management except via C2S (Client to Site) such as an SSL-VPN like NetExtender with 2FA enabled.
      • Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server - n/a
      • Enabling only necessary services, protocols, daemons, etc., as required for the function of the system - Applicable to firewalls - If the company is not using it loose it! If you host applications make sure you are forcing all inbound traffic to be encrypted - HTTP should only be open if 443 redirection is implemented correctly. If no one uses a S2S VPN or C2S VPN disable them. Make sure L2TP is disabled. If no one is ever in the office 1 or 2-hours after office hours then set the Wireless to enable on a schedule so that narrows an adversaries attack window.
      • Implementing additional security features for any required services, protocols or daemons that are considered to be insecure - Applicable to firewalls - don't use insecure protocols or open ports such as Aggressive Mode Proposal Exchanges for VPNs or open ports that allow unencrypted traffic inbound and if that breaks an LoB or critical function: either address the function or isolate the pathways so they cannot co-mingle with the rest of the environment.
      • Configuring system security parameters to prevent misuse Applicable to firewalls - Enforce user lockouts for all user accounts: Admins and users alike. Also limit Source Connections on all Zones - this requires research, planning and testing!
      • Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers - Applicable to firewalls - same as three points above.

Let me know if you have any questions!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Basically, a lot of what BST has already answered. On top of this, I would contact Sonicwall support because I remembered there were times where some of the firmware Sonicwall had released would fail PCI scans despite a solid configuration.
CollinMendozaAuthor Commented:
Hi. Thank you both for the respond. I did already contact SonicWALL support and send me some PCI documentations. Thank you BST for your input and clear some of these statements. I think I have something to go on.

Thank you again.
Blue Street TechLast KnightCommented:

I remembered there were times where some of the firmware Sonicwall had released would fail PCI scans despite a solid configuration.
I think you may be referring to older SonicOS versions which had RC4 and SHA1 ciphers for their self-signed certs. There was a transition when RC4 were still there and users didn't know how to reissue the new self signed cert after they upgraded their firmware.
Blue Street TechLast KnightCommented:
Glad I could help...Thanks for the points!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.