UNIX(ユニックス）の３８年問題へのISMS的対応は済んでますか？
システム担当者、サーバー担当者の間では遠くの昔に話は終わっているはずですが、改めて点検しておきたい警鐘記事が出ていた。
３２ビット版UNIXでは、２０３８年１月に時間カウントが限界を迎える。２０００年問題のUNIX版ということだ。２０００年問題は大山鳴動ねずみ一匹？
しかし、UNIXの場合は始末が悪い。
- １つは、基幹系に利用されているケースが多く、問題が出たら大事になってしまうこと。
- ２つはUNIXは亜流が実に色々あるから対策の範囲が特定し難いということ。
さて、ISMSです。
脅威（脆弱性？）の概要、あるいは脅威の発端となる概要は理解できる。
対策担当者をどのようにアサインすることが出来るか？基幹系サーバーなら 情報システム部門で話は早い。情報システム部門の目が届かないところにリスクは無いのかという話になる。
＜何処に３８年問題が潜むか？＞
- 基幹サーバー：情報システム部門
- 部門サーバー：
- 部門パソコン：パソコンを勝手にサーバー化利用するケース。
- デジタル技術応用機器：コンピューターと思っていないが内部ではUNIX系のコンパクトOSが動いているケース。
- 設備等のコントロールシステム：デジタル機器と認識できるものの姿も見えない可能性がある。納入業者あるいはメーカーに確認するしか無いだろう。
６４ビット版か、既に対策済みか、など。
＜資産価値？＞
発生する状況（情報資産の状況）と被害額の算定。直接、間接に脅威を受ける情報資産の洗い出しを行う。最終的なビジネスインパクト。この算定は、しかし、難しすぎる。
＜対策？＞
脆弱性改善の方法論、必要リソース。優先順位を付けて実施する。影響の大きさ（資産価値？）を理解して 対策を検討する。いつものことだ。
.*.
もし、３８年問題を既に脅威の一つとして検討済みならいいが、リスク（脅威）として捉えていなかった場合は、脅威の洗い出しプロセスに穴が開いていたことになる。２００４年尾銀行ATMトラブルでも予防処置が回らなかったらそのプロセスも問題だ。
今までのは、結果論ではあるが、ISMSに似て非なるものをやっていたに過ぎない 。
.*.
