When corporate IT evaluators consider networked products that will reside on the company’s IT infrastructure, they usually look for three things:
- Product hardening guide
- Vulnerability disclosure policy
- Documentation of key aspects of the vendor’s product security program
The presence or absence of any of these three items provide clues to product evaluators about the product security maturity of the manufacturer. A few physical security industry companies do provide these but most do not as of July 2018.
Vulnerability Disclosure Policy
The initialism ICT stands for information and communications technology. The ISO/IEC definition vulnerability disclosure includes the term ICT, which is why I explained it. ISO/IEC 29147:2014 states in its Introduction:
A vulnerability is a weakness of software, hardware, or online service that can be exploited. An exploitation of vulnerabilities results in a disruption of the confidentiality, integrity, or availability of the ICT system or related information assets, which may cause a breach of data privacy, interruption of operation of mission critical systems, and so on.
Inappropriate disclosure of a vulnerability could not only delay the deployment of the vulnerability resolution but also give attackers hints to exploit it. That is why vulnerability disclosure should be carried out appropriately.
Vulnerability disclosure is a process through which vendors and vulnerability finders may work cooperatively in finding solutions that reduce the risks associated with a vulnerability. It encompasses actions such as reporting, coordinating, and publishing information about a vulnerability and its resolution.
Written for Huge Development Teams
The vulnerability disclosure standard was written by and for large development teams like those of Amazon, Facebook, Microsoft, Netflix, Salesforce and so on. It is based on the successful practices of companies who have between 1,000 and 5,000 developers. Product teams in the physical security industry are nowhere near that large. So there is a lot of detail in the 42-page standard that doesn’t apply to most industry companies.
However, the Coordinated Vulnerability Disclosure (CVD) process (defined in the free ISO/IEC 29147:2014 Standard) and its related Vulnerability Management Process (defined in the ISO/IEC 30111 standard) are simple to understand and implement on a scale that’s appropriate for physical security industry manufacturers. The ISO/IEC 29147 standard illustrates them using the diagram to the left, on page 4 of the standard.
Easier Than It First Seems
RBCS has found that security industry companies who are using the agile development approach can easily map the appropriate roles and responsibilities defined in the two standards onto their existing personnel and processes.
Depending on the size of the dev team and its current development priorities, this can be done non-disruptively in a matter of weeks or worst-case in a few months. Usually it’s the shorter time frame.
Look at the diagram on the left and replace the word “vulnerability” with “bug”. Start with the step, which would now be read as, “Receive bug report from external source.” Don’t those steps match up pretty well with how your development team handles suspected bugs now?
The reason that RBCS offers to help is that it can be very time-consuming to study the ISO/IEC standards and related references, only to come to the conclusion that most of it doesn’t apply. The idea is to speed up:
- development of the vulnerability disclosure process,
- definition of the vulnerability management process, and
- implementation of the process as it best fits existing development resources.
The less the needless interruption to your development team, the better.
Documenting Your Security Program
A key benefit of lightly documenting your product security program is that customers get assurance that you are paying attention to security issues from a proactive & preventive approach, not just a fix-them-if-found approach. It’s a smart thing to do for internal reasons, as the fewer the security issues are, the lower the company’s potential reputation and interruption risk are.
If you are a manufacturer who would like some guidance or assistance in producing a product or system hardening guide, call me (949-831-6788) or email me (RayBernard@go-rbcs.com) and let’s have a discussion about how that might work.