NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係(転載)


NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係:働き方改革時代の「ゼロトラスト」セキュリティ(6) - @IT:

NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳

NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係

 SP 800-207は米政府がネットワークやセキュリティのモデルとしてのゼロトラストについて言及する際に、政府標準として扱われるべく提言されたものです。今後、他のSP 800シリーズ同様に、世界中の多くの組織がこのSP 800-207を参考に、ゼロトラストについて議論すると思います。

 今回はSP 800-207から、「ゼロトラストにおける7つの原則」といえる部分を解説していきます。

NISTによる「ゼロトラストにおける7つの基本原則」

 SP 800-207には、ゼロトラストが生まれた背景、基本的な考え方、そして実践の方法がまとめられています。これからゼロトラストを学ぶ上で非常に良質なドキュメントといえるでしょう。
 中でも第2章冒頭に掲げられた、「ゼロトラストにおける7つの基本原則」は、ゼロトラストを実現する上での理想的な考え方がまとめられています。
  1. データソースとコンピュータサービスは、全てリソースと見なす
  2. 「ネットワークの場所」に関係なく、通信は全て保護される
  3. 組織のリソースへのアクセスは、全て個別のセッションごとに許可される
  4. リソースへのアクセスは動的なポリシーによって決定される
  5. 組織が保有するデバイスは、全て正しくセキュリティが保たれているように継続的に監視する
  6. リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される
  7. 資産・ネットワーク・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する
 これらの7つの基本原則をまとめ、以下を満たした状態が理想的なゼロトラストであると提言しています。
  • 全てのリソースへのアクセスの認証と認可がリクエストごとに動的に決定される
  • 全てのリソースの状態が、その判断に用いられる
  • 全てのリソースの機器や通信が保護され、状態が可視化によって監視されている
 では、これらの7つの基本原則について詳しく見ていきましょう。

【1】データソースとコンピュータサービスは、全てリソースと見なす

 アクセスする側/される側に関係なくネットワークに接続されている全ての機器をリソースとして見なします。
 小型のストレージ機器、IoTデバイスなど、あらゆる大きさや機能を持っているデバイスもリソースとして考えます。もちろん、クラウドサービスもリソースの一つとして考えます。さらに、個人が所有している機器であっても組織のリソースにアクセスするのであればリソースとして考えます。

【2】「ネットワークの場所」に関係なく、通信は全て保護される

 この原則における「ネットワークの場所」とは、社内ネットワークやプライベートネットワークといった、一般的に「従来の境界線の内側や外側」とされる範囲を指しています。
 従来の境界型セキュリティモデルでは、ネットワーク境界線の内側は安全であり、暗黙的な信頼を付与していました。ゼロトラストの基本原則では、「セキュリティシステムで保護されたネットワーク境界範囲内であっても、インターネットと同様に利用可能な最も安全な方法で通信を保護すべきである」としています。

【3】組織のリソースへのアクセスは、全て個別のセッションごとに許可される

 従来のネットワークアクセスの考え方では、一度行われた認証や認可を一定時間キャッシュし、パフォーマンスを効率化します。しかし、ゼロトラストでは「全て個別のセッションやリクエストごとに許可されるべき」とされています。さらに、「アクセス時に許可される権限は、そのアクセスに必要最小限の権限にすべき」とされています。
 セキュリティよりもパフォーマンスを優先した設計が招く、横展開によるアクセス侵害を防ぐための、極めて重要なコンセプトです。

【4】リソースへのアクセスは動的なポリシーによって決定される

 従来のネットワークアクセスの考え方では、あらかじめ決められたポリシーによってアクセス許可が決定されていました。例えばユーザーIDとパスワードの組み合わせやクライアント証明書の確認などです。
 ゼロトラストでは、さまざまな属性をパラメーター化し、都度ポリシーに従って計算を行い、アクセスを許可します。下記が要素として扱われます。
  • クライアントの識別としては、ユーザーアカウントや関連属性など
  • デバイスの状態では、インストールされているソフトウェアのバージョンやネットワークの場所、アクセス日時など
  • 振る舞い属性として、ユーザーやデバイスの異常な振る舞いの記録の有無
  • 環境属性として、ネットワークの場所や時間、報告されている攻撃など
 これらの状態や属性を基に、データのリスクレベルに応じて許可すべきアクセスルールを決定し、その一連のセットがポリシーとなります。これらの状態や属性は時間によって常に変化するため、データへのリクエストを行うたびに最新の状態を基にアクセスの許可を決定します。

【5】組織が保有するデバイスが、全て正しくセキュリティが保たれているように継続的に監視する

 この基本原則では、組織内に存在する全てのデバイスがセキュリティを保って正常に動作している状況を監視し、必要に応じてタイムリーなアップデートや修正の実施を求めています。これは、「どのデバイスも本質的には信頼できない」という考えに由来します。
 脆弱(ぜいじゃく)性が発見されているにもかかわらず修正が行われていないようなデバイスを、セキュリティが保たれたデバイスと同じ扱いにしません。組織に接続する個人のデバイスも含めて常に監視を行い、セキュリティを保持することが求められます。

【6】リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される

 従来のモデルでは、ユーザーにおける認証・認可は一度認証された結果の使い回しが想定されていました。再認証によるユーザーの手間の省略やパフォーマンスの向上を求めた結果です。
 しかし基本原則では、現在実行中の通信においても継続的に信頼性の再評価を行い、場合によっては再認証の実施を求めています。

【7】組織は、資産・ネットワークインフラ・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する

 この基本原則では、資産のセキュリティ状況、トラフィックの状態、アクセス要求のログなど、組織のネットワークやデバイスにまつわる情報を常に取得し、さらに分析した結果を活用したポリシーの作成やセキュリティの改善を求めています。
 これは、組織の成長やテクノロジーの進歩によって変化し続ける組織のネットワーク形態やデバイス、ユーザーの利用状況に応じて、ポリシーの作り方やセキュリティの在り方を常にアップデートし続けるという考えです。

ゼロトラストの7つの基本原則と従来の境界型防御

 これらの7つの基本原則は、実現する技術にとらわれない普遍的な書き方です。いままでのネットワークセキュリティの考え方に基づいて提供されているさまざまなセキュリティソリューションが、ゼロトラストにおいても活用が可能なのは、そのためです。
 過去のゼロトラストの議論では、「ゼロトラストは従来の境界型防御を除去する」という部分が強調されてきました。しかし境界型防御の機能は、ゼロトラストを実現する機能の一部として、「マイクロセグメンテーション」「マイクロペリメタ」の形で取り入れられています。
 重要なのは、従来の境界型防御の排除ではなく、これらの7つの基本原則が満たされた状態が理想的なゼロトラストであると定義されていることです。
 また、「Never trust, always verify.」という言葉に代表されるように、暗黙的な信頼をゼロにするために、「全て(All)」という言葉が多用されているのが分かります。
 ただし、これらはあくまで理想的な目標であって、「現実的には全てが純粋な形で完全に実装されるとは限らない」とも書かれています。
 NISTが提言したSP 800-207 Zero Trust Architectureでは、現時点で理想的なセキュリティの姿を基本原則によって定義付けました。またSP 800-207では、これらの原則を実現するアイデアやコンセプトの集まりを「ゼロトラスト」とし、ゼロトラストのコンセプトやアイデアを利用する組織のサイバーセキュリティのプランを「ゼロトラストアーキテクチャ」として説明しています。
 ゼロトラストは、境界型防御の単純な否定ではなく、テクノロジーの進化に沿ったモダンなITアーキテクチャと共存可能なセキュリティコンセプトであると、SP 800-207からは読み解けます。

「データ侵害インデックス」サイト「Cit0day[.]in」で検索する方法 / Cit0day Search Tool(転載)

Cit0day Search Tool:

After my podcast episode about the Cit0day data leaks, my colleague Jesse initiated the idea of making our own search engine. The 23,000 breached databases within this massive leak can be queried on various breach notification sites, but they all simply provided a notice of hit within the Cit0day collection. None of them identify WHICH breached database contains the exposure. We now offer a tool for this. Head over to:

https://breach.myosint.com/

Provide any email address and immediately receive notification of the specific data breach which contains the email address. I present more details on the show tomorrow.

 

JPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開(転載)


sugimu retweeted: 公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…:
sugimu retweeted:
公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…

ーー

JPCERT/CC では、イベントログの分析をサポートするツール「LogonTracer」の最新版バージョン1.5をリリースしました。これまでのLogonTracerは、セキュリティインシデントの事後調査という用途に特化していましたが、リリース直後からLogonTracerをリアルタイムログ分析にも活用したいという要望が多く寄せられていました。そのため、今回のアップデートでは、リアルタイムイベントログ分析を可能にする機能を追加しました。
今回は、このアップデートについて紹介します。その他のアップデート内容については下記のリリースをご覧ください。

https://github.com/JPCERTCC/LogonTracer/releases/tag/v1.5.0

Elasticsearchのサポート

LogonTracerは、Elasticsearchと連携することでリアルタイムログ分析が可能になります。
図1は、LogonTracerとElasticsearchを連携させた場合のイメージです。LogonTracerは、デフォルトではWinlogbeatを使用してElasticsearchに送信されたイベントログをインポートすることが可能です。

LogonTracerとElasticsearchの連携イメージ
図 1:LogonTracerとElasticsearchの連携イメージ

LogonTracerは、Elasticsearchからインポートしたログを分析し、結果をElasticsearchに保存することができます。イベントログを可視化して分析する場合、LogonTracerから確認する必要がありますが、不審なアカウントのランキングやサマライズしたログの分析結果はElasticsearchにも保存されるため、ElasticsearchやKibana上で同様の分析結果を確認することが可能です。
図2は、LogonTracerの分析結果をKibana上で表示した様子です。KibanaのWatcherなどを使用して、LogonTracerからレポートされた不審なログをアラートするように設定しておけば、リアルタイムで異常検知のサポートになります。

LogonTracerの分析結果をKibanaで表示
図 2:LogonTracerの分析結果をKibanaで表示

Elasticsearchからのログインポート

ElasticsearchからLogonTracerにログをインポートには、Web GUIから行うことができます。左下の「Load from ES」ボタン(図3の左)をクリックすると、インポート用の設定画面(図3の右)が表示されます。

Elasticsearchからログをインポートする設定画面
図 3:Elasticsearchからログをインポートする設定画面

Elasticsearchからインポートする際の、さらに詳細な設定(index名など)はコマンドラインから行うことができます。詳しくはLogonTracerのWikiをご覧ください。

https://github.com/JPCERTCC/LogonTracer/wiki

LogonTracerにログをインポートする際の注意

LogonTracerの分析機能の大きなポイントの1つにイベントログの可視化があります。可視化は、ログ分析の大きなサポートになりますが、大規模なログの可視化は、ログ表示の遅延や大規模なグラフを目視で分析することは難しいという問題があります。これは、LogonTracerに限らず大規模な情報を可視化するシステムには、共通する課題です。
そのため、LogonTracerに、長期間(1ヶ月や1年など)のログをインポートすることは、可視化速度の低下につながるためお勧めできません。1週間または1日(適切な期間はホスト数やユーザ数によって異なります)などの間隔で、必要なログをインポートして、分析することを推奨します。
LogonTracerを、ADイベントログの監視に使用する場合は、cronなどで定期的にイベントログを読み込んで分析し、分析結果をElasticsearchに蓄積することで、Kibana上でLogonTracerの分析結果を監視する運用を行ってください。確認が必要なログが見つかった場合、LogonTracerに対象期間のログをインポートしてログの可視化を行うことで、効率的な監視が可能になります。

派遣エンジニアが起こした事件が理不尽だった件(転載)~いろいろな意味で〇ソだなと思った。派遣もシステムもプロパーも会社も、、、。~

どもども。僕はしがない派遣エンジニアです。

某零細企業から、某大手企業に派遣されています。

派遣先はお堅い職場です。

コロナのご時世ですが、リモートの「リ」も聞いたことありません。

万が一、データー漏洩した場合とんでもないことになりますからね(しらんけど

そんな職場ですが、わたくしは2年ほど勤めています。

お堅い職場ゆえに息苦しさもありますが、それが心地よかったりもします。

というよりも派遣という気軽な身分が合っているのかもしれません。

さて本題に。

こんな職場へ、新しい新人さんが入ってきました。

新人といっても50代のベテランエンジニア、Aさんです。

もちろん派遣です。

Aさんはどうにも「優秀ではないエンジニア」のようでした。

かろうじてプログラミングはできるけど、IDEの使い方、フレームワーク等はほとんど経験がないご様子。

何でもかんでもプロパーさんに聞いて回るので、「そんなことくらい自分で調べて!」と怒られていました。

確かにネットで調べれば済むことです。

Aさんはそんな感じの方です。

で、案の定。

着任して3日でドキュメント整理という名の戦力外通告をされていました。

そんな時、事件は起こりました。

会社の役員様から「こんなメールが届いたけど、どうしたらいいの?」とシステム部門に連絡があったのです。

それは決算に関わる重要なメールだけど、身に覚えがないのだそうです。

私のチームがその担当システムだったため、すぐに調査をしました。

その調査中にも、ほかの役員様から「なんだこのメールは?」と問い合わせが入ります。

チームは慌てふためきます。

時間が経つにつれ、経理部のプロパーの方々が駆けつけ、システム部長、経理部長まで駆け付け、一大事になったのは、社内事情に詳しくない僕から見ても明らかでした。

「原因はまだわからんのか!!?」

原因究明は長引きました。

というのも。

その決算プログラムは、15年前に作られたPHPプログラムで、度重なる改修の結果「よくぞここまで!」というくらいのスパゲッティになっていたからです。

社内にシステムの詳細を知る人間はおらず、ドキュメントも歯抜け状態。

プログラムを追うしかない状態でした。

操作ログもほとんどないシステムだったため、難航しました。

チームの派遣3名+プロパー1名は、徹夜で調査。

その結果、1つの仮説が導き出されました。

「あいつがバッチを起動させたのでは?」

「あいつ」というのは、例のベテラン新人エンジニアAさんです。

翌日、出勤してきたAさんは問い詰められました。

もちろんAさんは否定しました。

「私はまだ着任したばかりで、そんなことできっこない」と。

確かにその通りです。

「これをクリックしただろ?」

と、プロパーさんは画面の秀丸を指さしました。

それはシステムのドキュメントでした。

その中に、1つのURLが書かれていました。

プロパーさんはそれを指さしました。

「あぁー、押したかもしれませんね・・・」

そのURLは、決算システムの年次バッチを臨時に走らせる大変恐ろしい物だったのです。

しかも2005年の。

Aさんはプロパーに激詰され、システム部門の臨時会議で罵倒され、経理部門でも罵倒され、役員の方々への謝罪行脚に出かけていきました(プロパーさん、システム部長、経理部長を伴って

Aさんはまだ帰ってきません。

僕はAさんになんて声をかければいいのでしょうか?

そもそもAさんのどこに非があったのでしょうか?

Aさんが支給されたパソコンの秀丸は、ワンクリックでURLを開くようになっていました。

問題のバッチURLは、パスワードも必要なく。

もし誰かに非があるとするならば、秀丸ではないかと思うのです。

■追記

Aさんが罵倒された緊急会議でのこと。

僕はAさんを「凄い人だ・・・」と思いました。

「なんでこんなことしたんだ!」

「どうするつもりだ!」

と、激詰めされているにも関わらず、淡々と回答していたからです。

Aさんはとてつもない強靭な精神力を持つ人でした。

想像してみてください。

コロナにも関わらず、200人以上が常駐している広いフロアの真ん中にあるミーティングスペースで、多くの人がチラ見する中で罵倒される姿を。

会議の出席者の大半が敵であり、仲間であるはずの僕たちは、火の粉が降りかかるのを恐れて何も言えず、たった一人で戦わなくてはいけない状況を。

こんな恐ろしいことはありません。

「どうするんだ!!!?」

「どうやって収めるつもりなんだ!?」

「問題のデータはすでに特定しているので、すぐに修正できるかと・・・・」

「そういうことを聞いてるんじゃない!!!」

システム部長とプロパーさんでそんなやり取りがあった後、

「ご迷惑をおかけした方々に、私が直接謝罪します」と、Aさん。

「えっ・・・、おぅ・・・、それもいいかもな・・・」と、システム部長。

緊急会議はいったん解散し、部長会議が開かれたようで。

その後、Aさんが呼ばれ、謝罪行脚に出かけたのでした。 

--

↓の動画の最後のコメントがすごくイイ



ロシアで宅配便ロッカーを強制解除するサイバー攻撃が発生 / Hacker opens 2,732 PickPoint package lockers across Moscow(転載)


Hacker opens 2,732 PickPoint package lockers across Moscow:

謎のハッカーがサイバー攻撃を利用して、モスクワ中の2,732個の宅配ロッカーのドアを強制的に開けました。

12月4日(金)午後に発生したこの攻撃は、モスクワとサンクトペテルブルク全域で8,000件以上の荷物ロッカーのネットワークを維持している地元の宅配サービス「PickPoint」のネットワークを標的にしています。

ロシア人はオンラインで商品を注文し、注文した商品を自宅の住所ではなく、PickPointのロッカーに届けることを選択できる。

荷物が届くと、ユーザーは電子メールやモバイル通知を受け取り、PickPoint アプリを使って注文を取りに行くことができる。

しかし、ユーザーがロッカーを開けて荷物を受け取ることができる同じシステムが金曜日に攻撃を受けました。

未だ特定されていないエクスプロイトを使って、謎のハッカーが PickPoint のロッカーの 3 分の 1 のドアを強制的に開け、モスクワ全域で数千個の荷物が盗難にさらされました。


攻撃の理由はまだ判明していないが、週末のプレスリリースで、ピックポイントは当局に通知したと述べた。

ロシアの同社は現在、攻撃で被害を受けたネットワークの復旧作業を行っているという。

また、ロッカーから荷物が盗まれたかどうかも不明のままだ。ソーシャルメディアの投稿によると、警備員や家主は金曜日に素早く介入し、明らかに故障しているロッカーへのアクセスを制限した。

同社が土曜日のプレスリリースで強調しているように、これは "ポストゲートウェイネットワークに対する世界初の標的型サイバー攻撃 "であるようです。

【転載】パッチマネジメント とは?方法や必要性、注意点について徹底解説


パッチマネジメント とは?方法や必要性、注意点について徹底解説:

IT企業に限らず、ビジネスでは多くのコンピュータが使われています。そのコンピュータの管理にかかせないのが「セキュリティパッチの更新」です。

セキュリティパッチとはコンピュータに存在する脆弱性を解消するプログラムのことです。マルウェアの感染やセキュリティホールを悪用したサイバー攻撃を防ぐためには、適切なセキュリティパッチの適用が欠かせません。

今回はセキュリティパッチの更新を管理する「パッチマネジメント」について紹介します。

パッチマネジメントとは

パッチマネジメントとは、システムを構成しているコンピュータを管理して、脆弱性が発見されたときに適切にセキュリティパッチを適用させるための管理活動のことです。

セキュリティパッチはコンピュータに見つかった脆弱性を解消するために使用するプログラムです。ソフトウェアの中には、新しいセキュリティパッチが公開されたとき、ソフトウェアアップデート機能により自動的に更新するものもありますが、一部のコンピュータには、手動によるセキュリティパッチの適用が必要なものもあります。

しかしパッチマネジメントの導入により、セキュリティパッチの適用を効率的に漏れなく実施できます。それにより、コンピュータの脆弱性を確実に解決し、不正アクセスやマルウェアの感染のリスクを低減させられるのです。

2018.4.21
セキュリティパッチとは、公開されたソフトウェアで発見された問題点や脆弱性に対し、これらの不具合を解決するためのプログラムのことです。 WindowsなどのOSをはじめとした、お使いのソフトウェアおいて、このセキュリティパッチを更新し

パッチマネジメントの方法

パッチマネジメントは具体的には以下の3つの流れで進めます。

検知

脆弱性情報を公開しているWebサイトから、自社のシステムに関係のありそうな脆弱性情報を集めます。脆弱性情報の情報源には、具体的には以下のようなものがあげられます。

業界団体IPA(情報処理推進機構)
JPCERT/CC
JVN iPedia
NVD
有識者(専門家)Twitter
Facebook
ブログ
その他SNS
ベンダ(製品メーカー)各ベンダのWebサイト
情報配信サービス
プレスリリース
メールマガジン

情報源としては上記3つがあげられますが、これらの情報を取りまとめているニュースサイトもあります。これらの情報を全て追いかけるのは手間がかかるので、自社で使っているソフトウェアや製品に関連する情報だけでも効率良く収集するように工夫しましょう。

判断

自社に関係のある脆弱性が判明したら、そのリスクの大きさと攻撃を受ける可能性を判断して、対策の緊急度と必要性を決定します。

脆弱性の緊急性の判断には「CVSS」を基準に考えるのが一般的です。

CVSS(Common Vulnerability Scoring System)とは

共通脆弱性評価システムと呼ばれ、下記3つの基準で脆弱性を評価する仕組みのことです。

  • 基本評価基準(Base Metrics)
  • 現状評価基準(Temporal Metrics)
  • 環境評価基準(Environmental Metrics)

システムの種類や開発者、評価者などの違いに影響を受けないような、共通の尺度で深刻度を表す指標です。

自社においても脆弱性の深刻度を決定する基準として、CVSSのような指標を使い、あらかじめレベルごとの対応方針を決めておけば、迅速な対応が可能です。

対応

対策方法と対策時期を決めて、脆弱性を悪用したサイバー攻撃が発生する前に、脆弱性のリスクをできるだけ小さくします。しかし複数のシステムが混在している環境の場合、適切に対応されているのか把握しきれないことがあります。

そうならないためにも、複数のシステムを構築する際に、できるだけ共通の基盤を持つサービスを利用することがおすすめです。クラウドサービスの中には、パッチマネジメントの一連の手順を総合的に管理できるものも登場しています。

パッチマネジメントの必要性

包括的なパッチマネジメントを実施する必要性として、以下の2点があげられます。

脆弱性を悪用した攻撃を防ぐ

適切なパッチマネジメントにより、OSやアプリケーションソフトウェアにセキュリティパッチを適用することで、脆弱性を悪用した攻撃を防げます。

コンプライアンスを確保する

セキュリティパッチを適用しないと、コンピュータがマルウェアの感染するリスクが高まります。さらにマルウェアに感染したコンピュータから機密情報や個人情報が流出することで、社会的信用を失いことにもなりかねません。

パッチマネジメントを含めた情報セキュリティ対策は、コンプライアンスを確保する活動とも言えます。自社内のシステムの危険箇所を特定して、不正アクセスや改ざん、マルウェアの侵入を未然に防ぐことで、顧客情報や機密情報を守りことができます。パッチマネジメントは、情報保護ポリシーの実践や法令順守の活動の一環と言えるでしょう。

パッチマネジメントの注意点

パッチマネジメントの必要性はご理解いただけたかと思いますが、実際にはセキュリティパッチの適用が難しいケースもあります。特に以下のような場合は注意が必要です。

システムが多い場合注意

業務で使用しているシステムの数が多い場合、それら全てに対して適切にパッチマネジメントを行うことは困難でしょう。そもそも大規模なシステムの場合、システムで動作しているコンピュータの数ですら、把握できていないこともしばしばあります。また複数の種類の異なるコンピュータが混在している場合は、適用させるセキュリティパッチも異なるため、パッチマネジメントを効率的に行うことが難しくなります。

レガシーシステムに注意

古いソフトウェアで動作しているレガシーなシステムにも注意が必要です。レガシーシステムでは、アップデートのサポートの期限切れや、アップデートできない可能性があります。レガシーシステムといえ、現役で使われていることもあり、簡単には新しいシステムに代替できないこともあります。

パッチテストが必要

最新のセキュリティパッチでも、実際に適用させる前には十分なパッチテストが必要です。しかしそのパッチテストを実施するコンピュータの選定や、業務に影響が発生しないようにテストの時間帯などの調整も必要です。

組み込みシステムに注意

機能が限定された組み込みシステムは、全体を動作させているシステムの一部として動作していることがあります。そのような組み込みシステムは365日24時間動作させていることもあり、停止させてセキュリティパッチを適用させることが困難です。またそのような長期間動作している組み込みシステムは、古いOSが搭載されている可能性もあります。

未知の脆弱性に注意

セキュリティパッチは既知の脆弱性を解消するプログラムです。そのため未知の脆弱性を解決することはできません。未知の脆弱性が知れ渡り、その脆弱性に対するセキュリティパッチが完成するまでには時間がかかります。

まとめ

脆弱性対策にかかせないセキュリティパッチの適用を効率的に実施する、パッチマネジメントについて紹介してきました。

企業内で稼働しているコンピュータの数が多くなってくると、それらを効率的に管理するにも工夫が必要です。パッチマネジメントのために高いコストを投資して、包括的に管理できるシステムを構築できれば理想的ですが、そうは言っても予算をかけられない企業もあるでしょう。

そのような状況でも、自社にとって重要な情報やデータを把握し、システムのクリティカルな箇所から段階的にでもパッチマネジメントを進めていくことがおすすめです。ベンダが提供しているツールなどを有効に活用して、賢くパッチマネジメントを導入しましょう。


「EXILE TRIBE」の公式通販サイトでクレカ情報流出~想定損害賠償額は11億円程度か~


「EXILE」や「三代目J SOUL BROTHERS」など、LDH JAPANに所属するアーティストのグッズを扱う公式オンライン通信販売サイト「EXILE TRIBE STATION ONLINE SHOP」が不正アクセスを受けたことがわかった。

同サイトを運営するLDH JAPANによると不正アクセスにより、8月18日から10月15日までの約2カ月間、決済処理を行うプログラムが改ざんされたほか、個人情報を含むサーバに対してもアクセスを受けた形跡が見つかったもの。

同サイトではクレジットカード情報を保持していないが、期間中にクレジットカード情報を新規に登録したり、変更を行った場合、第三者に情報を窃取されたおそれがある。

4万4663人分のクレジットカード情報が外部に流出した可能性があり、名義や番号、有効期限、セキュリティコードが含まれる。さらに11月27日の時点で、このうち少なくとも209人分のクレジットカード情報が不正に利用をされた可能性があるとの報告をクレジットカード会社より受けたという。

またログファイルの調査により、クレジットカード情報以外の個人情報が格納されたサーバについても不正アクセスを受けていたことが判明した。流出件数などは特定できなかったとしている。