Designing a Quality Management Approach to Cybersecurity

Designing a quality management approach to cybersecurity starts with two sets of security standards, (1) the manufacturer and (2) the organization.

The manufacturer standards should include the mitigation of security vulnerabilities, (OWASP, CVE), based on a specific configuration within a defined architecture. There are only so many situations in which a network device firewall, router, switch, server, desktop, laptop, handheld can be deployed. The software, enterprise resource planning (ERP), utilities, apps, etc., should also be tested for security vulnerabilities before they are released.

We need to weed out the technologists who insist on flying by the seat of their pants. They can expose the organization to unnecessary reputational risks and potential financial and strategic risks. By not documenting security standards, the organization will be not be able to produce consistent outputs. It is impossible to manage quality when nothing is documented; it cannot be validated or verified.

The organization’s security standards need to define how a network device will be implemented. This usually means that only a select list of manufacturers and products that have been tested and meet the organization’s requirements can be purchased. This also means that the security architecture needs to be documented based on those specifications and business requirements. These specifications need to be meaningful, because they will be tested, verified and validated.

Each device or software product needs to have its security standards documented—again, these need to be meaningful. A risk assessment could help to identify what needs to be documented. I also recommend adopting the ISO 9001 approach to product realization. To be effective, security standards need to be consistently documented in a manner that includes specifications. These specifications are grouped as follows:

• Design—how the device or software fits into the architecture; i.e., internal facing
• Installation—how the device or software will be installed; i.e., configuration
• Operations—how the device or software will be used; i.e., standard operating procedure
• Performance—how should the device or software function; i.e., response times, look, feel, etc.

In quality management, we refer to these specifications as qualifications because they get tested and verified before release. We also call them design qualification (DQ), installation qualification (IQ), operations qualification (OQ) and performance qualification (PQ). These specifications need to be considered as part of the enterprise security architecture during any custom software development or major changes. Rule number one is “No surprises!” The secure software development methodology needs to include specifications for design that eliminate all known vulnerabilities and any organizational attack vectors that are unique to the organization. Any changes need to be retested during the quality assurance (QA) and user acceptance testing phase of development. The QA team needs to include a member from the software side and the technology side.

The results are a fully integrated, seamless approach to managing security vulnerabilities and shutting down those attack vectors. The time spent upfront will save time on the back end, so that management can focus resources on problem management and security events and incidents to gather additional intelligence. The additional benefit is that the security team can more easily detect potential security events and incidents more rapidly.

Organizations should not have to pay out of their own pockets to fix security defects that the manufacturer could have fixed for everyone by adopting a similar quality management approach. If the developer or manufacturer was facilitating this level of testing, it should be able to provide the security standards.
Organizations that purchase products that have known vulnerabilities/defects, nullify their warranties. This increases the organizations’ exposure and liabilities, which means that they will need to carry more insurance and pay for it out of their pockets, further increasing operational costs and lowering revenue because the cost of doing business just got more expensive.

Mark E.S. Bernard, CGEIT, CISA, CISM, CRISC, CISSP, ISO 27001 Lead Auditor

[Source: ISACA]