The Father of TQM Influences Security 50 Years Later
Photo: https://www.toolshero.com/toolsheroes/kaoru-ishikawa/

The Father of TQM Influences Security 50 Years Later

Part 1 - Prevention over Detection

Total Security Management from the Father of TQM

Kaoru Ishikawa (1915-1989) was a Japanese engineer and quality control expert who made significant contributions to the field of quality control and management.

Ishikawa was one of the pioneers of Total Quality Management (TQM) and was a key figure in developing Japan's reputation for high-quality products in the post-World War II era. He is particularly well-known for his development of the Ishikawa diagram, also known as the fishbone diagram or cause-and-effect diagram used to identify the root cause of a problem by organizing possible causes into categories and subcategories.

How Would Ishikawa Approach Cyber Security?

The field of cyber security did not exist during his lifetime. However, based on his approach to quality control and management, I will speculate on some principles that he might have applied to cyber security.

Prevention over Detection

Ishikawa was a strong believer in the importance of prevention rather than detection and correction. He believed that it was better to prevent problems from occurring in the first place than to fix them after the fact. Most of us are thinking prevention in terms of preventing a breach. I contend the intent of prevention is understanding the root cause at the behavioral and process level and perhaps may start with detection first.

Prevention 1st

The foundations of prevention must be holistic and can include many things such as a sound human resource strategy, continuous training, continuous process improvement, design practices, tactical areas such as tool stacks in dev/ops and deployment environments and many more areas. I agree with the prevention first approach. Certainly when you are designing and building a new capability, this should always be a center of focus. I'm a big fan of designing in quality and security. I can't think of anyone reading this would disagree with this time tested approach. Some cultures (Eastern) spend more time perfecting design, resulting in less build time whereas others (Western) are opposite spending less in design but more in build. Either way, complacency, mediocrity and "good enough" are the first enemies of prevention.

Detection Also Yields Prevention

My career in testing offers a different perspective and therefore propose a different approach of "Detection Also Yields Prevention". Nothing is absolute and there are no guarantees. We all do our best to get it right the first time but seeing as though we're all humans, it happens to be the exception and not the rule.

Testing is a unique activity that enables engineering to understand the flaw in their attempts at prevention. These flaws can be in many areas, human resource strategy, training, process, design and tool stacks, etc. The goal of testing is to gain truthful knowledge of the "what" was found by understanding "why" it exists. Only when we understand the "why" can we understand how to re-engage the idea of prevention from what was learned. The notion of continuous testing and/or iterative testing as change occurs allows engineering teams to engage a continuous process improvement methodology. The more such continuous testing is engaged the larger the data set created enabling teams to identify patterns. Such patterns can reveal behaviors, habits, process, execution, environment failures.

I agree with Ishikawa's Prevention over Detection philosophy but far too often I have seen this approach deemphasize the importance detection plays in helping teams understand how to improve and refine their prevention strategies, tactics and execution. Often testing is viewed as a means to an end rather than an activity producing rich data in what process was actually followed versus assumed.

What Detection Looks Like

Below is one chart of many serving as a visual result of testing and detecting security risk. Forget the actual details of the chart and lets focus on the high-level immediate observation. What this tells security professionals is every process designed to identify and mitigate the risks detailed in the radar map have failed and therefore being caught via testing or some other detection process.

DETECTION GRAPH - RADAR MAP

You might be thinking, "Rob...get to the point already!" Detection is a form of prevention with much deeper implications. Testing is often viewed as a final destination before something goes into production. I contend it's a lead measure/indicator of deeper failures in process, behaviors, habits, culture, strategy, etc...

Ishikawa had it right for sure, however I believe looking at prevention as an ideology that occurs only at the beginning of the process is too narrow and should include detection methods such as testing to identify targeted failures which can be continuously improved and is the very essence of prevention.

I will continue to push into other areas of Ishikawa's teachings and philosophy and hope it influences your decisions and strategy on security prevention and detection!

Thanks for reading! Please share with others and post comments on your thoughts.

要查看或添加评论,请登录

Rob Cross的更多文章

社区洞察

其他会员也浏览了