PCI DSS Wireless Analysis and Recommendations, Part 4

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!
This entry is part of a wonderful series, PCI DSS»


The PCI DSS Wireless Guidance document is filling out a very important need.  As I said in Part I, Part II, and Part III.   Today I will continue analyzing this Wireless Guidance document.  I will number them and ask that you refer to that number in your comments on my suggestions.  Remember – the goal is to help improve the document.


How to Improve on the PCI DSS Wireless Guidelines Document – Part IV

More processes

Continuing in the review of the "Complying with PCI DSS" flow chart, I found some other areas I would change.



(14)  I remove the arrow form "Change defaults" and draw one instead from "Generate audit report" – to "Enable 802.11i".   This may seem as a small fix, but in fact it means "Enable 802.11i AFTER you generate an audit report".   I also (15) would consider changing the verbiage of "Generate audit report"….  How can you generate an audit report to prove that the defaults have been changed?  Do you simply compare it to an earlier report that said that those were the vulnerabilities?  Do you just submit it as "this weakness not found" type report?  Either way, lets change the way it is phrased.

Similarly to (14) above, I would recommend item (16) to route the arrow from "Enable 802.11" to "Physically Secure" to originate at "Generate a wireless audit".  The difference being that taking the steps of "A centralized management system" and "Generate a wireless Audit report that proves…"  are very important to enablement of Audit.  The way the chart is drawn now, these can be seen as optional processes, and should not.

Finally here (17) I would like to note that in some situations it is not feasible, while certainly being desirable, to physically secure wireless devices.  They can be our of reach (as in on a very high ceiling) or maintained by a third-party organization.   I would suggest that the term be defined so an organization would not fail on their audit just for that reason alone.


More to come next Monday…


Tomorrow we will have Chris’ final article in the "How to talk to Senior Management about Security".  On Friday, as I promised, a discussion of Confidentiality, Integrity and Availability, and the next article in the PCI DSS Wireless series will be Monday.




How to Talk to Management About Security: Part 3 of 3 – Guest Blog

This entry is part of a wonderful series, Talking to Management»

In this third and final Installment, Chris Hayner sums up his recommendiation on


How to talk to management about security

Specific strategies for talking security

So it’s finally time to ask for approval for your project. What are the best ways to get your ideas across?  How can you get show senior management the importance of your project without alienating or boring them to death? Here are a few essential elements of a successful business presentation.

You should:

  • Speak clearly and explain the issue in basic terms. Do not try to impress them with technical language.
  • Avoid business language as well. Managers talk to one another in Management Speak. If you start spouting off about ‘revolutionary’ ‘shift paradigms and the like, you will just come off as patronizing.
  • Stress that information is the life blood of an organization. Protecting customer data, employee data and intellectual property has got to be a priority.
  • Remind them that the majority of security issues come from within the enterprise. This is often a glaring hole in the security structure that is easy to overlook from the boardroom. This can get managers interested quickly, providing a springboard into the rest of your presentation.
  • Identify project goals and attempt to define ROI.  No manager on earth will sign off on a project that doesn’t have concrete goals to justify the cost of the project. Try to include charts and graphs, if applicable, as graphical information is easier to digest than abstract numbers.
  • Show case studies of where security failed, and what it cost other organizations. This will remind managers that while no one ever got a raise for not getting hacked, plenty of people have been fired for security breaches occurring on their watch.

Be prepared to back up your assertions with data and case studies, but don’t fill a presentation with needless slides just to fill time.  Be prepared to answer questions, and try to anticipate as many as possible. Practice your presentation so you don’t stumble or lose the flow.  All senior managers are by necessity practiced speakers, and you need to sound professional in their company.