Originally published on LinkedIn · September 19, 2018. GSX 2018 Release updated September 23, 2018.
I am far from a ASIS/ANSI/RFC/IETF/NIST level standards writer, just an ops guy tired of excuses from manufacturers and wanted to provide a serious solution to end the excuse and start the discussion (decades late, mind you).
All suggested updates can be sent to the standards committee at cs4pst@askmcconnell.com
23 September 2018 Update: I have made a few updates and am calling this my GSX 2018 Release Draft. As I have the privilege to attend, speak, and serve at ASIS GSX 2018 this year, this will be in my “back pocket” for when there is discussion about whether or not there is a published standard.
Background
For too many years, I have listened to the excuses of countless physical security suppliers/vendors/manufacturers/service providers that “there are no published cyber security standards for our industry.” There are many standards that would help, but for some reason even as late as face-to-face meetings I had with many of them in August 2018, I keep hearing this excuse. Maybe it’s the title of the other standards or something else. Well, the time has come to make a final elimination of that excuse. This draft is my attempt to SOLVE THE EXCUSE PROBLEM.
I thought I would get into “Levels of Compliance” to this standard, but I think that is more important in the organizational maturity side so I might address that in a future version. So if you are buying physical security stuff, technology, or services, feel free to reference this in your RFI/RFP/Contracts. If you use the excuse that this standard isn’t “widely accepted” or “industry recognized” then you are missing the point. From today (9/18/2018) forward, I will be placing this standard in every contract that I have influence in — not just in purchasing physical security products and services, BUT will require EVERY supply chain agreement I am involved in to require that their physical security capabilities meet this standard.
“Do these simple things at scale and we will see great improvements” — Dr. Ian Levy
Organizational (People)
- Publish proof of your SSAE 18 / SOC 1 / SOC 2 / SAS-70 TYPE II Yearly Independent Audit and its scope.
- Dedicate at least two people with CISSP, CISA, SANS or recognized industry security certification reporting to a dedicated Chief Product Security Officer.
- Publish proof of your end-to-end supply chain security program (reference NIST SCRM).
- Published name of your Chief Security Officer and Chief Information Security Officer (can be the same human and may be virtual) that is trained and certified as a security professional — you know, the people that cover physical security, cyber security, fraud, investigations, etc.
- Publish your NIST CSF Maturity Level.
- Make sure your sales and “solutions” teams are trained in communications integrity.
Technical (Technology)
- Update your non-EOL software components at least yearly using the latest supported version of all software, APIs, components, operating system, firmware, and drivers.
- Don’t use EOL, unsupported commercial or open source software in your development.
Process-wise (Process)
- Register with CERT/CC for Vulnerability Reporting — Thank you Mr. Dormann.
- Make evidence available about how you train and use CMU Secure Computing standards — Thank you Mr. Secord.
- Make evidence available about your Full OSI Model Pentesting Process.
Accreditation
- Publish plans for product security evaluations from labs such as ICSA Labs or UL Security Certification.
- Publish your ISO 2700x Certification or plans to get certified for the scope of your environment that impacts the products you are selling me.
- Publish evidence when each of your products, services, and software elements have gone through exhaustive security scans from tools like: Veracode, Blackduck, Fortify, and other types of code-level analysis tools.
Documentation / Transparency
- Provide a public-facing, dedicated, and easy-to-find Product Security Website (e.g., www.myc00lproduct.com/security).
- Honor bug finders.
- Have your inventory, vulnerabilities, risks, and threats management processes well documented and ready at any time for a great auditor to show up.
- Document if you are independently certified/accredited to a standard but don’t try to fool us with “compliant”, “follow”, “reference”, “adopt” when it comes to standards. If you are not certified/accredited, give me a date when you will be.
- Make available your measured ability to scale your process, customer service, technical support, AND your technology based on your ability to support Small Medium Business (think <250 people/assets), Enterprise (think <50,000 people/assets), and Carrier Size (think >50,000 people/assets) implementations.
- Make sure all your documentation, website, webinars, white papers, paper literature, and social media content doesn’t use words like “all”, “every”, “any”, “best”, “only”, “enterprise-wide” unless you are ready to defend it.
- Publish your Code of Conduct / Ethics / Integrity for you and your suppliers along with your Ethics Reporting Hotline. Don’t have one, get one.
Don’t
- Don’t blame “other software” that you use in your software.
- Don’t blame me or your customers for the costs — think about the impact if someone dies or is injured because you were lax in these standards.
- Don’t blame your customers for not using your “hardening guide.”
All suggested updates can be sent to the standards committee at cs4pst@askmcconnell.com