ホワイトペーパー

セキュリティ 7つの習慣・20の事例「セキュリティブック」

関連記事

【連載企画第一回】 セキュリティ事故の“ミカタ”

関連記事

【連載企画第二回】自社のセキュリティ対策に“シカク”はないか？（課題の発見）

脆弱性を?ディスる“とは

第二回の連載記事「その課題発見にシカクは？（課題の発見）」では、これまでの業務経験から気を付けるべき以下３つの死角について解説をしました。
・IT業界におけるインシデントの意味
・セキュリティダメージコントロール
・パスワードポリシー
今回のテーマ「脆弱性を“ディスる”」は、やや上品さに欠ける表現です。英単語の接頭語としてのDISがそれに続く言葉の否定的な意味を持つことから、転じて「悪口を言う」「バカにする」といった意味合いで2000年代に入り使用されるようになった比較的新しい言葉であると言えます。元の英単語は『Disrespect；“尊敬を欠くこと”』から“ディスる”が徐々に一般的にも使われるようになったようです。

しかし、前回ご紹介した「課題の発見」の発見を意味する英単語Discoverも、ディス＋カバーであることは案外知られていません。つまり、覆われたカバーをはがすことで、隠れていた新しい事実が“発見”できるのです。まさにカバーをディスるのです。こう考えるとDISはネガティブな意味だけで使われているわけではなく純粋に反対語の意味に使われているわけですね。

さて、英語の話はこのくらいにして、カバーに覆われていた弱点・脆弱性を発見し、今度はそれをディスれば効果的な改善につながるはずです。

現場に潜む「５つの脆弱性」

これまでの連載記事を振り返れば、セキュリティ対策として向き合うべきは、脅威・脆弱性・リスクのうち、脆弱性。
そして、３つのP　People Process Productのうち、ついIT製品；ソフトウェア・ハードウェアあるいはネットワークシステムのProductの脆弱性に着目しがちですが、人やプロセスに潜む脆弱性もあることをお伝えしました。
さらに、
・脅威は制御できない、サイバー攻撃者はゼロにできない（いわば自然界の台風の位置づけ）
・脅威は脆弱性をついてリスクになる（多くの場合、ソフトウェアが古いまま、人間のうっかりミス、運用ルールの不備など）

リスクが顕在化し、コンピューターの制御を奪われたり、意図せず誤操作をしてしまい様々な事故につながります。
そのため、脆弱性に着目して対策を講じることが、事故発生前の対策、医療業界でいうインシデント対応、ヒヤリハットに対応する構図がわかります。

本来ならそれぞれの現場固有の脆弱性を発見し、それに応じた課題解決が必要ですが、これから紹介する「５つの脆弱性」は多くの現場に散見される代表的なものです。必ずしもすべての組織に、当てはまるものではないかもしれませんが、様々な課題解決の糸口として参考にしていただきたいと思います。

では、脆弱性を“ディス”っていきましょう。

脆弱性をディスる その１　パッチ適用はOSのみ対象にしていませんか？

標的型メールには、しばしばPDFファイルが添付されています。それをクリックし開くことでマルウェアに感染してしまうのはAdobe Acrobat Reader を代表とするPDF閲覧ソフトが古いバージョンで、脆弱性が残ったままであることを狙われているからと考えられます。
パッチ管理の対象はWindows UpdateをはじめOSの脆弱性への対応になりがちです。しかし、メール添付のPDF形式のファイルによる攻撃の例が示すとおり、アプリケーションのパッチ管理も同時に重要なのです。OSに比べてアプリケーションは、配布された後、バージョン管理されていないことが散見されます。バージョンチェッカー※などを利用して今利用しているアプリケーションのバージョンが最新のものかを確認したり、この機会に利用していないアプリケーションなどはアンインストールを検討することも大事です。

※バージョンチェッカー　https://jvndb.jvn.jp/apis/myjvn/

これまでの連載記事では、脆弱性はProduct；製品、ハードウェアやソフトウェアに焦点が当たりすぎとお伝えしましたが、やはりまずはここです。

弱点のないソフトウェア・ハードウェアが整っていないと、People:訓練された人で体制を組み、Process:成熟し、例外のないプロセスがあったとしても砂上の楼閣です。

脆弱性をディスる その２　システムのデフォルト値のまま運用していませんか？

PCI DSSはご存知でしょうか。クレジットカードの磁気ストライプ部分から簡単にデータがコピーされる不正、いわゆるスキミングと言われる手段で、偽造クレジットカードが出回る被害が相次ぎました。しかし、現在ではAmazonや楽天の決済手続きでクレジットカードの磁気ストライプ部分をスキャンするといった操作はありません。そのかわりにクレジットカード情報はそのeコマースのサイトで管理されるようになりました。こうなると、今度はサイト側の管理が適切でない場合、クレジットカード情報が不正に利用される可能性があります。こうしたリスクに対応するためにできたセキュリティ基準がPCI DSSです。

PCI DSSには12からなるセキュリティ要件がありますが、要件2では「システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない」とあります。ただ、PCI DSS認定を取らないからといって、デフォルトのままでよいわけではありません。最近のOSではセキュア・バイ・デフォルトと言われるように、OSインストール直後では、必要としないサービスなどは組み込まれないようになってきています。
ところが・・・
最も大切なアカウントにも関わらず、ほとんどの場合　Administratorのままで運用されています。この名前を変更して運用している現場は非常に少ないのではないでしょうか。
OSやアプリケーションの設定を自由に変更できるAdministratorアカウントは一般に特権アカウントと言われますが、もう一つの呼び名があるのをご存知でしょうか？
それはブレーク・グラス・アカウント（Break glass account） と言われるものです。これは、緊急時ガラスを蹴破ってでも、部屋に入り人を救助する意味から命名されたのかと思います。

ところが、この緊急事態用のアカウントが当たり前のように、緊急でもないのに日常で使われているのです。マルウェアを専門に分析している機関の方と会話する機会がありましたが、デフォルトの管理者アカウントであるAdministratorの名前を変更；リネームしているだけで、それを前提とし動作するマルウェアは一定の割合で実行失敗するようです。もちろん、これで完璧に防げるものではありませんが、少しでもシステムの弱点を減らす有効かつコストのかからない対策となります。

脆弱性をディスる その3　ログの活用タイミングは事後前提になっていませんか？

SIEMをはじめとしたログ活用のための製品が出てきた背景は、ログの活用が十分ではなく、システムがダメージを受ける前の段階、つまり攻撃の予兆を確認することが出来ていません。

では、SIEMのような製品を入れない限り、予兆管理はできないのでしょうか？
このことを整理するのに、筆者がよく話題にするのはイベントログと監査ログの違いです。監査（Audit）の原則の理解が非常に大切と言い換えることもできます。
「パスワードの強度が低いです！」　と指摘するためには何が必要でしょうか。それは「基準があること」にほかなりません。パスワードの文字列長8文字以上、英数字記号が混在していることなどの基準があってはじめて監査が可能になります。

ということは・・・監査ログはそもそも基準がなければ監査しようがないのです。しかしこの監査ログもイベントログ同様にとにかく生成だけして「何かあったときに確認するようにしています。」、これが、ほとんどの現場の実態ではないでしょうか。

監査ログの活用は知恵を試されています。よい基準を作る工夫ができれば、予兆管理に使えます。

例えば、攻撃の手口の１つに、組織の一員であるかのように振る舞うためアカウントを秘密裏に作り、それを悪用する不正行為があります。日常の運用として、新人採用や中途採用、派遣社員との契約など必要が発生する“たび”にアカウントを登録する運用だと、不正に作成されたものかどうか判断しにくくなります。しかし、アカウント登録は「毎週金曜夕刻」と決め、週明けからすぐ利用できるようにする運用に改めることが可能であれば、それ以外の時間帯に登録される場合は、「例外処理」か、「不正があった」かのどちらかになります。あくまで例ですので、すべての組織で同じようなことができるわけではありません。

ここでお伝えしたいのは、大きな被害が出てからログを確認するのではなく、基準をきちんと検討しておくと例外が見つけやすくなり、予兆管理に役立つということです。

脆弱性をディスる その４　委託業者に丸投げしていませんか？

最新の技術でシステムをきちんと構築するためには、その分野に強い業者に任せることが一般的です。自組織内で構築するよりも品質も高くなり、開発期間も合理的になるメリットがあります。

建築で比喩すれば、手先が器用な人が日曜大工で自宅を修理することはできるかもしれませんが、新築の家を建てる場合、建築基準法・防災対策・近隣への配慮・多数の建築経験に裏打ちされた匠の技を持つ建築家や大工さんにはかなわないのと同じようなことでしょう。これは、あくまで一般論で今後は傾向が変わっていく可能性がありますが、IT部門を持たないユーザー企業が独自で、大規模なシステムを構築することは難しいです。

そして構築されたシステムの運用も外部に委託されることが多いです。ネットワークやサーバー、最近ではクラウドの知識をもっておく必要もあり、構築同様に運用もIT部門を持たないユーザー企業独自で実施することは難しいです。

しかし、これはあくまで技術的視点で難しいのであり、そのシステムにより会社の業務がどのように効率化しているか、このシステムが正しく運用されないと何が困ることになるのか、そのためには日々どのようなタスクがあるのか、IT専門用語ではなく、ユーザー側の言葉に置き換えた形で運用が正しく行われているのかチェックすることこそ、ユーザー企業の出番のはずです。

すでに過去の事例と思われがちな大規模な情報漏えいを起こした某教育関連企業の事案はまさにこの点において脆弱性があったとも言えます。委託業者にすべて任せ、定期的なチェック体制がほとんどなかったことが原因の１つと考えられます。

犯罪を起こす条件に、“動機・機会・手段（あるいは正当化）”があげられます。

委託業者の担当からすれば、自分はまったく無関心の中で「何をやっても、褒められることもなければ、怒られることもない」状態が続くと、不正を働く、“動機・機会・手段”の条件が徐々にそろっていくことになるのではないでしょうか。

脆弱性をディスる その５　セキュリティがIT運用部門の仕事と位置付けられていませんか？

Administrator をリネームする設定操作、オペレーションは一瞬で設定可能です。Windowsの場合では、以下の画面にさえ推移できれば、ほんの数秒でできます。

しかし、そう簡単に実施できないのです。理由は“うすうす”おわかりでしょう。規模が大きいネットワーク環境ほど、複雑な運用管理を自動化するために、バッチ処理、スクリプトなど多数存在します。そのスクリプトなどに、固定でAdministratorを指定しているので、リネームするといったいどんな影響があるかわからないと懸念されるケースがあります。そのためリネームを躊躇することになるわけです。

皮肉なことに、サイバー攻撃者側の理屈と似ていると思いませんか？　Administrator前提で動作するマルウェアが一定の比率であることに呼応するように社内運用している部門もAdministrator前提で各種ツールが作られているわけです。

もし、スクリプト開発時点で、Administrator前提で作成するのは危険であることが開発者側に知見がありチェック体制があれば事情が変わっていたのではないでしょうか。

ほかにも、情報資産の重要度の定義もIT部門で実施してほしいと依頼されるケースがあります。

本来、情報資産のオーナーにしかわからないことまで、コンピューターシステムはよくわからないからと、社内IT部門にばかり依頼がある（よく言えば頼られ、悪く言えば押し付けられている）実態はないでしょうか。

この流れの延長でセキュリティ検討もIT運用部門へ依頼する傾向はないでしょうか。この連載での筆者の主張の１つは、インシデント対応が事故対応としている傾向になっていることでした。セキュリティ対策は計画時点や設計時点で検討すべきことが重要にも関わらず、構築後のシステムの運用でセキュリティ対策しているところに原因の一端がありそうです。

まとめ

セキュリティを専門としている人からすれば、「ずいぶん基礎的なことを課題解決案として提言しているなぁ。もっと高度なセキュリティ対策、たとえばAIを利用したセキュリティ対策など提言すべきでは？」と感じる人もいるかもしれません。

しかし、現場実態をよく見ていただきたいと重ねて申し上げたいと思います。多くの場合、基本的なことができていないのです。できていない以前に認識がない・知らなかったということも多いです。

前回の連載記事どおり、散らかったIT環境は、いくら最新のお掃除ロボで効率化しようとしてもその性能は半減どころか、何かにひっかかって動かないままになる可能性さえあります。

古くから構築されたシステムの設定を変更するのはリスクがあることが背景にありますが、そろそろ、「現状を維持すること」と「思い切って“あるべき姿”に変更する」のは、どちらのリスクが高いのかを真剣に検討する段階になってきていると思います。

OSのバージョンアップやクラウド移行など大きな変更や変革の時にこそ、今回紹介したような脆弱性を十分に加味した、要件定義や設計・実装を検討していただきたいと思います。

第一回から第三回まで　 現状分析・課題の発見・課題の解決と進めてきました。
第四回はいよいよ最後となりますが「解決案の運用と見直し」について解説する予定です。