Ambiguous Security Standards
Some security standards make statements that are ambiguous. One example is the PCI DSS that says “only necessary ports should be open”. The default effect of this ambiguous statement is for all sites to legitimately claim that all open ports are necessary and everyone passes. “The Remote Desktop Protocol is necessary to remotely manage the web site host” for example. In general ambiguity usually occurs when standards writers attempt to write “catch all” statements without precision. In a world where development technology is intentionally designed to create unique web sites that themselves have unique functionality, it is understandable that very few sites will share an exact set of functionality. Therefore in many cases specifying a criteria that “fits all” leads to ambiguous statements which themselves become meaningless. People can easily navigate around them with context.
A better approach to avoid ambiguity is to write concise statements and provide a flexible process to request exceptions. For example a better approach to the PCI DSS open ports issue above would be to say “Only ports 80 and 443 allowing inbound and outbound HTTP and HTTPS traffic should be enabled”. All other ports requests could then be documented by an accredited auditor and submitted to an approval process along with a set of documented guidelines for approval. This approach allows for a standard to specify security that should apply to the majority and provides a fair and effective process to avoid penalizing the minority.
September 4, 2007 at 2:30 pm
My favorite is “All security-relevant events shall be logged”. How do I build to that?
September 4, 2007 at 4:12 pm
In addition to For example a better approach to the PCI DSS open ports issue above would be to say “Only ports 80 and 443 allowing inbound and outbound HTTP and HTTPS traffic should be enabled”. All other ports requests could then be documented by an accredited auditor and submitted to an approval process along with a set of documented guidelines for approval.
For those ports that utilize RDP, SSH, etc… I would add a statement stating what traffic should be allowed, when, from where, use of two-factor authentication, and be protected by IDS/IPS/Firewall…
September 4, 2007 at 6:17 pm
>My favorite is “All security-relevant events shall be logged”. How do I build to that?
Mine too! That is why I was fighting this somewhat uphill battle of logging [almost] everything.
In any case, PCI isn’t that bad in this regard. Think SOX with “gotta have controls”-type of requirements….
September 4, 2007 at 11:04 pm
>All other ports requests could then be documented by an accredited auditor and submitted to an approval process along with a set of documented guidelines for approval.
All this does is push liability to the approver. Due to the scale and scope of PCI, this will be a rubber stamp process, with the approver being liable for “allowing” the port being open.
Why not have an auditor inspect every change (firewalls, software, OS configs, Web Serer configs etc) before it the change is applied? Of course, we then end up with the “PCI Police”.
September 6, 2007 at 7:05 pm
The updated PCI DSS says exactly what you suggest, actually they added a VPN port but that’s nitpicking. Here’s what the standard actually says:
“Justification and documentation for any available protocols besides hypertext transfer protocol (HTTP), and secure sockets layer (SSL), secure shell (SSH), and virtual private network (VPN)” 1.1.6 of PCI v1.1
Also, many of the things you cover in this regard are discussed at the QSA training. That’s one reason I would recommend a company who is certified as a QSAC to give advice on the PCI DSS standard.
September 6, 2007 at 10:49 pm
Thanks Clint.
September 6, 2007 at 10:53 pm
Lyalc
Thanks for the comment. Def won’t be a rubber stamp process if set up correctly. Think about it like the legal system of courts. magistrates, regional, states, supreme etc. The idea is to build (propose at this stage) the right political system and business model at this stage that will scale. As for the inspect all changes I can’t see this scaling. One of the things we are trying to think hard about is the stakeholders. Some are mom and pops, others big co’s and all have individual needs and constraints. It really is a hard problem to get a workable solution given the broad scope of the solution and the sheer amount of people it touches.
September 16, 2007 at 7:22 pm
[...] couple weeks ago, Mark Curphey blogged about Ambiguous Security Standards; standards that make “catch all statements.” In the comments, Clint Garrison points out [...]