How do you use quality management systems (QMS) thinking to design an information systems management system (ISMS)?  There are a lot similarities.  Read on:

IMHO it starts with two sets of security standards, (a) the manufacturer and (b) the organization.

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

We need to weed out the technologists that insist on flying-by-the-seat-of-their-pants.  They are a risk to the organization exposing 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.  This is reckless and increases exposure to the organization.  It’s impossible to manage quality when nothing is documented, it can’t 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 manufacture’s products that have been tested and meet the organizations 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 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 DQ, IQ, OQ, and PQ based on the bullets above .

These specifications need to be considered as part of the Enterprise Security Architecture during any custom software development or major changes.  Rule number one “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 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 backend so that management can focus resources on problem management and security events and incidents to gather additional intelligence.  An 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 once for everyone by adopting a similar Quality Management approach.  If the developer or manufacturer was facilitating this level of testing they 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.

Bio:

Mark E.S. Bernard, CRISC, CGEIT, CISA, CISM, CISSP, PM, ISO 27001, SABSA-F2

Information Security, Privacy, Governance ,Risk Management, Consultant.  Mark has 24 years of proven experience within the domain of Information Security, Risk, Governance and Compliance.  Mark has led teams of 30 or more as a Director and Project Manager and managed budgets of $5 Million +.  Mark has also provided over sight as a senior manager during government outsourcing contract valued at $300 million and smaller contracts for specialized services for ERP systems and security testing.  Mark has led his work-stream during RFP process, negotiations, on-boarding, contract renegotiation and as Service Manager.  Mark has architected information security and privacy programs based on ISO 27001 and reengineered IT processes based on Service Manager ITIL/ISO 20000 building in Quality Management ISO 9001.   He can be reached at: mesbernard@gmail.com