設備保全管理（MOSMS）と見比べて情報セキュリティ管理（ISMS）をちょっとだけ考える
夏休みの宿題的に「MOSMS実践ガイド」を読みました。プラントや工場の保全（点検や修理）に関するガイドブックです。
とてもざっくりいうとISMSが扱う「情報セキュリティ事故」がMOSMSにおける「生産設備の故障」にあたる感じです。分野違いながら内容は両者通ずるところがあるので頭の整理を兼ねてまとめます。
なお私は折悪しく（？）社内のISMS認証取得プロジェクトの推進担当を拝命してしまったところです。
情報セキュリティ周りについては5年ぐらい前にSC受かっただけなのでさほど詳しくないです。
MOSMSとISMSの位置づけの違い
MOSMS（もすむす）は「Maintenance Optimum Strategi Management System」の略で、「企業全体の最適化を図る保全の仕組み」を目指すとしています。
ISMSはITエンジニアの方には釈迦に説法ながら情報セキュリティマネジメントシステム（Information Security Management System）ですね。ISO27000シリーズ（特にISO27001）への準拠を実現するための各種施策・体制を指します。
ISMSは国際規格であるISO（と日本規格のIEC、JIS）が背景にありますが、MOSMSは（公社）日本プラントメンテナンス協会が定める業界の自主的なガイドブックのような位置づけです。そういう意味ではITでいうとPMBOKとかに近い性格のものかもです（詳しくないからしらんけど）。
MOSMSとISMSの共通点
以下のように基本的な思想は共通しています。
どっちかがどっちかに影響与えてるのかとかは存じ上げません。
- 扱うトラブルの位置づけ
- トラブル（情報漏洩 / 設備故障）が起こると事業活動の一部または全部が停止するし信用も損なってやばい
- なのでトラブルが起こる前に芽を摘み取るのがだいじ
- たたかいは上流からすでに始まっている（シフトレフト）
- 組織まわりのこと
- 全社方針としてルールを定めないといけないよ
- 専任の管理チームを置こう（MOSMSでは「情報の統括部署」というのがISMSでいうCERTやCSIRTにあたるっぽい）
- 従業員に周知と教育を
- 運用関連
- 事象のヤバさと発生頻度をもとに評価して優先度をつけよう
- 「動いてるからﾖｼ!!」で放置は害悪
- 隠し事はロクなことにならない。報告できる風土をつくる
- 継続的改善
- 一回ルール整備して終わりじゃなくて良い状態をキープしましょう
- やらかしは分析して次に活かせ
情報セキュリティにも活かせそうなMOSMSの要素
クライシスコミュニケーション
リスクマネジメントの分野では危機管理広報と呼ぶようです。
以下本の抜粋です。
近年、緊急事態の発生時には「安全の確保」とともに「安心の確保」が求められる。
この目的を果たすためには、情報を必要とする人に対して、正確な情報を迅速に伝達することが肝要である。これをクライシスコミュニケーションと称する。（略）
情報はマスコミを通じ瞬時に拡大され、内部情報は常に外部に伝わるという判断のもとに、事故で知り得た事実は全て正確に航海を行うことを原則とすることが信頼につながる。
（MOSMSガイド第2版 p.73-74より）
隠してもいいことないから正直に全部いった方が良いしその準備は普段からしておけって話ですね。
いちおうリスクマネジメント的な部分はISMSにもカスッている気がしますが、標準的な対応事項に有っていいように思います。
トラブルに先回りする予防保全の仕組みづくり
AWSのDCなんかもきっとそうでしょうが、同じ機械を同じような条件で稼働させれば故障の傾向が現れます。稼働時間が一定を超えると故障率が上がるとか、ぶっ壊れる数日前から異音がしはじめるとかです。
で、そうと分かれば壊れる前に計画的な部品交換などを行うことができます。そもそも年間の保全計画にこれら予見できる対応を載せ、計画的にメンテナンスを実施していきます。
- 定期保全：「2年経ったら修理」とか「稼働時間が3000時間超えたら交換」とか
- 予知保全：センサーや計器を使って「空気圧が〇〇を下回ったら対応」とか「振動の大きさが〇〇を超えたら分解点検」とか
脱線（ダブルミーニング）ですが、先日東海道新幹線が止まったトラブルは作業車のブレーキ故障の予知保全基準値を読み違えて適切な対応ができなかった事象のようです。
ITではライブラリのバージョンアップ規則やログ監視・アラート監視で怪しい兆候があった場合の対応ルールの整備が近いかと思います。あとはそもそもちゃんと予防対応の工数を計画に盛ること。
対応しているチームも当然あると思いますが、ISMS的には「サポート切れがないよう順次対応」「WAF/IDSにて監視（なんかあったら都度いい感じに対処します）」ぐらいゆるいルールでも多分審査通せちゃいます。
分析可能な振り返り
設備故障は同じ条件下では当然に再現しえます。汚れが原因でショートを起こしたなら、汚れないようにカバーなりつけるか清掃を徹底するなどしないといつかまたショートします。
MOSMSでは「故障原因分析書」を作成し蓄積、そしてそれらを分析してルールを見直すことを推奨しています。
で、自由記述の報告欄と別に事象分類のための項目をあらかじめ用意しています。
- 故障原因：設計不良 / 材料不良 / 材質不良 / 制作・組立不良 ・・・
- 原因性格：知識の不足 / ルール誤認 / 悪習慣 / 経験不足・無経験 ・・・
のような感じです。
対してITシステム開発の脆弱性や障害の対応って一期一会な扱いの印象です。現場にもよると思いますが私の前職ではそもそもインシデント報告書や障害報告書のフォーマットがなかったのでライブ感で顛末を記していました。これでは類似のトラブルを分類することも難しく、蓄積しても読み物どまりです。
このあたりは事象の発生頻度の違いも大きいのでしょうが、ITやってる側がデータドリブンな分析に使いづらい報告をするのも不思議な感じなので取り入れる余地はあるように思います。
管理境界を明確にする
送電、配水など工場間にまたがる設備についてどこからどこまでが誰の管理範囲というのを定めましょうというはなし。
- 供給側と受取側の棲み分けを明示する
- 「この配電盤よりこっちはウチの工場が保全します」とか
- その境界をテープでマーキングや掲示で明示する
- 「第１工場が供給する電力を第３工場が利用。第２工場は使わないけど敷地内を通過」とかもあり得る
- 日常保全の管理境界と有事の管理境界は別でもいい
- 「この配管の日常点検は敷地の境目からこっちをウチが見ますね。故障時は供給機器の手前まで見ます」みたいな
縄張りを明確にするのは情報セキュリティではあまり見ない気がしますしそのまま取り入れられるものではないとは思います。そもそもアーキテクチャもインフラ構成も結構変わり得るし、境界自体アプリケーションレベルではファジーな感じするし。
とはいえサブシステムの境界で情報管理ルールを使い分けるとか参考にする余地もありそうに思います。
参考にはならないけどMOSMSは大変だなーと思ったところ
最悪シナリオがすごく重い
情報セキュリティの世界では最大限にやらかしてもKADOKAWAしたりベネッセしたり尼崎したりするぐらいである意味影響は限定的です。
ところが設備保全でやらかすと生産が停止するリスクはもちろんのこと
- 労働災害：自社作業員が死傷
- 産業災害：周辺住民やユーザーにまで被害
- 環境被害：有害物質・汚染物質流出
といったところまで行く可能性があります[1]。
産業災害の例
最悪例の一つがカネミ油症事件かと思います。食用油の製造過程で設備故障から熱媒体が漏出して食品を汚染していたという事象です。
環境影響の例
最近の新日鉄（現・日本製鉄）が水路にシアン化物をお漏らしして千葉県に怒られました。報告内容を読む限りタンクの腐食（とその状況の放置）が原因とのこと。人的被害は今のところないそうです。
そもそもやらないと違法になる検査がある
いわゆる法定検査ですね。消防法、労働安全衛生法など様々な法規に従って検査や報告を行う必要があります[2]。
逆にこの辺は情報セキュリティに関する法的な規制が薄い（個人情報保護法と不正アクセス禁止法ぐらい）という印象もあります。個人情報の機密性について法定検査とかあったらものすごく面倒ですが有ったほうが本当はいいのかも。
「絶対に運転停止できない設備」がある
（ITでも業界によってはありえない話ではないですが）
前職の知人から聞いた話では製鉄の高炉なんかが該当するようです。一度止めると再稼働不能。最悪建て直し。
これは日本中でも金額面で最大規模の例ですが、ほかにも事故を起こしてはいけない設備の例としてMOSMSには以下のような内容が載っています（一部）。
- 事故が爆発や環境汚染につながる設備
- 主要部品の納期が非常に長い設備
- プラント全体の停止につながる設備
長期保全計画は20年とかになる
ベンチャーだったら1年後のことすらわからないというのにって感じですね。耐用年数とか考えたら必然ではあるのですが。
その他ちまい話のめも
外部攻撃者は考慮しない
MOSMSはプラントなどの設備保全のためのガイドブックです。そのためか情報セキュリティでは主要なプレイヤー🔪である外部の攻撃者について特に言及がありません。
とはいえ銅線盗まれたりテロリストに設備を破壊されたりもあり得ない話ではないから一応あってもいいのではとは思いました。
あとたぶん時々ヘビとかイタチとかが配電盤に入り込んでショートおこしたりもしますがその予防策とかも言及なかった。
始動直後が高リスクになるのが定番
設備の故障率は始動直後が高く、その後落ち着いてから経年で再び高まります。この故障率曲線はバスタブ曲線と呼ばれます。
情報セキュリティ分野でもこれに近いことは言えそうですが、リリース直後のリスク管理って習った覚えないですね。
もちろん既知の脆弱性を踏むような実装はしないしなるべくレビュー、テスト、静的解析で弾くしリリース直後はしばらく見守りはしますが、あくまで経験知に基づく対応であり情報セキュリティ対応として明文化はされてない気がします。
他にもMOSMSの世界とISMSの世界の細かな違いはたくさんありますがこの辺にしておきます。たまには違う畑の話から学ぶのも理解が深まっていいかもなと感じました。
箸休めの読み物にでもなったら幸いです。
やっぱり夏休み最終日は夜中まで読書感想文でヒーヒー言うに限りますね。
Discussion