サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹
ついに平成最後の週となり、週末からは待望のゴールデンウィークです。みなさまのご予定はいかがでしょうか。
私個人は特に大きなイベントは予定しておらず、都内で歌舞伎や美術展鑑賞をするくらいです。ただ、美術展に関しては東京では
30
年ぶりというクリムト展があり、全長
34
メートルの巨大な壁画『ベートーヴェン・フリーズ』のレプリカが展示されるということで非常に期待しています。
そして今年の
GW
で気になることといえば、その長さ。皇位継承をはさむことからカレンダーレベルで日本史上初※の
10
連休となります。※当社調べ
現場レベルでは人とシステムが稼働中の組織も多いと思いますので、ITのインシデントやその他のインシデントが発生しないか気が気でない方もいらっしゃると思います。
ITのインシデントに関して言うと、IPAウェブサイトに
「ゴールデンウィークにおける情報セキュリティに関する注意喚起」
がアップされています。これらを参考にし、GWは安心安全に過ごしたいですね。
外部サイト：
ゴールデンウィークにおける情報セキュリティに関する注意喚起
さて、
IPA
といえば先週
4/19
に
“
「ITサプライチェーンにおける情報セキュリティの責任範囲に関する調査」報告書について
“
という発表がありました。
外部サイト：
「ITサプライチェーンにおける情報セキュリティの責任範囲に関する調査」報告書について
今回はこの報告書について確認していくことにしましょう。
■調査の経緯
IPAが
2017
年度に委託元、委託先間の情報セキュリティに関する取り決めの調査を実施したところ、サプライチェーンにおいて重要なセキュリティに関する責任範囲が不明確であるとの結果が出たところが起点となりました。
そして続く
2018
年度はこの問題の解決に向け、仮説を立てたうえで掘り下げる調査を実施しています。
■サプライチェーンとインシデント
サプライチェーンを利用して広がるインシデントはたとえば「
Wannacry
」等のランサムウェアの蔓延が記憶に新しいところです。
これらのインシデントが発生した時に対応・復旧におけるセキュリティの責任範囲が明確になっていないと対応への着手が遅れることにより影響範囲が拡大し、発生した金銭的インパクトがより大きくなることは既知の事実ではないでしょうか。
その他にも故意か過失かを問わず、納入された機材のソフトウェアやアップデート後のソフトウェアにマルウェアやスパイウェアが仕込まれている等、場合によっては直接の被害だけでなく自社のブランドを脅かすインシデントにも十分注意していく必要があります。
外部サイト：
Wannacry
外部サイト：
ASUS
、
Live Update
を悪用した
APT
攻撃を確認
■今回の調査手法
まず、調査の概要は以下のようになっており、アンケート対象は
800
社を超えることからかなり広範に調査を実施したことがわかります。
（１）調査方法・対象
アンケート調査 ユーザ企業
417
社、
IT
システム・サービス提供企業
428
社
事例調査 ヒアリング 国内ユーザ企業、
IT
企業、有識者 計
10
者
文献調査
34
件
（２）調査期間
2018年
10
月～
2019
年
2
月
（３）実施者
一般財団法人 経済調査会
■調査結果から見る
5
つのポイント
引用先の
IPA
のサイトでは本調査の結果として以下の
5
つのポイントがピックアップされました。
1
．「新たな脅威が顕在化した際の対応」について責任範囲の明記がない割合は
8
割
委託元
が文書で明確にしているセキュリティに係る要求事項
（委託元調査）
2
．責任範囲を明確に出来ない理由は知識・スキル不足が最多で
79.6%
委託元
が責任範囲を明確に出来ない理由
（委託元調査）
3
．
IT
業務委託契約においてリスク低減を目的に複数の対策を実施
委託先
が実施している対策（複数回答）
（委託先調査）
4
．
IT
業務委託契約時に責任範囲を記述している文書は“契約書”が最多
委託元
がセキュリティに係る要求事項を記載した文書（複数回答）
（委託元調査）
5
．責任範囲を明確にするには“契約関連文書の雛形の見直し”が最も有効
責任範囲を明確にするために有効な施策（複数回答）
（委託元調査）
本調査の目的から照らし合わせると
1.はセキュリティの責任範囲が不明確なエリアを可視化
2.は不明確になっている原因の可視化
3.はセキュリティの責任範囲が不明確な契約をせざるを得ない現状に対し「委託先」が実施している対策の可視化
4.は委託元がセキュリティの責任範囲を担保するために利用している根拠文書の実態を可視化
5.でセキュリティの責任範囲を明確するために有効な施策
⇒ 今回の結論
となっています。
大きく分類すると原因である
[1,2]
と実態である
[3,4]
、それに結論である
[5]
という形になります。
セキュリティに限らず、事業、業務の方向性を修正するためのコストは上流から下流に進むにしたがって増加していくものです。原因である
[1,2]
が認識できれば当初の委託契約締結時に知見を持ったセキュリティ専門家によるレビュープロセスを組み込むというアイディアはすぐに出てくると考えられますし、そのプロセスのための人材や予算の不足は
PMO
等での一元対応というやり方もすぐ思い浮かぶのではないでしょうか。
実態である
[3,4]
についてはかなり苦しい現状が見て取れます。
委託先で実施する
[3]
については委託元⇒委託先の力関係がありますし、決まった受注金額にのなかで十分なサポートができる専門家をアサインできるのか、付け焼刃的になってしまわないか疑問が残ります。
委託元で実施する
[4]
については契約書もしくは付随文書へセキュリティの責任範囲を記載することはもちろん重要なポイントですが、必要な付随文書が正しくリンクされているか？また、文書が版数を重ねても正しく最新版とリンクされているか？というところをどのように管理していくかが重要といえるでしょう。
結論である
[5]
については次項に続きます。
■結論 － 契約書雛形について
まとめを見ると結論である
[5]
は原因である
[1,2]
に関する対策ノウハウを雛形・テンプレートに落とし込むことによりセキュリティの専門知識がない担当者少ない、またはいない状況でも一定のレベルを担保する方法として打ち出されているのだと思います。（そもそも雛形で解決可能というのが当初の仮説のようです）
しかしながら、ここではあえて
2
つの懸念事項を提起しておきます。
1つはバリエーションの数、もう
1
つは経年での変化です。
バリエーションについては雛形といいつつ個別契約に合せて様々な派生の雛形を作っていった時に果たしてそれらを専門的知識がない担当者が正しく適用・管理していけるのかどうか？
雛形といいつつ
数があまりにも多いようだと確認と選択の作業が発生することにより実効性が薄くなり本末転倒
です。
もう
1
つの変化について。
急速な技術の進歩に伴い、セキュリティの世界も変化が激しいことはご存じのとおりです。ある時点でノウハウを詰め込んだ雛形を作成したとしても
定期的な見直しは必須
となります。このプロセスを考慮しない雛形は役には立たないでしょう。
半期か年次かはシステムの重要度にもよりますが、その際には必ずセキュリティの専門家が必須となり、当然それに対してのリソースの確保も必須となります。コスト増という考え方に関してはセキュリティの責任範囲が不明確であることによりインシデントが発生したり、被害が拡大した場合の対応費用を算出したうえで、最適な投資額を決定するが必要となります。
■最後に
『最も弱い環の原則』によりサプライチェーン全体のセキュリティレベルはサプライチェーンの一番弱い部分のセキュリティレベルと同等です。少なくとも責任範囲の合意不足によりセキュリティレベルが「ゼロ」となる部分が無いようにしたいものです。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
