パブリッククラウド利用システムにおける
セキュリティ診断

Share

SQAT® Security Report 2019年9月号掲載

雲とネットワークのイメージ図

※本記事は、SQAT®Security Report 2019年 9月号の記事、
「パブリッククラウド利用システムにおけるセキュリティ診断」の一部抜粋になります。

増えるパブリッククラウド利用とセキュリティ事情

クラウドサービスは、自社でサーバを抱える必要がないことから、導入および運用コストが大幅に削減できるため、今や企業ネットワーク環境構築における選択肢の1つとなっており、オンプレミスからクラウドに移行する企業は増えている(下グラフ参照)。その際、スケジュール等の事情によりシステムを見直す余裕がなく、そのままの状態で移行せざるを得ないケースもあるのが実情だろう。しかしながら、開発や改修後のリリース前にシステムの脆弱性診断を実施すべきであるのは、クラウドへの移行時も例外ではない。

クラウドサービスの利用状況

出典:総務省「平成30年通信利用動向調査の結果」(令和元年5月31日公開)

自組織が業務用のパブリッククラウド(AWS、Microsoft Azure等)を利用している場合、ハードウェアまではクラウド事業者が管理しているが、OSおよびそれより上の層については利用企業側に責任があることを忘れてはならない。パブリッククラウド上のWebアプリケーションやECツール等で使用しているOS、ミドルウェア、アプリケーションといった各コンポーネントは、経年により脆弱性が発見される宿命だ。セキュリティ対策として、定期的にそれらを更新する必要がある。

オンプレミスと同様、パブリッククラウド上にシステムを構築している場合も、自組織のシステムが情報漏洩や改竄、DoS攻撃等の被害に遭う危険性があるかどうか、適宜把握しておく責任がある。このため、パブリッククラウド上のシステムにおいても、定期的に脆弱性診断を実施するのが望ましい。

パブリッククラウド向け脆弱性診断の必要性

パブリッククラウド向けでない一般的なリモート診断では、ファイアウォール越しで実施するため、ファイアウォールでアクセスを許可しているポートに対してしか診断できない。これに対し、パブリッククラウド向け診断では、直接アクセスできるセグメントに対して実施するため、管理用ポート等、ファイアウォールでアクセス制限されていることの多いポートに対しても診断可能だ。

インシデントのリスクは、外部に公開されたシステムにとどまらないことを忘れてはならない。例えば、AWSを社内インフラとして使用している企業があるとする。そういったシステムは (…続き)


本記事はここまでになります。

この記事の続きでは、テレワークの隙を狙った攻撃の脅威をご紹介し、それに対して企業がどのように脆弱性対策に取り組むべきかということについて解説しています。ぜひご一読ください。

※参考(続き)
contents
3.CISベンチマークを利用したセキュリティチェックの必要性
4.診断を受けるにあたっての注意点

下記より無料でダウンロードいただけます。

まずは無料で資料をダウンロード

年二回発行されるセキュリティトレンドの詳細レポートをダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。

 


セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー



 

Share

ニューノーマルに求められる脆弱性対策

Share

SQAT® Security Report 2021年春夏号掲載

テレワークをする女性(アイキャッチ画像)

※本記事は、2021年3月公開SQAT®Security Report 2021年 春夏号の記事、
「巻頭企画:ニューノーマルに求められる脆弱性対策」の一部抜粋になります。

株式会社ブロードバンドセキュリティ
高度情報セキュリティサービス本部 本部長 大沼 千秋

去る2020年は、新型コロナウィルス感染症(COVID-19)のまさに世界規模なパンデミックにより、我々の生活ばかりでなくビジネスをも大きく変革させた一年だった。中でもテレワーク、リモートワークといった遠隔による勤務形態の整備は、従来様々な理由から普及が伸び悩んでいたが、ここ一年ほどの間で加速度的に普及しつつある。また、ビジネスにおけるIT環境も、クラウドシフトが一気に進行している。

従来のオンプレミス型からクラウド型へのシステム構築・運用環境の移行は、様々な企業のIT戦略において、優先度の高い課題といえるだろう。そして、テレワーク、クラウドシフトが進んでいく中で、新たなセキュリティ上の問題が顕在化してきていることも事実だ。特に、急ピッチでこれらの環境を整備し、運用開始しているケースでは、以前よりもサイバーセキュリティ脅威および危険性は増大しているといっても過言ではない。本稿では、アフターコロナにおけるニューノーマルを見据えた企業における脆弱性対策に焦点を当て、どういったことを推進していくことが必要か解説していきたい。

テレワークとクラウドシフトに伴う脅威

企業のネットワークやOAシステムといったITインフラには、既に様々なセキュリティ対策が講じられているものと思われる。このセキュリティ対策の大原則は、インターネットとの境界を防御するという考え方に基づいており、ファイアウォールによるアクセス制御、攻撃検知のための侵入検知・防御システム(IDS・IPS)、DMZ(DeMilitarized Zone:非武装地帯)を用いた公開システムの区分、安全なWeb閲覧のためのWebプロキシ、マルウェア対策ツール、EDR(Endpointo Detection and Response)による監視、といった対策を組み合わせることによるセキュリティの確保を意味する。

ところが、昨今のテレワーク、クラウドシフト(左下・右下グラフ参照)で在宅による業務環境の提供が不可欠となったことにより、社内の環境は一定のセキュリティが確保されているので安全である、という前提が崩れてきている。本来であればインターネットから接続できない各種業務システムへのアクセス許可や、業務における各種情報を共有するためのクラウドストレージサービスの利用、営業活動における情報管理のためのCRM(Customer Relationship Management:顧客管理システム)の導入や、グループウェア等に代表されるSaaS型クラウドサービスの活用等といった具合に、業務システムが様々な領域へと進出し、多様化してきていることから(下イメージ)、セキュリティ対策としては一箇所だけを守っていれば安全である、という常識は既に覆っていると考えて間違いない。

例えば、テレワーク導入を急ピッチで進めている中で、 (…続き)


本記事はここまでになります。

この記事の続きでは、テレワークの隙を狙った攻撃の脅威をご紹介し、それに対して企業がどのように脆弱性対策に取り組むべきかということについて解説しています。ぜひご一読ください。

※参考(続き)
contents
2.ゼロトラストによるセキュリティの確保
3.セキュリティ状態の可視化と有効性評価
4.ニューノーマルに伴うセキュリティのあり方

下記より無料でダウンロードいただけます。

まずは無料で資料をダウンロード

年二回発行されるセキュリティトレンドの詳細レポートをダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。

 


 

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー



 

Share

Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

Share

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。 本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版(OWASP Top 10 2017)から4年ぶりの更新となります。

※OWASP(Open Web Application Security Project)…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –アクセス制御の不備
A02:2021 –暗号化の不備
A03:2021 –インジェクション
A04:2021 –NEW セキュアでない設計
A05:2021 –セキュリティ設定のミス
A06:2021 –脆弱かつ古いコンポーネントの使用
A07:2021 –識別と認証の不備
A08:2021 –NEW ソフトウェアとデータの整合性の不備
A09:2021 –セキュリティログとモニタリングの不備
A10:2021 –NEW サーバサイドリクエストフォージェリ(SSRF)

NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

● セキュアでない設計(Insecure Design)
  ポイント:設計における管理策の欠如、ロジックの検証が不十分である等
  推奨対策:シフトレフトによる開発ライフサイクルの実践 等
● ソフトウェアとデータの整合性の不備(Software and Data Integrity Failures)
  ポイント:安全でないデシリアライゼーション、
  信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備 等
  推奨対策:データの整合性チェック、コンポーネントのセキュリティチェック、
  CI/CDのセキュリティ対策

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト(Shift Left)について、詳しくは過去記事「前倒しで対処 ー セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法(アジャイル開発手法等)が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI/CDの説明図

CI(Continuous Integration)は継続的インテグレーション、CD(Continuous Delivery)は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会(JIPDEC)プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」(2021年10月15日更新)より

CI/CDパイプラインにおける検証不備によるリスク

コードカバレッジツールへのサイバー攻撃の概要図

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです(右図参照)。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます(下図参照)。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
 Security Assurance Requirements for Linux Application Container Deployments
 https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
 OWASP Application Security Verification Standard
 https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター(NISC)
  情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
  https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー



 

Share

人という脆弱性
~ソーシャル・エンジニアリング攻撃~

Share

SQAT® Security Report 2020-2021年 秋冬号掲載

特殊詐欺のイメージ画像(電話・お金・メモ)

※本記事は、2020年10月公開SQAT®Security Report 2020-2021年 秋冬号の記事、「人という脆弱性~ソーシャル・エンジニアリング攻撃~」の一部抜粋になります。

ここ数年、ソーシャル・エンジニアリングを用いた攻撃による大規模な事件が多数発生している。

・2015年に発生した日本年金機構の大規模な情報漏洩事件*1
・2017年の大手航空会社が3億8000万円をだましとられた事件*2
・2018年の暗号通貨の不正送金事件*3
・2020年7月に起きた大手SNSの大規模アカウントハック事件*4

これらはすべてソーシャル・エンジニアリングを用いた攻撃に端を発しているといわれている。ソーシャル・エンジニアリングを用いた攻撃の高まりを受けて、IPA(独立行政法人 情報処理推進機構)が「ソーシャル・エンジニアリングを巧みに利用した攻撃の分析と対策」*5 を発表したのが2009年であるが、10年以上が経過した今も、ソーシャル・エンジニアリングを用いた攻撃は、収まる気配がない。それは、ソーシャル・エンジニアリングが持つ、人間という脆弱性を狙う性質に原因がある。
ここでは、今一度、ソーシャル・エンジニアリングと人間とのかかわりを考えていきたいと思う。

攻撃者の目線

サイバー攻撃を行う場合、攻撃者はいくつかの手段を選択することができる。その選択肢の中で、システムの脆弱性を攻撃して目的の情報を盗みだすことよりも、人間を狙って攻撃する方が、少ないコストで多くの利益を得ることができると、彼らはときに考える。それが、人間という脆弱性を狙った攻撃、つまりソーシャル・エンジニアリングを用いた攻撃である。ここでは人間をシステム全体に対する脆弱性ととらえて、解説と対策を語っていきたい。

ソーシャル・エンジニアリングとは?

そもそも、ソーシャル・エンジニアリングとは何なのだろうか? ソーシャル・エンジニアリングフレームワークの第一人者と知られるクリストファー・ハドナジー(Christopher Hadnagy)氏は、著作『ソーシャル・エンジニアリング』(日経BP社)の中で、ソーシャル・エンジニアリングを「人を操って行動を起こさせる行為。ただし、その行動が当人の最大の利益に適合しているか否かを問わないこともある」と定義づけている。これには警察官、弁護士、医師といった人々が、標的当人の利益となるように誘導するといったケースも含まれているが、一般的にサイバー攻撃におけるソーシャル・エンジニアリングとは、不正アクセスするのに必要なシステム情報、アカウント、パスワード、ネットワーク・アドレス等を正規のユーザあるいはその家族、友人などから人間の心理的な隙や、行動のミスにつけ込んで手に入れる手法と位置付けられることが多くなっている。ソーシャル・エンジニアリング攻撃の定義は様々なものがあるが、その共通するところは、人を介して攻撃を行うという点である。

人が持つ心理的脆弱性

では、なぜ人が脆弱性となってしまうのか、この点について、原因の一つとなっていると考えられる、人に存在する心理的脆弱性を見ていきたい。ハドナジー氏は人には以下のような8つの心理的脆弱性が備わっていると主張している。

返礼
人からの親切に対し、お返しをせずにはいられない特性

プレゼントのお返しに、何かしてほしいことはないかと聞く。

義務感
社会的、法的、道徳的に、人がなすべきだと感じている行動をとってしまう特性

身体が不自由な人に、積極的に手を差し伸べなくてはならないと考えて寄付を行う。

譲歩
何かを譲ってもらったら、同じように譲らなくてはならないと考える特性

相手の大きな要求を最初に断ったのだから、次の小さな要求には応じてあげたいと考える。


本記事はここまでになります。

この記事の続きでは、こちらでご紹介した以外にも、人に対する過度なストレスを与える攻撃、など心理的弱みを突く攻撃「ソーシャル・エンジニアリング」のメカニズムを徹底解説しています。 ぜひご一読ください。

※参考(続き)
contents
4.人へのバッファオーバーフロー攻撃
5.人間の隙をつくソーシャル・エンジニアリング攻撃
6.テクノロジーが人間を追い詰める
7.ソーシャル・エンジニアリングに対する防御
8.おわりに

下記より無料でダウンロードいただけます。

まずは無料で資料をダウンロード

年二回発行されるセキュリティトレンドの詳細レポートをダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。

 


 

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー



 

Share

暗号技術を安全に活用するために
―今、やっておくべきセキュリティ対策―

Share

暗号技術は、私たちの安全なシステム利用や事業継続のためにかかせないテクノロジーです。しかし、とりあえず導入しているからそれでよい、というわけではなく、ただしく実装されているかを確認したうえで、環境・リスクに応じて適切に実装することが求められます。本記事では、暗号技術を安全に活用するために、必要なポイントを解説し、やっておくべき現状確認についても紹介いたします。

現代の暗号技術の2大課題

暗号技術は情報セキュリティを支える重要な技術の1つです。暗号技術があればこそ、私たちは安心して業務システムを利用し、インターネット経由での事業活動を行うことができています。

一方で、今、次世代暗号に関する話題が、少しずつ一般的なニュースでも取り上げられ始めています。なぜ、次世代暗号技術が求められているのでしょうか。その背景には、既存の暗号技術に対する次のような懸念があるためと考えられます。

量子コンピュータの脅威に対抗:耐量子暗号

将来、コンピュータの処理能力の進化によって、現在普及している暗号技術が無力化されてしまうと言われています。これは昨今よく取りざたされている、量子コンピュータの登場に起因しています。量子コンピュータは量子力学を計算過程で用いて並列計算を実現することで、現在のコンピュータと比較して圧倒的な処理能力を保持するとされています。

量子コンピュータの登場による既存の暗号技術への脅威、そしてその対策は以下のとおりです。

※公開鍵暗号、共通鍵暗号については後述

量子コンピュータは2030年には実用化されると想定されているため、その頃にはサイバー攻撃者が量子コンピュータを用いた攻撃を実行してくる恐れがあるということになります。これが、「暗号の2030年問題」と言われるものです。このため、2030年に先駆けて、防御策を実現する必要があります。そこで、耐量子暗号の選定や鍵長ポリシーの見直し、といった次世代暗号に向けた標準化が、日米において進められています。

暗号技術の標準化動向

●米国:NIST(米国立標準技術研究所)
 →2022年頃の標準化を目指す
●日本:CRYPTREC(暗号技術検討会(総務省・経産省))
 →各種タスクフォース等により調査検討中
  NISTと同等の時期での標準化を目指す

NISTによる標準化検討で挙げられている耐量子暗号の最終候補には、以下のようなものがあります。そう遠くないうちに確定されることでしょう。

暗号化とデータ活用の両立:高機能暗号技術

従来の暗号技術は、
●データの秘匿:保管している内容が第三者にわからないようにする
●改竄の防止:メッセージ認証等、内容が書き換えられていないかチェック
●認証:なりすましが行われていないか電子証明書による確認
●通信の安全性確保:ネット上で流れるデータ内容が第三者にわからないようにする
といった機能に特化したものです。  

そして、データの照合や分析といったデータ活用時の処理は平文(データが暗号化されておらず、誰が見ても内容がわかる状態)で実施しているのが現状です。このため、データ処理者に対する平文データへのアクセスを許容せざるを得ず、結果として、業務上の利便性等の都合により、暗号化されていてしかるべき重要情報が平文のまま保存されているといった実情があります。結果、内部犯行はもちろんのこと、外部からの不正アクセスを受けた場合に、平文の重要情報が盗取されてしまう恐れがあるわけです。

これに対し、従来に加えて付加的な機能がある暗号技術の総称が、「高機能暗号技術」です。

なかでも、暗号化したまま演算処理できる「準同型暗号」は、今まさに、実装ライブラリについての国際標準化推進活動が進行中です。準同型暗号のような高機能暗号技術が実用化されれば、クラウドサーバ上における暗号化したままでのデータ照合や分析、個人情報や機密データを秘匿したままでの様々な処理の実現といった、セキュリティが保持されたデータ活用に期待が持たれています。

現在主流の暗号方式の種類

さて、次世代暗号技術のことを述べてきましたが、ここで、従来の暗号技術、すなわち現在主流の暗号技術について確認してみましょう。現在使用されている暗号技術は以下のとおりです。

暗号方式特徴主な用途主な暗号種別
共通鍵暗号 暗号化も復号も同じ鍵を使用
→処理が高速
→鍵の管理が煩雑
ファイルの暗号化DES
Triple DES
RC5
AES
公開鍵暗号 公開鍵と秘密鍵を作成して暗号化と復号で異なる鍵を使用
→セキュリティ強度が高い
→鍵の管理が容易
→処理は低速
共通鍵の鍵配送
電子署名
電子証明書
RSA
DSA
DH(Diffie-Hellman)
ECC(Elliptic Curve cryptosyste:楕円曲線暗号)
ハイブリッド暗号 共通鍵暗号の受け渡しには公開鍵暗号を、データ自体の暗号化には共通鍵暗号を使用
→安全性が保たれたうえで高速な処理が可能
SSL/TLS(HTTPS通信)鍵交換:DH
暗号化:AES、Camellia

共通鍵暗号と公開鍵暗号を組み合わせた「ハイブリッド暗号」には、身近な利用例として、SSL/TLSがあります。HTTP通信をSSL/TLSによって暗号化するHTTPS通信です。共通鍵暗号と公開鍵暗号のそれぞれの長所を組み合わせることで、セキュリティ強度の高い暗号化を実現し、通信の安全性を高めています。

暗号化されていないデータに伴うリスク

このように、暗号技術は情報セキュリティの基盤技術として、インターネット通信、電子署名、ファイルやデータベースの暗号化等に活用され、安全な事業活動に寄与しています。

ここで気をつけたいのが、通信上を流れるデータには注意を払っていても、自組織内で保存する重要なデータが平文のまま、というケースです。これは、ビジネス上の非常に大きなリスクとなり得ます。ここでは主に二つのリスクが考えられます。一つ目は、攻撃者の侵入を許してしまった場合、使用可能な状態の情報にアクセスを許してしまうことによる情報漏洩のリスク、二つ目が内部による犯行を誘発するリスクです。過去には実際に、保存データが平文であったことで深刻な情報漏洩となってしまった例が存在します。

暗号化されていなかったことにより個人情報が漏洩した事例

2020年
通販サイト(日)*6
約6,300件漏洩
パスワードを平文で保存
2020年
カード決済事業者(米)*2
約250万件漏洩
クレジットカード情報を平文で保存
2019年
ファイル送信サービス(日)*3
約480万件漏洩
パスワードを平文で保存
⇒サービス終了
2018年
航空会社(中)*4
940万件漏洩
バックアップファイルを平文で保存
⇒多額の制裁金等
2017年
信用情報機関(米)*5
約1億4,500万件漏洩
ユーザデータを平文で保存
⇒格付け引き下げ、
多額の制裁金等
2014年
通信教育会社(日)*6
約3,500万件漏洩
内部関係者による犯行
⇒刑事裁判での過失責任認定等

仮に攻撃者の侵入を許してしまったとしても、暗号化でデータを保護することによって、情報漏洩の被害を防ぐことが可能です。また、ランサムウェアの二重脅迫*7や、内部犯行に対しても暗号化は有効です。

安全な暗号技術導入のために必要なポイント

では、取りあえず暗号技術を導入していれば安心かというと、決してそんなことはありません。

暗号化を実装したつもりで、実はこんな状態になっている、ということはないでしょうか。

●一部の個人情報や機密情報といった重要情報がHTTP通信で送信されている
●サーバ証明書が期限切れである
●信頼できない認証局SSL/TLS証明書を使用している
●危殆化した暗号アルゴリズムや鍵長を利用しているプラットフォームがある
●ソースコードに独自の暗号化関数(またはライブラリ)を実装している
●ソースコードにおいて暗号鍵がハードコード(※)されている

※ハードコード… 本来、ソースコード内には記述すべきではない処理や値を直接書き込むこと。(例:税率など)動作環境や利用条件に応じて処理や値を変更する場合、対応が困難になる。

例えば、前述した「ハイブリッド暗号」で触れたSSL/TLSの実情について見てみましょう。IPA(独立行政法人情報処理推進機構)が2020年7月に発行した「TLS暗号設定ガイドラインv3.0.1」では、暗号化通信のプロトコルバージョンについて、TLS 1.2とTLS 1.3のみ推奨としています。Chrome、Firefoxといった主要ブラウザもTLS 1.1までのバージョンをすでに無効化しています。しかしながら、TLS 1.1以下をサポートしているサイトがいまだ全体の4割程度存在することがわかります(グラフ参照)。たとえブラウザで無効化されていたとしても、攻撃者がブラウザを経由せずサーバを攻撃する恐れがあるため、TLS 1.1以下の接続を許容すること自体がリスクとなります。早急にTLS 1.1以下での接続可否を確認し、接続が可能な場合は対処を実施するべきです。

自組織の現状確認、最新の暗号技術動向の把握に努め、環境・リスクに応じた適切な暗号技術の実装を行う必要があるでしょう。

安全に暗号技術を活用するためにやっておくべきこと

せっかくコストをかけて暗号技術を導入していても、適切に実装できていなければ宝の持ち腐れになってしまいます。まずは自組織の暗号化実装がセキュリティ対策として実効性のあるものか、現状の確認を行うことを推奨します。

例えば以下のような観点でチェックすることが必要です。

環境・システムへの暗号化実装による実効性確認のポイント

●プラットフォーム
●Webアプリケーション
●API
●スマホアプリ
●クラウドサービス

確認方法の例

●システム脆弱性診断
●PCI DSS準拠チェック
●ソースコード診断
●クラウド設定チェック(CISベンチマーク、ベストプラクティス適合度)
●ペネトレーションテスト

現状、適切な暗号技術の実装がなされていれば、来る次世代暗号技術への移行準備を実施する段になっても、スムーズに対応することができるでしょう。

参考情報:暗号化実装に関するガイドラインの紹介

■電子政府における調達のために参照すべき暗号のリスト
(CRYPTREC暗号リスト)(最終更新:2021年4月1日)
 総務省・経済産業省
 https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r6.pdf

■TLS 暗号設定ガイドライン(2020年7月)
 IPA(独立行政法人情報処理推進機構)・NICT(国立研究開発法人情報通信研究機構)
 https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-3.0.1.pdf

■暗号鍵管理システム設計指針(基本編)(2020年7月)
 IPA(独立行政法人情報処理推進機構)・NICT(国立研究開発法人情報通信研究機構)
 https://www.cryptrec.go.jp/report/cryptrec-gl-3002-1.0.pdf

■SP 800-57 Part 1: Recommendation for Key Management: Part 1 – General」(2020年5月4日)
 NIST(米国立標準技術研究所)
 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

■SP 800-175B: Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms(2020年3月31日)
 NIST(米国立標準技術研究所)
 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175Br1.pdf


 

セキュリティレポート資料ダウンロードページボタン

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらから
お気軽にお問合せください。


 

SQAT® Security Serviceページへのバナー

 

BBSecコーポレートサイトへのバナー



 

Share

中小企業がサイバー攻撃の標的に!
Webサイトのセキュリティ対策の重要性
―個人情報保護法改正のポイント―

Share
PCのイラストとプロテクトマーク

2022年(令和4年)4月1日に改正個人情報保護法(令和2年改正法)の全面施行が予定されています。いま、攻撃者にとって格好のターゲットとなるWebサイトを狙ったサイバー攻撃は、大企業のみならず中小企業も狙われており、サイバーセキュリティに対する意識が低いなどセキュリティ課題が明らかになっています。本記事では、個人情報保護法改正の全面施行に向け、改正点を解説し、最新のサイバー攻撃の種類と手口、セキュリティ対策を改めて整理します。

サイバー攻撃や組織における管理またはシステムの設定不備・不足等が原因となり、個人情報を含む機密情報の漏洩事故および事件が相次いで発生しています。東京商工リサーチの調べ*8によれば、2020年に上場企業とその子会社で個人情報漏洩または紛失事故・事件を公表したのは88社、漏洩した個人情報は約2,515万人分とされています。個人情報の漏洩または紛失事故・事件は年々増加の傾向にあり、同社の調査結果を見ても2020年は社数では最多、事故・事件の件数は2013年に次いで過去2番目に多い水準となっています。

出典:東京商工リサーチ「上場企業の個人情報漏えい・紛失事故」調査(2020年)

改正個人情報保護法への対応

個人情報の保護においては、2022年(令和4年)4月1日に改正個人情報保護法(令和2年改正法)の全面施行が予定されています。また海外でも法の整備が進んでおり、日本企業と関連性の深いところでは、例えば8月にブラジル個人情報保護法(LGPD)、2022年6月頃にタイ個人情報保護法(PDPA)の施行があります。多くの組織にとって、自組織やサプライチェーン内の関係組織かを問わず、国内外における個人情報保護体制の整備・見直しが必要であり、改正個人情報保護法への対応は重要課題の一つといえるでしょう。

個人情報保護法改正のポイント

個人情報保護法の主な改正点は以下のとおりです。

また、これら以外ではデータの利活用が促進されることもポイントです。この観点からは「仮名加工情報」について事業者の義務が緩和されることと、情報の提供先で個人情報となることが想定される場合の確認が義務化されることが定められました。企業のWebサイトでは利用者の閲覧履歴を記録する仕組みとしてCookieを使用し、デジタルマーケティング等に活用しているところも多いでしょう。Cookieにより取得されるデータは他の情報と照合するなどして個人の特定につながり得るため、保護を強化する声が高まっていたこともあり、改正個人情報保護法では取り扱いに慎重を期するよう求めています。

中小企業を狙ったサイバー攻撃

Cookieのみならず、Webサイトでは個人情報や決済情報など、様々な機密扱いの重要情報を取り扱っていることがあります。それらが漏洩する事故・事件が発生した場合、組織は金銭的損失や信用失墜に陥るだけでなく、個人情報の所有者(本人)から利用停止・消去請求があった場合には「情報資産」も失う可能性があります。

サイバー攻撃においてWebサイトが格好のターゲットであることはご存知のことでしょう。また、攻撃者に狙われるのは大企業ばかりではありません。経済産業省からの報告資料*2によれば、全国の中小企業もサイバー攻撃を受けていることが明らかになっています。というのも、中小企業の多くは大企業に比べてサイバーセキュリティに対する意識が低く、被害者になると考えていないことから攻撃を受けていること自体に気付いていなかったり、セキュリティに対する知識や対策に必要な資源が不十分であるために原因の特定や対策の実施が困難だったりするためです。

独立行政法人 情報処理推進機構(IPA)が2021年3月に公開した「小規模ウェブサイト運営者の脆弱性対策に関する調査報告書」では、小規模Webサイトの運営およびセキュリティ対策、さらには脆弱性対策の実態を調査したアンケート結果とそれに対する見解が述べられています。

IPAが調査の中で、サイバー攻撃の対象となり得る、脆弱性を作りこむ可能性があるWebサイトの機能・画面を選定し、それらが実装されているかを確認したところ、「ユーザによるフォームの入力(問合せ、掲示板等を含む)」が56.5%、「サイト内の検索と結果表示」が36.9%、「ユーザへのメール自動送信」が36.9%、「入力された情報の確認のための表示」が34.6%で上位を占めました。なお、これらはWebサイトの規模の大小にかかわらず多くのWebサイトに共通して実装されている機能・画面であり、当社の脆弱性診断でも検査の対象となっているものです。

Webサイトのセキュリティ対策において、脆弱性を可能な限り作りこまない設計となっているか、脆弱性を発見するための情報収集や検査は実施しているか、対応するための体制や仕組みはあるか、といった事柄はとても重要になります。

中小企業がより危険視されているのは、こうした事柄を実現するための「人員が足りない」「予算が確保できない」といった課題(下図参照)があり、さらにセキュリティ対策に関する知識不足や、意識の甘さがあることからサイバー攻撃のターゲットになりやすいことが理由に挙げられます。また、脆弱性に関する知識についても、情報漏洩につながる危険性のある「SQLインジェクション」や「OSコマンドインジェクション」等について具体的な内容を知らないという回答が約50%~60%に上りました。

出典:IPA「小規模ウェブサイト運営者の脆弱性対策に関する調査報告書」

サイバー攻撃の種類と手口

サイバー攻撃は多種多様なものが存在しますが、最近では特に次のような攻撃が大きな問題となっています。

① 分散型サービス運用妨害(DDoS)攻撃
  攻撃対象に対して複数のシステムから大量の通信を行い、
  意図的に過剰な負荷を与える攻撃
② ランサムウェア攻撃
  データを暗号化したり機能を制限したりすることで使用不能な状態にした後、
  元に戻すことと引き換えに「身代金」を要求するマルウェアによる攻撃
③ ビジネスメール詐欺
  従業員や取引先などになりすまして業務用とみられる不正なメールを送ることで
  受信者を欺き、金銭や情報を奪取する攻撃
④ Webサービスからの個人情報窃取
  Webサービス(自社開発のアプリケーションや一般的に使用されているフレームワーク、
  ミドルウェア等)の脆弱性を突いて、個人情報を窃取する攻撃
  ※前段で触れた、情報漏洩につながる危険性がある
  「SQLインジェクション」や「OSコマンドインジェクション」もこれに分類されます。

それぞれの攻撃の目的および手口や対策の例を以下にまとめました。金銭的利益は攻撃目的の大半を占めますが、それ以外を目的とした攻撃も多数確認されています。その他代表的な攻撃や目的については、「サイバー攻撃を行う5つの主体と5つの目的」で参照いただけます。

Webサイトの脆弱性対策

改正個人情報保護法の全面施行に向けて、組織は個人情報をさらに厳格に管理する必要があります。前述のとおり、6か月以内に消去する短期保存データも「保有個人データ」に含まれるようになるため、例えば、期間限定のキャンペーン応募サイトなども今後は適用範囲内となります。公開期間は短くとも、事前にしっかりとセキュリティ対策の有効性を確認しておく必要があるでしょう。

情報の安全な管理を怠り流出させた場合、それが個人情報であれば罰則が適用される可能性があり、取引先情報なら損害賠償を要求されることが想定されます。また、ひとたびセキュリティ事故が起これば、企業の信用問題にも陥りかねません。

2021年3月にIPAが公開した「企業ウェブサイトのための脆弱性対応ガイド」では、脆弱性対策として最低限実施しておくべき項目として以下7つのポイントを挙げています。

(1) 実施しているセキュリティ対策を把握する
(2) 脆弱性への対処をより詳しく検討する
(3) Webサイトの構築時にセキュリティに配慮する
(4) セキュリティ対策を外部に任せる
(5) セキュリティの担当者と作業を決めておく
(6) 脆弱性の報告やトラブルには適切に対処する
(7) 難しければ専門家に支援を頼む

脆弱性対策を行うためには、まずWebサイトに脆弱性が存在しているかを確認することから始めましょう。脆弱性診断を行い、Webサイトのセキュリティ状態をきちんと把握することで内包するリスクが可視化され、適切な対応を講じることが可能となります。また、Webサイトの安全性を維持するには、定期的な診断の実施が推奨されます。定期的な診断は、新たな脆弱性の発見のみならず、最新の攻撃手法に対する耐性の確認やリスク管理にも有効です。

セキュリティ対策を外部の専門業者に依頼する場合に、「技術の習得や情報の入手・選別が難しい」といった課題もあります。弊社では昨年8月に「テレワーク時代のセキュリティ情報の集め方」と題したウェビナーで、情報収集の仕方やソースリストのご紹介をしておりますので、ぜひご参考にしていただければと思います。

Webサイトは、いまや企業がビジネスを行う上で不可欠なツールの一つとなっている一方で、安全に運用されていない場合、大きな弱点となり得ます。脆弱性対策を行い、セキュリティ事故を未然に防ぐ、そして万が一攻撃を受けた際にも耐え得る堅牢なWebサイトを目指しましょう。


セキュリティレポート資料ダウンロードページボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


SQAT® Security Serviceページへのバナー

BBSecコーポレートサイトへのバナー



Share

ランサムウェア最新動向2021
―2020年振り返りとともに―

Share
PCの画面と南京錠

昨年11月の記事「変貌するランサムウェア、いま何が脅威か -2020年最新動向」では、最近のランサムウェアは「Ransomware-as-a-Service」(通称「RaaS」)と呼ばれる形態が主流となっている、という現状をお伝えしました。本記事は2021年に新たに登場した様々な特徴や攻撃バリエーションを持つランサムウェアの最新情報をご紹介するとともに、2020年のニュースを振り返り、改めてランサムウェア対策に有効な対策を考えます。

ランサムウェア感染を招くマルウェア「Emotet」の猛威と終焉

ボット型マルウェアEmotetは、メール添付ファイルを主とする手法で感染させたPCのメールアカウントやアドレス帳などを窃取して感染拡大を図り、さらなるマルウェアに感染させるという多段階攻撃を行っていたことが確認されています。このため、Emotet感染をトリガーとするランサムウェア攻撃を多く生み出しました。

2019年から2020年にかけて世界的な流行を見せたEmotet*3は、2021年1月、欧州刑事警察機構(Europol)と欧州司法機構(Eurojust)を中心とした欧米各国による共同作戦「Operation LadyBird」によって制圧されました。*2

残存するEmoteの影響は?

Emotetインフラは無害化されましたが、その脅威がなくなったわけではありません。制圧前にすでに感染していた端末が多数存在する可能性があるためです。実際、各国法執行機関からの情報によると、制圧後の2021年1月27日時点で、日本のEmotet感染端末による約900IPアドレスからの通信が確認されたとのことです (下図)。

JPCERT/CCのEmotetに感染端末の数の推移を示したグラフ

すでに感染している場合、端末やブラウザに保存された認証情報、メールアカウントとパスワード、メール本文とアドレス帳データの窃取、また、ランサムウェアなど別のマルウェアへの二次感染といった被害が発生している恐れがあります。

Emote感染端末への対応

2021年2月5日以降、感染したコンピュータ名の情報も提供されるようになったため、総務省、警察庁、一般社団法人ICT-ISACは、ISP(インターネットサービスプロバイダ)各社と連携してEmotet感染端末の利用者に注意喚起する取組を実施しています。*3該当する通知を受けた場合にとるべき対応は次のとおりです。

◆ JPCERT/CC「マルウエアEmotetへの対応FAQ」を参照の上、
  EmoCheckにより感染有無を確認し、感染していた場合はEmotetを停止させる
◆ メールアカウントのパスワードを変更する
◆ ブラウザに保存されていたアカウントのパスワードを変更する
◆ 別のマルウェアに二次感染していないか確認し、感染していた場合は削除する

「情報セキュリティ10大脅威 2021」(組織編)
でランサムウェアが1位に

IPA「情報セキュリティ10大脅威 2021」組織向け脅威のランキングの表

ランサムウェアに話を戻しますと、独立行政法人情報処理推進機構(IPA)より発表された「情報セキュリティ10大脅威 2021」(組織編)で、「ランサムウェアによる被害」が1位に躍り出ました(昨年5位)。以下のような実情が脅威度アップにつながったと考えられます。

● 「二重の脅迫
  (暗号化+情報の暴露)」の台頭
● 特定の標的を狙った進化型の登場
● 新たな攻撃手法による標的対象の拡大

ランサムウェアによる二重の脅迫

身代金要求の条件として、従来の「データの暗号化」に加えて、暗号化前に窃取した「データの暴露」という2段階の脅迫を行う手法です。

米国セキュリティ企業はじめ、複数の企業を襲ったMaze、新型コロナウイルスの話題に便乗したフィッシングメールなどにより各国政府やインフラ事業、教育機関を中心に被害をもたらしたNetwalker。そして、暗号化による脅迫のみで使用されていた従来のランサムウェアの数々も二重の脅迫を行うようになり、実際にデータが暴露されるに至ったケースも見られます。*4「暴露型」は、もはやランサムウェアの常套手段となりました。

特定の標的を狙った進化型ランサムウェア

不特定多数に対するばらまき型でなく、特定の企業・組織を狙った標的型攻撃ツールとして使用する手法です。

2020年6月に国内自動車メーカーの社内システムが、EKANSの攻撃を受け、日本を含む各国拠点で一時生産停止に陥るなど大きな被害がありました。*5同インシデントの調査を行ったセキュリティ企業によると、同社の社内ネットワークで感染拡大するよう作りこまれていたことが確認されており、*6当該企業を狙った標的型攻撃だったことがわかります。

続く7月には、別の国内自動車メーカーの取引先が、Mazeに感染した*7と報じられ、同自動車メーカーを標的としたサプライチェーン攻撃であることがうかがえました。

さらに、2020年11月に公表された国内ゲームメーカーに対するRagnar Lockerによる攻撃では、二重の脅迫の結果、攻撃者により相次いで情報が公開(暴露)されました。最大約39万人分の個人情報流出の可能性があるとした報告の中で同社は、「オーダーメイド型ランサムウェアによる不正アクセス攻撃」と述べており、*8これもまた、巧妙に仕組まれた標的型攻撃といえます。

新たな攻撃手法をとるランサムウェア

様々な特徴や攻撃バリエーションを持つランサムウェアが新たに登場しています。以下に紹介するのは、そのほんの一部です。

Avaddon
2020年国内宛に
多数のスパム拡散を確認
Nefilim
主にMicrosoftのRDPの
脆弱性を突いて
重要インフラを狙う
Tycoon
VPNツールの不備を突いて
教育機関や政府機関を攻撃
Egregor
停止したMazeの後継ともいわれ
世界の大手企業が次々被害に
EKANS
制御システムを停止させる機能で
製造業など工場系に特化
DoppelPaymer
重要インフラへの被害急増にFBIも注意喚起

ランサムウェアは手を替え品を替え、次々に新種や亜種が生まれ続けています。例えば、2021年3月、Microsoft Exchange Serverについて報告された4件のゼロデイ脆弱性*9を利用したサイバー攻撃が活発化しましたが、その中の1つに、中国に関係する攻撃グループによる新種のマルウェア「DearCry」を利用したキャンペーンがあり、主に米国やカナダ、オーストラリアに存在する多くの脆弱なメールサーバが感染の被害を受けたとされています。

ランサムウェア市場の活況

2020年における世界のランサムウェアの被害額は200億米ドルに及ぶとするデータ*10があり、ここ数年、うなぎのぼりです(棒グラフ)。要求される身代金は1件平均17万米ドルにのぼるとの調査結果(2020年)*11も公表されています。

ランサムウェアを活発にしている原因の1つに、RaaS(Ransomware-as-a-Service)の存在が挙げられます。2020年のランサムウェア攻撃における攻撃元の6割以上をRaaSが占めているとするデータ*12もあります(円グラフ)。

Group-IBによるランサムウェア調査レポートの棒グラフ(ランサムウェア被害額)と円グラフ(ランサムウェア攻撃元)

専用サイトやコミュニティにより、犯罪グループなどにランサムウェアを提供して互いに利益を生み出す市場が成り立っています。金額、技術、サービスのレベルは様々で、単にランサムウェア自体をリースや売買するだけでなく、身代金ステータスを追跡できる仕組みや犯罪を実行するにあたってのサポートなども提供されている模様です。技術的なスキルがなくても容易にランサムウェアを拡散させることができるほか、カスタマイズを通じた亜種の誕生にもつながっていると思われます。

企業が行うべきランサムウェア対策とは?

2021年、ランサムウェアは実質的にサイバー攻撃手段第一の選択肢となっており、その脅威がますます高まることは間違いありません。では、組織・企業はこれにどう立ち向かえばよいのでしょうか。

ランサムウェアを含むマルウェアの感染経路は様々ありますが、総務省が中心となって運用するマルウェアの感染防止と駆除の取組を行う官民連携プロジェクト「ACTIVE(Advanced Cyber Threats response InitiatiVE)」では、以下のように分類しています。

マルウェアの感染経路の分類タイプ(Web閲覧感染型・Web誘導感染型・ネットワーク感染型・メール添付型・外部記憶媒体感染型)
出典:ACTIVEホームページ (https://www.ict-isac.jp/active/security/malware/)

こうした感染経路や本稿で紹介したような手口に対する防御、および感染した場合を想定した以下のような対策が重要です。

◆ 標的型攻撃メール訓練の実施
◆ 定期的なバックアップの実施と安全な保管(別場所での保管推奨)
◆ バックアップ等から復旧可能であることの定期的な確認
◆ OSほか、各種コンポーネントのバージョン管理、パッチ適用
◆ 認証機構の強化
  (14文字以上といった長いパスワードの強制や、多要素認証の導入など)
◆ 適切なアクセス制御および監視、ログの取得・分析
◆ シャドーIT(管理者が許可しない端末やソフトウェア)の有無の確認
◆ 標的型攻撃を受けた場合に想定される影響範囲の確認
◆ システムのセキュリティ状態、および実装済みセキュリティ対策の有効性の確認
◆ CSIRTの整備(全社的なインシデントレスポンス体制の構築と維持)

ランサムウェア特有の対策もさることながら、情報セキュリティに対する基本的な対策が欠かせません。また、セキュリティ対策は一過性のものではなく、進化し続けるサイバー攻撃に備えて、定期的に確認・対応する必要があることも忘れてはならないでしょう。

BBSecランサムウェア総点検サービスへのバナー


セキュリティレポート資料ダウンロードページボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関するお問い合わせボタン

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


SQAT® Security Serviceページへのバナー

BBSecコーポレートサイトへのバナー



Share

テレワーク導入による開発現場での課題
―セキュアプログラミングの重要性―

Share

セキュアプログラミングは、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、セキュリティの観点からみても重要な考え方です。特に、テレワーク環境では、エンジニアとの連携が困難になり得るため、必要以上に手戻りが発生しがちです。そこで、本記事ではセキュアプログラミング開発のための推奨対策をご紹介します。なお、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方「シフトレフト」についてもご参考ください。

企業のソースコードが流出

2021年1月下旬から2月上旬にかけて、プログラム開発プラットフォームのGitHub上で大手金融機関を含む複数の国内企業に関するソースコードの一部が公開されるというインシデントが発生しました。各被害企業からは、セキュリティ上の問題はない旨コメントされたとの報道でしたが、中には公的機関のものと思しきコードも含まれていたと想定され、ネット上が騒然となりました。

ソースコードを公開したのは、元委託業者のエンジニアでした。転職において自身の年収を査定するWebサービスを利用するため、実績として当該ソースコード群を公開状態でGitHubにアップしてしまったとのことです。

サプライチェーン問題とリテラシー問題

このインシデントの原因は、悪意の有無に関係なく、業務でソースコードを作成した者が容易にそれを持ち出せた点にあります。そこには、大きく2つの問題があると考えられます。

・サプライチェーン問題
 委託元が委託先(もしくは再委託先)でソースコード流出が発生しないような仕組みを整備できていないこと、および開発状況を監視できていないこと
・リテラシー問題
 委託先か自組織かにかかわらず、開発従事者がソースコードを持ち出して保持したり、どこかにアップしたりしても問題ないという認識であること

※サプライチェーンとは、製品やサービスがユーザに届くまでのすべてのプロセスとそれに関わるすべての企業・組織を指します。

GitHubの利用禁止は解決にならない

事態をうけて、一般社団法人コンピュータソフトウェア協会(CSAJ)と日本IT団体連盟はそれぞれ、GitHubの利用に関する要請*13を発表しました。主なポイントは以下の3点に集約されます。

1. GitHubの利用自体を禁止することは解決にならない
2. 委託先と委託元が協力し合い、サプライチェーンの把握が必要
3. クラウド・バイ・デフォルト原則ではクラウド利用者側の使い方、設定、
   リテラシーが重要

GitHubはソースコードのレビュー、および開発プロジェクト進行の課題解決を効率的に行えるクラウドサービスです。その利用自体はソフトウェア開発産業の促進に不可欠であるとした上で、サプライチェーンの問題(上記2)とリテラシーの問題(上記3)に触れています。

コード流出対策としては、「GitHub設定の定期的なチェック」「委託先企業の厳密な管理」「インシデント対応体制の整備」ということになるでしょう。

サプライチェーンの弱点が狙われる

サプライチェーンの把握については、近年、繰り返し警鐘が鳴らされています。2021年1月、独立行政法人情報処理推進機構(IPA)より発表された「情報セキュリティ10大脅威 2021」 では、「サプライチェーンの弱点を悪用した攻撃」は、昨年に引き続き4位にランクインしています。

大企業のセキュリティが堅牢になればなるほど、関連している中小企業のセキュリティホールが狙われる、という皮肉な構図が浮かび上がります。一カ所でも弱点があると、サプライチェーンに含まれる全企業・組織に危険が及ぶ恐れがあります。

テレワーク導入拡大における懸念

サプライチェーンにおけるリスク管理を困難にしている要因の1つが、テレワークの拡大です。「情報セキュリティ10大脅威 2021」第3位には、新たに「テレワーク等のニューノーマルな働き方を狙った攻撃」が登場しました。

IPAによる「ニューノーマルにおけるテレワークとITサプライチェーンのセキュリティ実態調査」中間報告 で、委託元企業のテレワーク導入経験が約5割であるのに対し、委託先IT企業の方は9割以上であることが明らかになりました。このギャップは、テレワーク環境により目の届かないところで作業されているという、委託元の不安を増大させています。

委託元と委託先の相互協力が必須

日本のあらゆる業種において見受けられる「多重下請け構造」は、ソフトウェア開発においても例外でなく、委託・再委託なしでは成り立たないのが現状です。

委託先を原因とするインシデントであっても、例えばソースコード流出により重要情報が漏洩する被害が発生した場合、実際に企業・組織名が報道され、社会的信用を失墜する恐れがあるのは委託元です。委託先に対する管理の甘さによりインシデントを招いた責任から免れることはできません。委託先も、インシデントを引き起こしたとなれば、取引停止等、事業の存続自体が危ぶまれる恐れもあります。委託元と委託先の両方がダメージを受けてしまうのです。

発注側である委託元の経営者が「セキュリティは投資」という認識を持ち、開発に必要な人員や期間、環境等のリソースを考慮した上で、委託先と互いに協力し合う必要があります。具体的には以下のような対策が挙げられます。

さらに活発化するOSS

また、ソフトウェア開発の潮流の1つにオープンソースソフトウェア(OSS)の活用があることも、注意すべきポイントです。世界のソフトウェア開発組織によるオープンソースコンポーネントのダウンロード数は、一社平均で年間37万超に上る*2とのデータがあります。同時に、OSSプロジェクトに対するサイバー攻撃は前年比4.3倍に増加している *3とのことです。

ここ数年、日本においても、企業ばかりでなく、東京都が新型コロナウイルス感染症対策サイトのソースコードをGitHubで公開したり、総務省が住民情報システムのOSSによる開発を行うことを決定したり―といった具合に、政府や自治体もOSS採用を加速させています。

管理策として、ソフトウェアBOM(ソフトウェア部品表)の作成*4が推奨されます。製造業における部品明細と同様の考え方で、アプリケーションで使用されているOSS、各種コンポーネントやフレームワークについて可視化しておくのです。これらの情報を集約してアップデートを継続しておくと、OSSにおけるコンプライアンス問題の対策にもなります。

セキュアプログラミングの必要性と推奨対策

テレワーク時代のソフトウェア開発を取り巻く現状を見てきました。テレワーク環境では、エンジニアとの連携が困難になり得るため、開発チームのマネジメントに課題があります。また、担当者間や組織間での連携が薄まると、納品物に対するチェックが不十分となったり、必要以上に手戻りが発生したりすることで、完成したソフトウェアにセキュリティ上の問題が存在してしまう原因となり得ます。ソフトウェアの安全性を確保するため、改めてセキュアプログラミングの必要性を認識することが重要です。プログラムが意図しないデータを受信した場合も想定し、サイバー攻撃に耐えうる、脆弱性を作りこまない開発を可能にするため、以下のような対策を推奨します。

リテラシー教育
 ポリシーの整備やセキュリティ教育・訓練の実施は、組織全体のリテラシー向上に必要です。実施には、ノウハウがあり、信頼できるセキュリティ企業の力を借りるのが有効です。
・ツールによるソースコード診断
 開発のあらゆるタイミングで手軽にソースコードの安全性と品質の検査ができるのが、ツール診断の強みです。早期の段階からチェックし、コード単位で解消していくことで、結果的に一定のセキュリティ標準を満たすことができます。
セキュリティエンジニアによるソースコード診断
 効率的で網羅的なツール診断に加えて、より精度を上げるため、専門家による判断が必要な脆弱性の検出を行います。脆弱性を解消した状態で、安心してリリースに臨むことができます。
開発プラットフォームの設定確認・検査
 リポジトリとコードへのアクセスを許容するユーザを厳格に制限すると同時に、設定ミスがないことを継続的に確認する必要があります。開発プラットフォームとしてクラウドサービスを利用するにあたりセキュリティ設定に不安がある場合は、セキュリティ企業による検査を受けておくと安心です。
開発環境における監視
  コードリポジトリに対して監視を行い、不審なデータや挙動がないか定期的にチェックすることで、うっかりミスや悪意による改変をいち早く検知することができます。

まもなく年度末です。開発プロジェクトのラストスパートを迎えている企業・組織も多いことでしょう。テレワーク環境では、インシデントの検知・対応に混乱が生じることも予想されます。今一度、セキュアなアプリケーション開発を肝に銘じていただけましたら幸いです。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。




Share

SQLインジェクションの脆弱性、企業が問われる2つの責任とは

Share

この記事では、XSS(クロスサイトスクリプティング)と並ぶ、Webアプリケーションの代表的脆弱性といえる「SQLインジェクション」について解説します。

XSSとSQLインジェクションの違いや、SQLインジェクション攻撃が実際に行われるまでの手口、セキュリティ会社がどのようにSQLインジェクションの脆弱性の有無を判断しているかなどを解説します。また、SQLインジェクションを放置した責任を企業が問われた裁判の判決も紹介し、最後にSQLインジェクションの対策方法を考えます。

SQLインジェクションとは

「SQLインジェクション」とは、データベースを操作する「SQL」という言語を悪用して、Webアプリケーションの入力フィールドに悪意のあるSQL文を入力するなどして行うサイバー攻撃のことです。SQLインジェクション攻撃によって、なりすまし、Webサイトの改ざん、あるいはデータを盗んだり破壊したりといったことが可能になります。

XSSとSQLインジェクションの違い

もうひとつの代表的な脆弱性であるXSSは、Webサイトにアクセスしているユーザに対して攻撃を行います。一方、SQLインジェクションは、攻撃対象がユーザではなくデータベースです。データベースに登録されている全てのデータが攻撃対象になり得るという点で、SQLインジェクションの方が、被害が発生した場合の規模がより大きくなる傾向があります。管理者にとって見つかったらとても嫌な脆弱性のひとつです。

SQLインジェクション攻撃が行われる仕組み

SQLとはデータベースを操作するための言語です。MySQL、PostgreSQL、Oracleなど、さまざまなデータベースで広く使われており、これらのデータベースは、すべてSQLインジェクションの攻撃を受ける可能性があります。

「Shodan(ショーダン)」というちょっと変わった検索エンジンでは、Webサイトのコンテンツではなく、インターネットに存在するコンピュータやIoT機器を探せるのですが、このShodanで「sql」と検索すれば、サーバヘッダに「SQL」が入ったコンピュータやサーバの一覧が山ほどリストアップされます。

サイバー攻撃者は、しばしばこうした情報をもとに標的を探し出し、一覧の中から、SQLインジェクションの脆弱性が放置されているサーバをさまざまな方法で絞り込み、攻撃を実行します。

脆弱性診断の現場でSQLインジェクションはどのぐらい見つかるのか

弊社が実施しているWebアプリケーション脆弱性診断の2020年上半期統計(14業種延べ533企業・団体。4596システムの診断結果)では、SQLインジェクションは、検出される全脆弱性(システム全体の83.9%)のうち1%ほどとなっています。被害が発生した場合のインパクトが極めて大きな脆弱性ですので、これは決して小さい数字であるとは言えません。

SQLインジェクションを検出する方法

一般的なやり方としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断します。こうした文字列を「診断文字列」と呼ぶことがあります。ちなみに、SQLインジェクションの脆弱性が存在する場合に、個人情報の取得ができるかどうかまでを実際にやってみるのがペネトレーションテストです。

SQLインジェクションの脆弱性を突かれた被害事例、企業が負う2つの責任

SQLインジェクションの脆弱性への対策を怠った結果、Webサイトが攻撃を受けて被害が発生してしまった場合、企業はどのような責任を負うことになるのでしょうか。

運営責任

あるショッピングサイトの被害事例からご紹介しましょう。このサイトでは、SQLインジェクションによる攻撃を受け、クレジットカード情報を含む最大10万件の個人情報が漏えいしました。その結果、営業停止による機会損失に加え、顧客に対する賠償用買い物ポイントの付与、お詫び状送付、被害者対応、インシデントの調査などに多くの費用がかかりました。

これは、欠陥を含むシステムを運営していた代償であり、「運営責任」を問われたかたちです。

開発責任―東京地裁判決より

続いて、運営責任ではなく、システムの「開発責任」を問われた例として、2014年にあった裁判の判決(平成23年(ワ)第32060号)をご紹介します。

とある企業の依頼で開発、納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性が存在し、その結果、不正アクセスによる情報漏えい事故が発生しました。開発を依頼した側の企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として裁判に訴えました。東京地方裁判所はそれを認め、開発会社には約2,200万円の損害賠償支払いが命じられました。

SQLインジェクションはより過失度が大きい脆弱性

情報漏えいとは? 代表的な原因や求められる対応策」で解説していますが、どんな情報が漏えいしたかによって、情報漏えいの深刻度は異なります。たとえば、メールアドレスとセットでそれに紐付くパスワードも漏えいしていたとしたら、メールアドレスのみが漏えいした場合と比べ、事態はより深刻です。

そして、データベースに保存されるのは重要な情報ですから、そこを攻撃対象とするSQLインジェクションは、対策の優先順位が非常に高い脆弱性だといえます。対策を怠り、事故を招いた場合、社会やユーザからは非常に厳しい目が向けられるでしょう。

たとえば、納品したオンラインショッピングのシステムにSQLインジェクションの脆弱性が存在していたら、上述のように債務不履行、納品物の瑕疵とみなされ、SQLインジェクションの脆弱性を放置したままWebサイトを運営していたら、管理義務を果たしていないとみなされる可能性があるのです。

さらに言えば、Webサイトの開発責任が他社にあり、他社から賠償を受けられたとしても、Webサイトの運営側ではエンドユーザに対してなんの申し開きも立ちません。たとえばこれは、食中毒を出したレストランが、顧客に対して「傷んでいた食材を納品した卸業者が悪い」と言えないのと同じことなのです。

SQLインジェクション対策

重要な情報が集まるデータベースは、守るべき優先度がきわめて高く、SQLインジェクション対策としてさまざまな取り組みが行われています。

まず、DevSecOpsの考えのもとでセキュアコーディングを行ったり、開発段階で脆弱性が作り込まれていないかソースコード診断を行ったりすることは、コストパフォーマンスの高い、きわめて有効な対策です。

さらに、近年、SQLインジェクションをはじめとするWebアプリケーション脆弱性に対処する仕組みが、アプリケーションやミドルウェア、開発環境側で整いつつあります。脆弱性のあるWebアプリケーションへの悪意ある通信をブロックするWeb Application Firewall(WAF)の普及も進んでいます。

2021年現在、最新のアプリケーションと開発環境を用いて新規にWebアプリケーションを開発するなら、たとえセキュリティを意識せずに開発に取り組んでいたとしても、SQLインジェクションの脆弱性が作り込まれることは少なくなってきているといえるでしょう。

しかしながら、すべての開発会社が最新の環境で開発を行える、ということはありません。DevSecOpsも、開発の考え方としてはまだ新しく普及はこれからという面があり、また、ソースコード診断を行うことができるような予算やスケジュールを確保できないことも多いでしょう。さらに、開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。

こうした実情に対して有効なのは、Webアプリケーションの定期的な脆弱性診断です。SQLインジェクションによるリスクを考えると、これはサイトを運営するならばぜひとも実施すべき対策、といえるでしょう。

まとめ

  • SQLインジェクションとはデータベースを操作する「SQL」という言語を悪用して行うサイバー攻撃、あるいはその脆弱性のことです。
  • Webサイトにアクセスしているユーザを狙うXSSと違って、Webサイトに登録済みのデータを狙うSQLインジェクションでは、より規模の大きい被害が発生する傾向があります。
  • 多くのデータベースではSQL言語が使われており、それらのデータベースはすべて潜在的にSQLインジェクションの攻撃を受ける可能性があります。
  • SQLインジェクション攻撃では、大規模な個人情報漏えいが起こる可能性が高く、そうなった場合、企業は運営責任を問われます。
  • SQLインジェクションの脆弱性を作り込んでしまった会社に損害賠償を命じる判決が下されたこともあります。
  • 最新の環境で開発を行えば発生しづらくなってはいるSQLインジェクションですが、リスクはゼロではありません。定期的な脆弱性診断は有効性の高い対策と考えてよいでしょう。

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

金融機関はサイバー攻撃を前提とした備えを
―リスクを最小化するセキュリティ対策―

Share

2020年は世界的に急拡大した新型コロナウイルス感染症(COVID-19)の影響を受け、デジタルトランスフォーメーション(DX)の進展やテレワークの急激な普及など、企業を取り巻く環境は著しく変化しました。急激な環境の変化により、強固なセキュリティ対策が必須な金融機関においても被害報告が増加しています。そこで今回は、金融機関に焦点をあて、最新の攻撃事例に触れつつ、その対策と予防策をご紹介いたします。

テレワークの採用など急激な業務体系の変化は人々に不安を与える一因となるだけでなく、十分なセキュリティ対策が伴わない場合、攻撃者に隙を与えてしまいます。昨今のサイバー攻撃は多様化、巧妙化しており、攻撃手法も日々進化しています。それに対抗するセキュリティ対策はどうでしょうか。とりわけ機密情報を多く取り扱い、安定的なサービス提供が要求される金融機関は、サイバー攻撃のリスクを経営上のトップリスクの一つと捉え、強固なセキュリティを実現すべく取り組んでいますが、それでも被害は起こっています。

金融機関を狙うサイバー攻撃

新型コロナウイルス感染症(COVID-19)の流行が世界的に急拡大した2020年2月から4月にかけて、金融機関を狙ったサイバー攻撃が238%増加したとの調査結果があります。このうちランサムウェア攻撃は、同じ期間で約9倍増加したとのことです。実際、過去12カ月の間にサイバー攻撃が増えていると回答した金融機関は8割に上っています。*5

金融機関におけるサイバー攻撃の脅威と被害例には、以下のようなものがあります。

出典:日本銀行「サイバーセキュリティの確保に向けた金融機関の取り組みと課題 -アンケート(2019年9月)調査結果-」(2020年1月)
https://www.boj.or.jp/research/brp/fsr/data/fsrb200131.pdf

約400の金融機関を対象に日本銀行が実施したサイバーセキュリティに関するアンケート結果によると、昨今のサイバー脅威の主な動向として、ランサムウェア攻撃の凶悪化とDoS・DDoS攻撃規模の拡大化が挙げられています。*2

ランサムウェア攻撃の凶悪化

身代金として金銭を得ることを目的としたランサムウェア攻撃について、独立行政法人情報処理推進機構(IPA)は、従来の攻撃に「人手によるランサムウェア攻撃」と「二重の脅迫」という新たな手口が加わったと注意を呼び掛けています。*3

【従来の攻撃と新たな攻撃の比較イメージ】

出典:IPA「事業継続を脅かす 新たなランサムウェア攻撃 について ~「人手によるランサムウェア攻撃」と「二重の脅迫」~」
https://www.ipa.go.jp/files/000084974.pdf

特に、「人手によるランサムウェア攻撃」は、従来の明確な標的を定めず無作為に感染を試みる攻撃とは異なり、より大金を得られるよう、組織だけでなくシステムや情報といった明確な“獲物”に狙いを定めて実行されます。新たなランサムウェア攻撃では、標的型サイバー攻撃全般で使用される攻撃手口が用いられることが考えられると、IPAは注意を呼び掛けています。

新しいタイプのランサムウェアについては、「変貌するランサムウェア、いま何が脅威か‐2020年最新動向‐」にもまとめていますので、あわせてご覧ください。

標的型サイバー攻撃の脅威

金融機関や決済サービスを標的としたサイバー攻撃は増加の傾向にあり、国内でも2020年8月から9月にかけて大規模な銀行口座不正利用が発生しました。その被害は、11の銀行で200件以上、被害総額は2,800万円以上にのぼると報告されています。*4オンライン取引の増加、サービスの電子化や政府主導のキャッシュレス決済の推進、クラウドサービスやAIのさらなる活用といった様々な環境変化によって利用者側のユーザビリティが高まる一方で、標的型サイバー攻撃の脅威は常に組織を脅かしています。例えば、世界中の金融機関に攻撃を仕掛けることで有名な“国家支援型”攻撃グループ「APT38」(「Lazarus」や「Hidden Cobra」とも) *5が、2020年、新たなマルウェア「BLINDINGCAN」を使用していることが発見されました。*6

ニューノーマル浸透に対するセキュリティ課題

さらに、新型コロナウイルス感染症(COVID-19)の影響を受け、金融機関でも政府の呼び掛けにより在宅勤務対応が急速に広まりました。先に紹介した日本銀行による調査*7でも、大手銀行のすべて、地方銀行の約半数が在宅勤務制度を設けていることが分かりました。在宅勤務というニューノーマルが浸透していく一方で、内部システムへの接続環境や業務に利用する端末(私用端末含む)、情報の授受方法(メール、ファイルダウンロード/アップロード、USB等の記憶媒体利用など)、Web会議サービスの利用、職員への教育……といったセキュリティ対策の様々な課題が浮き彫りになっています。

金融機関のセキュリティ対策における課題について、これまで当社が複数の地銀様・信金様よりお聞きしたところでは、共通して下記の問題点が確認されています。

1)十分に精通した専門家がいるわけではなく、対応要員の確保ができない
2)取引先・外部委託先まで含める必要があり、範囲が拡がる一方で対応が追いつかない
3)攻撃の複雑化・巧妙化に伴って対応も高度化しているため、コスト負担が非常に大きい
4)クラウド利用は増加の一途だが、そのセキュリティ対策まで十分に手が回らない

攻撃を前提としたセキュリティ対策へ

サイバー攻撃の昨今の傾向を鑑みると、完全な防御は難しいといえます。そのため、予防的対策に加えて攻撃発生を想定した対策とリスク評価が重要となります。攻撃の防御に努める一方で、万が一攻撃を受けた場合にも被害を最小限にとどめる必要があります。求められる対策には、例として以下が挙げられます。

・基本的なセキュリティ対策の実施
 (例)
 -OSやソフトウェア等のアップデートならびにセキュリティパッチの適用
  -セキュリティ診断の定期的な実施
  -適切なアクセス制御と監視、ロギング
  -定期的なバックアップと安全な保管 -推奨されるセキュリティ設定の適用 など
・攻撃回避と検知能力の向上
  (例)
  -悪用されうる機能やサービス等の無効化
  -ネットワーク分離
  -高度な機能を持つセキュリティソリューションの導入
  -監視とログ分析の強化 など
・業務継続の視点からのセキュリティ対策
  (例)
  -コンティンジェンシープランの整備
  -リスクの可視化
  -訓練・教育の強化
  -対策の実効性確認 など

標的型攻撃リスク診断 SQAT®APT デモ動画

セキュリティ対策の実効性を確認するには、訓練や演習、定期的なセキュリティ診断が効果的です。実際に攻撃を受けた場合に、どこまで被害が及ぶのか、対応のための体制や仕組みは十分か、といった点を評価できます。マルウェア対策にしても、アンチウイルスソフトをはじめとする対策ソリューションを導入しているからといって完全に安心できるわけではありません。近年ではそれらを掻い潜る攻撃が増加していることも広く知られています。そこで、例えば実際の攻撃を想定したシナリオに基づく疑似的なペネトレーションテストを実施し、より現実的なリスクを可視化するという方法があります。当社のお客様の8割はマルウェア対策ソリューションを導入していますが、その上でペネトレーションテストサービスを利用するのには、こうした背景があるからにほかなりません。

2020年12月、経済産業省より「最近のサイバー攻撃の状況を踏まえた経営者への注意喚起」*8が発行されました。サイバー攻撃によって発生した被害への対応は企業や組織の信頼に直接関わる重要な問題であることが強調されており、さらなる対策の強化と徹底が求められています。

参考情報:金融機関向けセキュリティガイドライン等の紹介


■金融分野におけるサイバーセキュリティ強化に向けた取組方針
金融庁
https://www.fsa.go.jp/news/30/20181019/cyber-policy.pdf

■金融機関等におけるセキュリティポリシー策定のための手引書(第2版)
公益財団法人金融情報システムセンター ※一般公開なし
https://www.fisc.or.jp/publication/book/000154.php

■金融機関等コンピュータシステムの安全対策基準・解説書(第9版令和2年3月版)
公益財団法人金融情報システムセンター ※一般公開なし
https://www.fisc.or.jp/publication/book/004426.php

■金融機関等におけるコンティンジェンシープラン策定のための手引書
公益財団法人金融情報システムセンター ※一般公開なし
https://www.fisc.or.jp/publication/book/000120.php

■製品分野別セキュリティガイドライン 金融端末(ATM)編
一般社団法人重要生活機器連携セキュリティ協議会(CCDS)
https://www.ccds.or.jp/public/document/other/guidelines/[CCDS]ATM%E7%B7%A8%E5%88%A5%E5%86%8A_%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E5%AF%BE%E7%AD%96%E6%A4%9C%E8%A8%8E%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89_Ver2.0.pdf

■Financial Crime Guideline
FCA(金融行為規制機構)
https://www.handbook.fca.org.uk/handbook/FCG.pdf

■金融分野における個人情報保護に関するガイドライン
金融庁
https://www.ppc.go.jp/files/pdf/kinyubunya_GL.pdf


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。




Share