SQAT® Security 瓦版

2024年4月1日2024年4月1日

脆弱性管理とIT資産管理
-サイバー攻撃から組織を守る取り組み-

日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

増え続ける脆弱性

脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です（下グラフ参照）。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

増え続ける脆弱性画像 — NVD（米NIST：NATIONAL VULNERABILITY DATABASE）Static Resultsより2010～2023年の登録脆弱性件数

また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

脆弱性管理とその目的

情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

脆弱性管理の必要性

しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

脆弱性管理のライフサイクル

脆弱性管理の標準的な流れは以下の4つのプロセスになります。

各プロセスの概要とポイント


プロセス	概要	ポイント・留意点
資産の把握・管理	IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。	・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。・常にアップデートできていること、管理外の資産（シャドーIT）がないこと。
脆弱性情報の収集	資産管理情報をもとに、自組織に関係する脆弱性情報を収集。	・必要に応じて適切なタイミングで実施。・政府機関や製品ベンダといった信頼できるソースから収集。
脆弱性のリスク評価	脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。	・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
解消策の実行	実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。	・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

脆弱性管理におけるIT資産管理

脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

・ハードウェア： PC、サーバ、ネットワーク機器等
・ソフトウェア： OS、ミドルウェア、アプリケーション等
・ライセンス情報、購入・保守情報、廃棄情報
・利用者（利用部門）、利用状況

IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

脆弱性管理とIT資産管理の連携

IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

適切な脆弱性管理のためのポイント

前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。


漏れなく適時に一元管理	実態に即した評価と対応	プロセスの標準化と見直し
脆弱性管理を統括する部門に情報が集約されていること資産管理、脆弱性情報に漏れがないこと資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること　等	脆弱性情報とその解消策が信頼できる内容であること自組織への影響評価と解消策の要否・優先度の決定が適正に行われること解消策の実施が安全・確実な方法で行われること　等	脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること各プロセスでのトラブル発生時には適宜協議できる状態であること定期的、あるいは必要に応じて適宜手順の見直しを行うこと　等

“漏れなく”管理するには

ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

資産の把握・管理：ソフトウェアコンポーネントの管理

見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

■組み込みソフトウェアに起因する脆弱性が問題となった例：

2021年12月　

Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*1。
悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。

2023年12月

Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3。
リモートコード実行、クロスサイトスクリプティング、ＤｏＳ、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表（SBOM）」の活用が有効です。

SBOM （Software Bill of Materials）
特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
参考情報：https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver. 1.0」（令和5年7月28日）が発行されていますので、参考にしていただくとよいでしょう。

資産の把握・管理：シャドーITの撲滅

先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

■シャドーITに起因する脆弱性が問題となった例：

2024年 2月

著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
根本的な原因は、自組織で管理すべきCNAMEレコード（ドメインの別名を定義する情報）が、放棄されたドメインを指定したまま放置されていたこと。

シャドーITを発見するには、ASM（Attack Surface Management）が有効です（下イメージ）。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

一般的なASMの特徴とイメージ

インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

脆弱性情報の収集：脆弱性診断で補完

資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム（下記例）に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

・外部に公開されているネットワークセグメント
・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
・主力業務に直結するミッションクリティカルなシステム　等

ASMや脆弱性診断の実施頻度

漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

ウェビナー開催のお知らせ

2024年4月10日（水）13:00～14:00
「DevSecOpsを実現！- ソースコード診断によるセキュリティ対策のすすめ –」
2024年4月17日（水）14:00～15:00
「変化する不確実性の時代における「安心・安全・安定のWebサイト運営」セミナー- Google提唱のサイト信頼性スコアとセキュリティ基準の詳細 –」
2024年4月24日（水）13:50～15:00
「知っておきたいIPA『情報セキュリティ10大脅威 2024』～セキュリティ診断による予防的コントロール～」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2024年2月22日2024年2月26日

IPA 情報セキュリティ10大脅威 2024を読み解く
-サイバー脅威に求められる対策とは-

2024年1月24日、独立行政法人情報処理推進機構（IPA）は「情報セキュリティ10大脅威 2024」（組織編）を公表しました。各脅威が自身や自組織にどう影響するかを確認することで、様々な脅威と対策を網羅的に把握できます。多岐にわたる脅威に対しての対策については基本的なセキュリティの考え方が重要です。本記事では、脅威の項目別に攻撃手口や対策例をまとめ、最後に組織がセキュリティ対策へ取り組むための考え方について解説いたします。

注目するべきは「ランサムウェアによる被害」「内部不正による情報漏えい等の被害」

2024年1月24日、独立行政法人情報処理推進機構(IPA）は、情報セキュリティにおける脅威のうち、2023年に社会的影響が大きかったトピックを「情報セキュリティ10大脅威 2024」として公表しました。ここではその分析と解説、そして対策について述べていきます。

まず注目すべき点として挙げられるのが、1位の「ランサムウェアによる被害」（前年1位）と3位の「内部不正による情報漏えい等の被害」（前年4位）です。

「ランサムウェア感染」および「内部不正」は、日本ネットワークセキュリティ協会（JNSA）が発表している「2023セキュリティ十大ニュース」でも選考委員全員が関連事案をノミネートしたとされており、脅威の重大性が伺えます。

そのほかの部分に目を向けると、脅威の種類は前年と変化はありませんでしたが、大きく順位が変動しているものがいくつかあります。これについては脅威を取り巻く環境が日々変動していることを反映していると考えられます。特に4位から3位に順位を上げた「内部不正による情報漏えい等の被害」と、9位から6位に順位を上げた「不注意による情報漏えい等の被害」について、どちらも人間に起因するところが大きい脅威であることは、注目に値するでしょう。

「情報セキュリティ10大脅威 2024」注目の脅威

10大脅威の項目のうち、今回の記事では注目すべき脅威として、まず1位・3位・6位の脅威を取り上げて解説します。

1位「ランサムウェアによる被害」

ランサムウェアとは、「Ransom（身代金）」と「Software（ソフトウェア）」を組み合わせた造語であり、感染したパソコンに特定の制限をかけ、その制限の解除と引き換えに金銭を要求するといった挙動をするマルウェアです。

2017年5月12日に発生したランサムウェア「WannaCry（ワナクライ）」によるサイバー攻撃では、世界中で過去最大規模の被害が発生し、日本でも感染が確認され、国内大手企業や組織等にも被害があったことを覚えてらっしゃる方も多いでしょう。近年では、より悪質な二重の脅迫（ダブルエクストーション）型のランサムウェアによる被害が拡大しており、国内の医療機関が標的となって市民生活に重大な影響を及ぼした事案や、大手自動車メーカーのサプライチェーンをターゲットとしたサイバー攻撃も発生しています。

＜攻撃手口＞

メールから感染させる
Webサイトから感染させる
脆弱性を悪用しネットワークから感染させる
公開サーバに不正アクセスして感染させる

関連事例
2023年7月にランサムウェア感染により国内物流組織の全ターミナルが機能停止するというインシデントが発生しており、重要インフラ（他に代替することが著しく困難なサービスを提供する事業が形成する国民生活および社会経済活動の基盤とされるもの）へのサイバー攻撃の重大性を世に知らしめる結果となりました。またこの事例においては既知の脆弱性が悪用されたとの報道もあります。こちらは7位「脆弱性対策情報の公開に伴う悪用増加」についてもご参照ください。

1位「ランサムウェアによる被害」 — 出典：警察庁（令和5年9月21日）「令和５年上半期におけるサイバー空間をめぐる脅威の情勢等について」　P.20
３　ランサムウェア被害の情勢等　(2)企業・団体等におけるランサムウェア被害　より
【図表21：ランサムウェア被害の企業・団体等の業種別報告件数】

3位「内部不正による情報漏えい等の被害」

「内部不正による情報漏えい等の被害」は、組織の従業員や元従業員など関係者による機密情報の漏えい、悪用等の不正行為のことで、組織に不満を持つ者や不正に利益を得ようとする者等により、機密情報や個人情報が第三者に不正に開示されることを指します。組織の社会的信用の失墜、損害賠償や顧客離れによる売上の減少といった金銭的被害、官公庁からの指名入札停止等による機会損失等、甚大な損害につながる恐れがあります。IPAの調査によると、中途退職者による情報漏えいだけでなく、現職従業員等の情報リテラシーやモラルが欠如しているために起こる不正事案も多く報告されています。

内部不正に関してはIPAより「組織における内部不正防止ガイドライン」が作成され、現在改訂版第5版（2022年4月改定）が公開されています。改定ポイントの1番目に、内部不正による情報漏えいが事業経営に及ぼすリスクについての経営者に向けたメッセージの強化が挙げられています。こちらのガイドラインも参照し、経営者リーダーシップの元、必要な対応の実施を進めていただくことをおすすめします。

＜攻撃手口＞

アクセス権限の悪用
在職中に割り当てられたアカウントの悪用
内部情報の不正な持ち出し

関連事例
2023年10月に大手通信会社の元派遣社員による約900万件の顧客情報が流出したというインシデントがありました。このケースでは2013年7月頃から10年にわたり、自治体や企業など59組織の顧客情報が持ち出され、第三者に流通させていた*5とのことで、影響は広範囲に及んだものと考えられます。

6位「不注意による情報漏えい等の被害」

「不注意による情報漏えい等の被害」は3位の「内部不正による情報漏えい等の被害」と同様の人的要因による脅威です。代表的なものとしては「メールの誤送信」などが挙げられますが、これも細かく原因を見ていくと、メールアドレスの入力ミス、入力場所のミス、送信先アドレスのスペルミス、アドレス帳からの選択ミス、送信してはいけないファイルを勘違いして添付してしまう、送信者が気づかずに社外秘などの情報を伝達してしまうなど、原因は多岐にわたります。

対策としては、社外に送信されるメールのフィルタリングや、添付ファイルのアクセス制限といったシステム側からの対策のほか、リテラシー教育の実施といった従業員等へのケアも重要となります。またメールの誤送信以外にも、クラウドの設定ミスや生成AIに機密情報を入力してしまうといった事例も起きており、こちらも注意が必要です。

＜要因＞

取り扱い者の情報リテラシーの低さ
情報を取り扱う際の本人の状況
組織規程および取り扱いプロセスの不備
誤送信を想定した偽メールアドレスの存在

関連事例
2023年は、マイナンバーに他人の健康保険証情報や口座情報が紐づけられてしまうといった、マイナンバー関係のインシデントが相次いで発生しました。これを受け、デジタル庁は６月2日に「マイナンバー情報総点検本部」を設置*2し、マイナンバーに関する手続きの総点検を実施しました。点検対象となった約8200万件のうち、紐づけが間違っていた件数が約8400件あったと発表しました。その主な原因は、①目視と手作業による入力の際のミス、②各種申請時にマイナンバーの提出が義務化されておらず、提出がなかった場合の紐づけを氏名と性別だけで行っていた、③申請書に誤ったマイナンバーが記載されていた、④本人と家族のマイナンバーを取り違えた、と結論付けています。

引き続き警戒が必要な脅威

2位「サプライチェーンの弱点を悪用した攻撃」

サプライチェーンの弱点を悪用した攻撃は、セキュリティ対策が手薄な関連企業や取引先企業を経由して、標的とする企業へ不正侵入をするサイバー攻撃です。攻撃手段としてランサムウェアやファイルレス攻撃などの様々な手段を用います。

日本の会社は約9割を中小企業が占めており、大企業の関連会社、取引先企業の中には中小企業が多数あります。中小企業では大企業ほどセキュリティ対策にコストや人を費やすことができず、どうしてもセキュリティは手薄になりがちです。そのため、サプライチェーン攻撃が大きな問題となっているのです。

＜攻撃手口＞

取引先や委託先が保有する機密情報を狙う
ソフトウェア開発元や MSP（マネージドサービスプロバイダ）等を攻撃し、標的を攻撃するための足掛かりとする

4位「標的型攻撃による機密情報の窃取」

標的型攻撃とは、明確な意思と目的を持った攻撃者が特定の企業・組織・業界を狙って行うサイバー攻撃を指します。不特定多数の相手に無差別にウイルスメールやフィッシングメールを送信する攻撃とは異なり、特定の企業・組織・業界をターゲットにし、明確な目的を持って、保有している機密情報の窃取や、システム・設備の破壊・停止をする攻撃が行われます。長時間継続して行われることが多く、攻撃者が標的とする組織内部に数年間潜入して活動するといった事例もあります。

＜攻撃手口＞

メールへのファイル添付やリンクの記載
Webサイトの改ざん
不正アクセス

5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」

ゼロデイ攻撃とは、修正プログラム提供前の脆弱性を悪用してマルウェアに感染させたり、ネットワークに不正に侵入したりする攻撃です。セキュリティ更新プログラムが提供されるよりも早く攻撃が仕掛けられるため、ソフトウェア利用者には脅威となります。また、通常ではサポートが終了した製品には更新プログラムの提供はないため、使用を続ける限り“常にゼロデイ攻撃の脅威にさらされている”ということになります。サポートが終了した製品を継続利用している組織や個人は、サポートが継続されている後継製品への速やかな移行が必要です。

＜攻撃手口＞

ソフトウェアの脆弱性を悪用

「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」について、SQAT.jpでは以下の記事で解説しています。
こちらもあわせてご覧ください。
「IPA情報セキュリティ10大脅威にみるセキュリティリスク―内在する脆弱性を悪用したゼロデイ攻撃とは―」

7位「脆弱性対策情報の公開に伴う悪用増加」

ソフトウェアやハードウェアの脆弱性対策情報の公開は、脆弱性の脅威や対策情報を製品の利用者に広く呼び掛けることができるメリットがありますが、一方で、攻撃者がその情報を悪用して、当該製品への脆弱性対策を講じていないシステムを狙って攻撃を実行する可能性があります。近年では脆弱性関連情報の公開後から、攻撃が本格化するまでの時間も短くなってきています。

修正パッチや回避策が公開される前に発見されたソフトウェアの脆弱性をゼロデイ脆弱性と呼びますが、修正プログラムのリリース後から、実際に適用されるまでの期間に存在する脆弱性は「Nデイ脆弱性」と呼ばれます。ソフトウェアの管理が不適切な企業は、対応されるまでの時間が長くなるため、被害に遭うリスクが大きくなります。

8位「ビジネスメール詐欺による金銭被害」

ビジネスメール詐欺は、巧妙な騙しの手口を駆使した偽のメールを組織・企業に送り付け、従業員を欺いて送金取引に関わる資金を詐取する等の金銭被害をもたらす攻撃です。ビジネスメール詐欺では、経営幹部や取引先などになりすましたメールが使われることがありますが、攻撃の準備として、企業内の従業員等の情報が狙われたり、情報を窃取するウイルスが使用されたりします。

＜攻撃手口＞

取引先との請求書の偽装
経営者等へのなりすまし
窃取メールアカウントの悪用
社外の権威ある第三者へのなりすまし
詐欺の準備行為と思われる情報の窃取

9位「テレワーク等のニューノーマルな働き方を狙った攻撃」

2020年新型コロナウイルス対策として急速なテレワークへの移行が求められ、自宅等社内外からVPN経由での社内システムへのアクセス、Zoom等によるオンライン会議等の機会が増加しました。こうしたテレワークの業務環境に脆弱性があると、社内システムに不正アクセスされたり、Web会議をのぞき見されたり、PCにウイルスを感染させられたりする恐れがあります。

テレワークのために私物PCや自宅ネットワークの利用、VPN等のために初めて使用するソフトウェアの導入等、従来出張用や緊急用だったシステムを恒常的に使っているというケースでは、セキュリティ対策が十分であるかの確認など、特に注意が必要です。

＜攻撃手口/発生要因＞

テレワーク用製品の脆弱性の悪用
テレワーク移行時のまま運用している脆弱なテレワーク環境への攻撃
私有端末や自宅のネットワークを利用

10位「犯罪のビジネス化（アンダーグラウンドサービス）」

犯罪に使用するためのサービスやツールがアンダーグラウンド市場で取引され、これらを悪用した攻撃が行われています。攻撃手法は、脆弱性の悪用やボットネットによるサービス妨害攻撃、ランサムウェアの感染など攻撃者が購入したツールやサービスによって多岐にわたります。

攻撃に対する専門知識に詳しくない者でもサービスやツールを利用することで、容易に攻撃を行えるため、サービスやツールが公開されると被害が広がる恐れがあります。ランサムウェアやフィッシング攻撃を含め、様々なサイバー攻撃の高度化や活発化の原因にもなっている脅威です。

＜攻撃手口＞

ツールやサービスを購入し攻撃
認証情報を購入し攻撃
サイバー犯罪に加担する人材のリクルート

「犯罪ビジネス化（アンダーグラウンドサービス）」について、SQAT.jpでは以下の記事で解説しています。
こちらもあわせてご覧ください。
「IPA 情報セキュリティ10大脅威からみる― 注目が高まる犯罪のビジネス化 ―」

脅威への対策

世の中には今回ご紹介したIPA「情報セキュリティ10大脅威」以外にも多数の脅威が存在し、脅威の種類も多岐にわたりますが、セキュリティ対策の取り組みには、基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。

セキュリティ基本10項目

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

組織全体で対策へ取り組みを

サイバー攻撃は手口がますます巧妙化し、手法も進化を続けています。基本対策を実践するのはまず当然として、被害前提・侵入前提での対策も考える必要があります。

侵入への対策目的：システムへの侵入を防ぐ		侵入後の対策目的：侵入された場合の被害を最小化する
・多要素認証の実装・不要なアカウント情報の削除（退職者のアカウント情報など）・公開サーバ、公開アプリケーションの脆弱性を迅速に発見・解消する体制の構築・VPNやリモートデスクトップサービスを用いる端末・サーバのバージョン管理（常に最新バージョンを利用）・ファイアウォールやWAFによる防御など		・社内環境におけるネットワークセグメンテーション・ユーザ管理の厳格化、特権ユーザの限定・管理（特にWindowsの場合）・侵入検知（IDS/IPSなど）、データバックアップといった対策の強化・SIEMなどでのログ分析、イベント管理の実施・不要なアプリケーションや機能の削除・無効化・エンドポイントセキュリティ製品によるふるまい検知の導入

リスクの可視化をすることで実際にどこまで被害が及ぶのかを把握し、実際に対策の有効性を検証したうえで、企業・組織ごとに、環境にあった対策を行い、万が一サイバー攻撃を受けてしまった場合でも、被害を最小限にとどめられるような環境づくりを目指して、社員一人一人がセキュリティ意識を高めていくことが重要です。

BBSecでは

当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。sqat.jpのお問い合わせページよりお気軽にお問い合わせください。後日営業担当者よりご連絡させていただきます。

SQAT脆弱性診断

BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

ペネトレーションテスト

「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。脆弱性診断で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

ウェビナー開催のお知らせ

2024年3月6日（水）13:00～14:00
「セキュリティ対策の有効性を確認！ペネトレーションテストとはー脆弱性診断とペネトレーションテストー」
2024年3月13日（水）14:00～15:00
「クラウド時代に対応必須のセキュリティあれこれークラウドセキュリティについてー」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2024年1月29日2024年2月19日

ゼロトラストセキュリティ
-今、必須のセキュリティモデルとそのポイント-

クラウドサービスを導入して業務に活用する企業が約7割となった現代、自組織の情報資産を守るために、これまでのセキュリティモデルとは異なる考え方として、ゼロトラストモデルが注目されています。ゼロトラストでは「すべてを疑う」とし、境界内外問わず、すべての情報資産に対してのセキュリティの確保が求められます。本記事では、ゼロトラストとは何か？どのような考え方か？なぜ必要なのか？そして、実装のためのポイントとして現状把握の重要性について解説します。

ゼロトラストとは

「ゼロトラスト」は、「守るべき情報資産に対するあらゆるアクセスを信頼せず、すべて検証する」という原則に基づくセキュリティモデルです。

従来のセキュリティモデルである「境界型セキュリティ」とは異なり、ネットワーク境界（ネットワークの内側と外側）における信頼度を前提にしません。境界型セキュリティではネットワーク内部を信頼し、外部との境界を守ることが主眼としますが、ゼロトラストではすべてのアクセスに対して徹底的な検証を行います。ユーザやデバイスがネットワークに接続しようとする際に、その正当性を継続的かつ厳格に確認するのです。これにより、内部ネットワークへの侵入や権限の乱用を最小限に抑え、セキュリティを向上させることが期待できます。

境界型セキュリティの限界

ゼロトラストの根底にあるのは、境界の内側が必ずしも安全ではないという認識です。ゼロトラストという概念が生まれた背景として、以下のような事情による、境界型セキュリティの限界があります。

クラウド利用/テレワークの普及

国内企業におけるクラウド利用は7割超、テレワークの普及率は約５割とのことです（下図）。従来の境界型セキュリティの考え方では、社内ネットワークの内側は信頼できる領域であり、従業員もその領域内にいるものとされてきました。しかし、クラウドサービスは社外からアクセスでき、テレワークでは社外にいる従業員が企業・組織のシステムやデータにアクセスできるため、「ユーザは社内におり、社内の環境はセキュリティが確保されているから安全である」という前提が崩れてきています。

企業におけるクラウドサービスの利用状況 — 総務省「情報通信白書令和5年版データ集」より

サイバー攻撃の高度化

攻撃者は、標的型攻撃やゼロデイ攻撃など、様々なやり方で境界防御の突破を狙ってきます。そして、その手法はどんどん高度化・巧妙化しています。これに対して、境界型セキュリティでは、侵入させないためにファイアウォールを実装して、IPS（侵入防御システム）も実装して…と境界の壁を強固にすることを考えますが、技術が進歩してくなかで壁を強固にする側とそれを破ろうとする側のいたちごっこになるばかりで、結局のところ、無敵の壁をつくることは不可能といえます。

媒体経由感染/内部犯行等のリスク

攻撃者はネットワークへの不正アクセスに成功した場合、社内ネットワーク内を移動してマルウェア感染を広げるなど侵害を拡大させますが、境界型セキュリティではこれを防ぐことはできません。そもそも、外部からの侵入者に限らず、USBメモリ等の物理媒体を経由したマルウェア感染や内部犯行による情報窃取のリスクに対して、従来の境界型セキュリティでは、十分な対策を講じることは困難です。

VPN利用に係るリスク

先に触れたテレワークの普及に伴い、そのセキュリティ対策としてVPNの利用が拡大しました。しかし、VPN機器における脆弱性の放置がIPAやJPCERT/CC等からもたびたび注意喚起されており、これらの脆弱性を悪用した攻撃は境界型セキュリティで防御することが困難です。また、VPNを介した通信量の急増により、帯域不足やパフォーマンスの低下が発生する可能性があり、セキュリティを維持しながら利便性を享受することがしづらいケースもみられます。

進むゼロトラストの普及

日本も含め、世界中でゼロトラストの実装が進んでいることがうかがえる調査結果があります（下図）。

クラウド利用やテレワークの普及、DXの推進といった業務効率化・利便性を阻害せず、セキュリティを向上させる仕組みが必要とされる昨今、ゼロトラストの導入は待ったなしであり、今後もあらゆる業種において進んでいくと考えられます。

進むゼロトラストの普及 — Okta「ゼロトラストセキュリティの現状 2023」より

ゼロトラストの基本原則

ゼロトラストの考え方の基本原則は、2020年にNIST（米国立標準技術研究所）より発行された「NIST SP 800-207 Zero Trust Architecture」で定義されています。以下に７つの基本原則をご紹介します。

ゼロトラストの適用方針

ゼロトラストアーキテクチャをどのように適用していくか、という点については、デジタル庁発行の「ゼロトラストアーキテクチャ適用方針」も参考になります。同文書では、以下のような６つの適用方針が示されています。

ゼロトラストを実現するためのポイント

ゼロトラストの考え方について述べてきましたが、実際にゼロトラストアーキテクチャを構築・運用するにあたってはどういった要素があるのでしょうか。ここでは実現するためのポイントとして、５つの例をご紹介します。

まずはセキュリティ状況の可視化と有効性の確認を

境界型セキュリティは、機器やシステム、アプリケーションといった単位でセキュリティ対策を講じる発想でした。つまり、各リソースを単一点（シングルポイント）としてとらえて保護する形です。しかし、これでは様々な形態のアクセスを想定したＩＴ環境において、十分なセキュリティ対策を講じることは困難です。もし、境界型セキュリティのみに依存している場合は、これまでの脆弱性対策やセキュリティポリシーの内容および運用の見直しが求められそうです。

とはいえ、ゼロトラスト導入にはそれなりのコストがかかることは間違いありません。また、これまでのセキュリティ対策とは根本的に考え方が異なるセキュリティモデルを実装するため、導入するには課題もあります。そこで、まず取り組めることとして、以下のようなセキュリティ対策の基本から始めることが重要です。

・セキュリティ状態の可視化
セキュリティコンサルや各種脆弱性診断などにより、自組織の状態を明確に把握する
・実装済みのセキュリティ対策の有効性評価
ペネトレーションテストやログ分析などにより、実装したセキュリティ対策が有効に機能しているか確認する

こうして自組織内の情報資産の状態を把握することで、万が一サイバー攻撃を受けてしまっても、被害を最小限に抑えることが可能になります。組織の状況に応じて、適切な対策を実施していくことが、セキュリティ向上への第一歩となるでしょう。

BBSecでは

SQAT脆弱性診断

自システムの状態を知る

ペネトレーションテスト

攻撃を受けてしまった場合の対策の有効性を確認

完全に防ぎきることは難しくても、「攻撃・侵入される前提の取り組み」を行うことで、攻撃を受けてしまった場合にも被害を最小化する対策をする、「多層防御」が重要です。SQATペネトレーションテストでは実際に攻撃者が侵入できるかどうかの確認を行うことができます。

【コラム】
ゼロトラストに対する疑問

ゼロトラストについて、様々な疑問を持っておられる方もいらっしゃるでしょう。ここでは、ゼロトラストへの理解を進めるために、そういった疑問の例と、それに対する回答をピックアップしました。

ゼロトラストとはどのようのツールや技術？
ゼロトラストは特定の技術やツール、ソリューションを指す言葉ではありません。ゼロトラストは、セキュリティのアプローチや考え方を表す概念です。

ゼロトラストモデルか境界型セキュリティのどちらがいい？
ゼロトラストは境界型セキュリティを否定するものではありません。システムの特性や業務上の要件によって、両者を使い分けるとよいでしょう。境界型セキュリティが有効な場面として、ゼロトラストモデルへの移行が困難なレガシーシステムや特定の業界標準要件への対応、セキュリティ対策の構築・運用コストとの兼ね合いなどの事情が考えられます。

何を実装すればゼロトラストを達成できたと言える？
これを行えばゼロトラストを実現できている、という絶対的な答えがあるわけではありません。組織の実情に応じて異なるアプローチが必要です。ゼロトラストは単一の技術や手法ではなく、包括的なセキュリティモデルを指すためです。ゼロトラストモデルの具体的な適用ポイントについては先に述べた「ゼロトラストの適用方針」をご参照ください。

ゼロトラストの導入でシステムの利便性が落ちるのでは？
むしろ利便性を損なわずにセキュアな環境を提供することを目指すのが、ゼロトラストです。適切な設計・実装により、境界型セキュリティの制約から解放され、柔軟かつ安全なリモートアクセス環境を築くことが可能です。

ウェビナー開催のお知らせ

2024年2月7日（水）13:00～14:00
「シフトレフトを実現するためのソースコード診断とは-DevSecOps時代のセキュリティへの第一歩-」
2024年2月14日（水）14:00～15:00
「今さら聞けない！ PCI DSSで求められる脆弱性診断-4月1日運用開始！PCI DSSv4.0での脆弱性診断実施におけるポイントとは-」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年12月15日2023年12月20日

APIのセキュリティ
―Webアプリでもスマホアプリでも安全なAPI活用を―

APIはAI、IoT、モバイル、クラウド利用において今や必要不可欠です。利便性があり、利用者も増える一方で、APIを狙ったサイバー攻撃の数も増加傾向にあります。本記事では、APIとは？API連携の仕組みやスマホアプリとの関連、活用のメリットについて触れつつ、APIのセキュリティ対策の一つとして、脆弱性対応の方法ついて解説します。

APIとは

APIとは「Application Programming Interface」の略です。プログラムの機能をその他のプログラムでも利用できるようにするための仕組みです。

ソフトウェアやアプリ、プログラム同士を、APIを介して機能連携させるのが「API連携」です。あるソフトウェアに他のソフトウェアの機能を埋め込むイメージです。API連携によってソフトウェア同士が相互にデータと機能を共有できるようになります。

【APIの活用例】

社内業務システム：チャットAPIを活用してコミュニケーション
会員サービスサイト： SNSアカウント認証APIでログイン
ネットショップ：クレジットカード・認証APIで決済
飲食店サイト：地図情報APIで店舗位置情報表示 × 予約受付APIで予約対応

API活用のメリット

APIには、以下のようなメリットが考えられます。

Web API

「Web API」は、HTTPやHTTPSといったWeb技術により実現される、インターネットを介して情報をやりとりするAPIです。連携するAPI同士が異なるプログラミング言語で構築されていても通信でき、Webブラウザ上でも稼働するWeb APIは汎用性が高く、最も多く活用されているAPIです。

複数のWeb APIを組み合わせて新しいサービスを生み出す”マッシュアップ”が多く行われており、多くの人々が、日々その恩恵を受けていると言えるでしょう。インターネット上には膨大な数のWeb APIが公開されており、今後もマッシュアップは続くものと考えられます。

スマホアプリとAPI

Web APIは、Webアプリケーションばかりでなく、スマートフォンアプリ（スマホアプリ）でも多く活用されています。

例えば、経路案内アプリでは交通機関・運賃・時刻等の情報を的確に検索してくれるAPIが、家計簿アプリでは電子マネーによる決済やクレジットカード決済などの情報を取得して計算してくれるAPIが使用されています。

スマホアプリは、外部との通信をせずにスマホ端末単体で動作するものよりも、インターネットに接続しながら使用するものが圧倒的に多く、ユーザが利用している画面の裏でインターネットを介してサーバとのやりとりが行われており、そこでＷｅｂＡＰＩが稼働しているのです。

スマホアプリのセキュリティについて、SQAT.jpでは以下の記事で解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ瓦版「攻撃者が狙う重要情報の宝庫！ ―スマホアプリのセキュリティ―」

増え続けるAPI活用

国をあげてDXの取り組みが推進されている昨今、AI、IoT、モバイル、クラウド利用において、APIの積極的な活用は不可欠です。

クラウド環境上で動作するアプリ、クラウドネイティブアプリケーションを例にとると、APIを使用している割合は高く、今後さらに増大することが予想されるとの調査結果があります（下図）。

APIに対するセキュリティ脅威

利便性が高いAPIですが、利用が増えれば、そこに存在する様々なデータを攻撃者が狙ってきます。APIに対するセキュリティ脅威の例は以下のとおりです。

APIによって機能や取り扱う情報はそれぞれですが、金融情報のような資産に紐づくデータ、医療情報のような機微情報に関するデータなど、流出して悪用されると深刻な被害につながりかねません。APIを開発・利用する上で、セキュリティは必ず考慮する必要があるということです。

APIのセキュリティ脅威について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてご覧ください。
SQATⓇ 情報セキュリティ玉手箱「APIのセキュリティ脅威とは」

APIを狙ったサイバー攻撃の増加

APIに対する攻撃は増加傾向にあるとの観測結果が報告されています（下グラフ）。

なお、このグラフで多くの割合を占めている「ローカルファイルインクルージョン」は、攻撃者が対象システムのローカル上のファイルを読み込ませることで、領域外のファイルやディレクトリにアクセスできるようにしてしまう脆弱性です。情報漏洩、任意のコード実行、認証回避、DoS（サービス運用妨害）などの被害につながる恐れがあります。攻撃されたAPIサーバを「踏み台」とした内部/外部ネットワークへのさらなる攻撃やマルウェア感染などが想定されるため、危険度の高い脆弱性と言えます。

また、100ヶ国を対象にしたアンケート調査では、API攻撃による情報漏洩を経験している組織が90％以上にのぼるとの結果も報告されています（下グラフ）。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASP（Open Web Application Security Project）が、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したもので、今回は2019年の初版リリースから4年ぶりの第二版となります。

APIのセキュリティ対策

ここまで見てきたＡＰＩセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

開発中、リリース後、更新時といったいかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

また前段の「スマホアプリとAPI」でも述べたように、APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

BBSecでは

スマホアプリ脆弱性診断

悪意ある第三者の視点で、対象アプリに影響を及ぼす恐れのある脅威と関連リスクをあぶり出します。実機を使った動的解析とAPK（Android）・IPA（iOS）ファイルの静的解析を実施します。

Webアプリケーション脆弱性診断

また、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。弊社診断エンジニアによる、より広範囲で網羅的な診断を検討している方は、手動で診断する、「Webアプリケーション脆弱性診断」がおすすめです。

ウェビナー開催のお知らせ

2024年1月24日（水）13:50～15:00
「Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年11月10日2024年2月1日

ASM（Attack Surface Management）と脆弱性診断
― セキュリティ対策への活用法 ―

今、インターネット上に公開されるIT資産がサイバー攻撃者に狙われ、被害が拡大しています。サイバー攻撃者は事前に偵察行為をし、攻撃の的を探し、特定します。特に、脆弱性が存在しているWebシステムやネットワーク機器などは攻撃者にとっても悪用しやすく、侵入するための入口となってしまいます。では、自組織が狙われないようにするために、私たちはどのような対策をとればよいのでしょうか？本記事では、ASM（Attack Surface Management）と脆弱性診断を併用した、それぞれの実施の活用方法について解説いたします。

アタックサーフェス（攻撃対象領域）とは

サイバー攻撃に対する防御について語られる際に出てくる言葉の1つに、「アタックサーフェス」があります。

アタックサーフェスは、直訳すると”攻撃面”となりますが、サイバーセキュリティの文脈では、「攻撃対象領域」といった意味合いで使用され、サイバー攻撃の対象となり得る様々なIT資産、攻撃のポイントや経路等を指します。

組織が事業活動を行う上で使用するIT資産には、ハードウェアもソフトウェアも含まれます。IT資産にサイバー攻撃の足掛かりとなる攻撃ポイント・経路が存在すると、サイバー攻撃者は容赦なくそこを狙ってきます。

【アサックサーフェスの例】

攻撃事例とアタックサーフェス

実際のサイバー攻撃やインシデントの事例とそのアタックサーフェスを確認してみましょう。


年	事　例	アタックサーフェス
2020年	国内上場企業のドメイン名を含むサブドメインテイクオーバー（使用が終了したドメイン名の乗っ取り）の被害事例が2020年7月までに100件以上発生*3	ドメイン管理の不備
2023年	2022年5月以降、特定のセキュア・アクセス・ゲートウェイ製品の脆弱性を狙ったものと見られる標的型サイバー攻撃が断続的に発生*2	ネットワーク機器の既知の脆弱性
2023年	国内自動車メーカーの関連会社で保有する顧客約215万人分の車両等の情報が10年近く公開状態になっていたことが判明*3	クラウド設定の不備

拡大するアタックサーフェス

クラウド利用、DXの推進、テレワークの一般化……ITインフラ環境の柔軟性は高まる一方です。これに伴い、Webシステムやネットワーク機器といった外部との境界にあるアタックサーフェスは、拡大し続けています。つまり、外部にいるサイバー攻撃者が組織のシステムを侵害するチャンスが広がっていると考えられます。

サイバー攻撃者によるアタックサーフェスへのアプローチ

サイバー攻撃者が攻撃のため、最初に行う活動の典型が、「偵察」です。攻撃に利用可能な様々な情報を探索し、どの組織を標的とするか、どのような攻撃手法をとるか、といったことを定めるのに役立てます。

偵察活動で駆使される技術として、合法的に入手可能な公開情報を収集して調査・分析する手法—OSINT（「オシント」Open Source Intelligence：オープンソースインテリジェンス）が注目されています。

サイバー空間における脆弱性探索行為

前述のサイバー攻撃者による偵察活動が行われていることの裏付けとして、日本の各機関からも以下のような観測が定期的に報告されています。

【観測報告の例】


発表元		観測内容
国⽴研究開発法⼈情報通信研究機構（NICT）	2022年1～12月	調査⽬的と判定されるスキャンの数は12,752のIPアドレスから約2,871億パケットあり、これにサイバー攻撃のための偵察活動が含まれていると考えられる*4
JPCERT/CC	2022年10月～2023年6月	IoT機器を主な標的とするマルウェアMirai型パケットについて、海外および日本からの探索活動が継続して報告されている。探索元IPアドレスの一部について、動作している機種の特定に成功したことも*5
	2023年4～6月	Laravel（Webアプリケーションフレームワーク）の設定情報窃取を試みる通信を確認*6
警察庁	2023年1～6月	脆弱性のあるIoT機器の探索を目的としたものと見られるアクセスの増加を確認
	2023年1～6月	脆弱性のあるVPN機器の探索を目的としたものと見られるアクセスを断続的に確認

ASM（アタックサーフェスマネジメント）で自組織を守る

サイバー攻撃者の偵察行為で、自組織が攻撃対象として選定されないようにするにはどうすればよいでしょうか。

サイバー攻撃から⾃組織を守るために、インターネット上で意図せず公開してしまっているアタックサーフェスとなり得るIT資産を特定し、セキュリティ対策に活用する手法が、「ASM（Attack Surface Management：アタックサーフェスマネジメント）」です。

ASM導入ガイダンス

経済産業省は、ASMを「組織の外部（インターネット）からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」と定義しており、2023年5月29日に「ASM（Attack Surface Management）導入ガイダンス～外部から把握出来る情報を用いて自組織のIT資産を発見し管理する～」を発行しています。

企業のセキュリティ担当者や情報セキュリティを管掌する経営層（CIO、CISO等）に向けて、企業・組織に対してサイバー攻撃の起点となり得るIT資産を適切な方法で管理できるよう促すため、ASMの解説、ASMを実施するためのツールや必要なスキル、体制、留意点等がまとめられています。また、国内企業のASM取り組み事例も掲載されています。

ASMにより得られる効果

ASMにより以下のようなことが確認できます。

ASMのプロセス

ASMで具体的にどのようなことを実施するかというと、前述の経済産業省によるガイダンスでは、次のようなプロセスが紹介されています。「攻撃面」とは、「アタックサーフェス」のことです。

プロセス(1)　攻撃面の発見：

インターネットからアクセス可能なＩＴ資産として、IPアドレスやホスト名を発見。

・組織名（法人名等）より、オフィシャルWebサイトや検索プロトコルであるWHOISを利用して当該組織のドメイン名を特定・ドメイン名を特定したら、ＤＮＳ検索や専用ツールの使用によりＩＰアドレス・ホスト名の一覧を取得

プロセス（2）攻撃面の情報収集：

前プロセスの結果より通常のインターネットアクセスで取得可能な方法でOS、ソフトウェア、ソフトウェアのバージョン、開放されているポート番号といったＩＴ資産の情報を収集。

プロセス(3) 攻撃面のリスク評価

前プロセスで収集した情報を既知の脆弱性情報と突合せするなどして、脆弱性が存在する可能性を識別。

ASMのプロセスとしてはここまでですが、セキュリティ対策としては、ASMを実施して自組織のセキュリティリスクを把握した後の工程として、リスクの深刻度に応じた対応要否や優先度、具体的な対応内容等を決め、セキュリティリスクの低減に努める必要があります。

ASMと脆弱性診断の違い

さて、「IT資産の脆弱性検出やリスク評価を行う」となると、脆弱性診断と重なるイメージがあるのではないでしょうか。

ASMと脆弱性診断の関係性を表す、次のような図があります。脆弱性管理において、それぞれに役割があることが伺えます。

ASMと脆弱性診断の違い画像 — 出典：経済産業省「 ASM（Attack Surface Management）導入ガイダンス～外部から把握出来る情報を用いて自組織のIT資産を発見し管理する～」（令和5年5⽉29⽇）P.11　図 2-2 ASM と脆弱性診断の違い

両者の違いをまとめると以下のようになります。いずれもセキュリティ対策における取り組みですが、非常にざっくりと、ASMは“管理対象でないものも含めて広く浅く”、脆弱性診断は“特定した対象に対して深く詳細に”という印象で捉えられるのではないでしょうか。

ASMと脆弱性診断の併用・使い分けを

脆弱性管理において、ASMと脆弱性診断のどちらかを行っていればOK、ということではありません。脆弱性診断では、自組織が特定したシステムや機器に対して脆弱性を洗い出しますが、脆弱性診断の対象となるということは、組織自身が当該IT資産を管理下にあるものと認識していることになります。一方、ASMでは、そもそも管理外であるにもかかわらず当該組織のIT資産としてインターネット上に公開されてしまっているもの、つまり気づかぬまま管理から漏れてしまっているものを発見することができます。

そのため、両者の特長を理解した上でその目的に応じて、例えば、ASMによって脆弱性が存在する可能性があると発見したら、対象となる機器やシステムに対して脆弱性診断を実施して脆弱性の特定を行う、といった両者の併用・使い分けが推奨されます。

ASM・脆弱性診断ともに有効な実施方法の検討を

ASMも脆弱性診断も、ただ実施すればよいというものではなく、効果的に、かつ継続して行うことが重要です。そのためにはノウハウやスキルが必要となります。

ASMや脆弱性診断を自組織で実施しようとなると、以下のような注意点が挙げられます。

例えば、自組織ではASMや脆弱性診断をどう活用したいか検討することの方に労力を割き、ＡＳＭや脆弱性診断の実施や結果の分析については、その活用目的に合致した対応が望める外部のセキュリティサービスを探して依頼するなど、定期的に見直しをすることが重要です。

日々進化していくITインフラ環境において便利になる反面、攻撃者にもそのチャンスが広がっています。攻撃者から自組織を守るためにも、ASMと脆弱性診断の実施を組み合わせることは有効な選択肢の1つといえるでしょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

アタックサーフェス調査サービス

SQAT脆弱性診断サービス

システムに存在する脆弱性は、時として深刻な被害につながる看過できない脅威で、事業継続性に影響を与えかねません。BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。

ウェビナー開催のお知らせ

2023年11月22日（水）13:00～14:00「今さら聞けない！PCI DSSで求められる脆弱性診断あれこれ」
2023年12月6日（水）13:00～14:00「今さら聞けない！ペネトレーションテストあれこれ」
2023年12月13日（水）14:00～15:00「今さら聞けない！スマホアプリのセキュリティあれこれ」

最新情報はこちら

Security Report TOPに戻る
TOP-更新情報に戻る

2023年9月29日2023年10月4日

PCI DSS v4.0で変わるセキュリティ対策のポイント

PCI DSS v3.2.1の引退まで1年を切っていますが、対応状況はいかがでしょうか。2022年3月31日にリリースされたPCI DSS v4.0の準拠運用は、即時要件に対しては遅くとも2024年4月に開始される時期となり、システム系の大きな変更点が伴う未来日付要件を含めたv4.0完全対応完了までは、残り1年半となっています。この記事では、PCI DSS v4.0で変わるセキュリティ対策のポイントについて、脆弱性診断に関する要件に着目し、今後どのように対応すべきかについて解説します。

PCI DSS v4.0：新たなセキュリティスタンダードへの移行

PCI DSSとは、Payment Card Industry Data Security Standardの頭文字をとったもので、クレジットカード会員データを安全に取り扱うことを目的として策定された、クレジットカード業界のセキュリティ基準です。American Express、Discover、JCB、MasterCard、VISAの5つのカードブランドによって設立された組織、PCI SSC（PCI Security Standards Council）によって管理されており、クレジットカードを取り扱うすべての事業者に対して、カード情報の保護とセキュリティの実施を求めるものです。この基準に準拠することで、クレジットカードを取り扱う事業者の信頼性と顧客の安心感を高め、ブランド価値の保護、そして業界全体のセキュリティレベルの向上に寄与します。

2022年3月31日には最新版PCI DSS v4.0が発表されました、以前のメジャーバージョンであるPCI DSS v3.0は2013年11月に発表されたもので、今回8年4か月ぶりのメジャーアップデートとなります。今後2024年3月31日には2年間の移行期間が終了したv3.2.1が引退し、以降v4.0のみが有効な基準となることが決まっています。

未来日付要件は、現在はベストプラクティス要件の位置づけのため、2025年3月31日までは対応必須ではありません。しかし、残り1年半程度の対応期間の中で、システム改修や新規ソリューション導入等を行わなければならない場合、予算化や製品選定、対応ベンダ選定、運用に向けた検証作業、手順書見直しなど、対応すべき事項は決して少なくありません。

少なくとも今年度中には、要件の要求ポイントと自組織に不足する要素を洗い出し、対応スケジュールの立案が済んでいることが望ましい時期です。

PCI DSS v4.0改定のポイント

PCI DSS v4.0は、従来のv3.2.1に比べて、以下のようなポイントで改定されています。

●　決済業界のセキュリティニーズに対応
●　継続的なプロセスとしてセキュリティを促進
●　さまざまな方法論に柔軟性を追加
●　検証方法を強化

出典：https://www.pcisecuritystandards.org/document_library/
PCI-DSS-v4-0-At-a-Glance-r1-JA.pdf

PCI DSS v3.2.1からの主な変更点

PCI DSS v4.0では、いくつかの重要な変更点があります。事業者がPCI DSS準拠の対応を検討する際には、これらの変更点に注意を払う必要があります。

要件タイトル変更

まず、大きな変更の一つ目が、要件タイトルの変更です。要件9以外すべてが変更となりました。加えて、要件の理解を高めるために、詳細要件と用語の定義、文章の修正が行われました。

進化した要件

次に、新たな脅威や技術、決済業界の変化に対応するため追加された新規要件や、既存要件が一部変更／削除されたものがあります。該当する要件は67件ありますが、その中でも大きなものとしては、以下のようなものがあげられます。

多要素認証について

PCI DSS v4.0では、要件8.5.1にて、多要素認証(MFA)について、実装方法が明確に要件化されました。

また、要件8.4.2では「カード会員データ環境(CDE)へのすべてのアクセス」にMFA（多要素認証）が要求されることになりました。8.4.3では「カード会員データ環境(CDE)にアクセスまたは影響を与える可能性のある、事業体のネットワーク外から発信されるすべてのリモートネットワークアクセス」に対してもMFAが求められており、それぞれでMFAが必要となります。

これは例えば、ある担当者が最初にリモートアクセスによって事業者のネットワークに接続し、その後ネットワーク内からカード情報データ環境(CDE)への接続を開始した場合、その担当者は「事業者のネットワークにリモートで接続するとき」と「事業体のネットワークからカード会員データ環境(CDE)へアクセスするとき」の2回、MFAを使用して認証する必要があるということです。なお、CDEへのアクセスに対するMFAはネットワークまたはシステム／アプリケーションのレベルで実装することができます。CDEネットワークに接続する際にMFAを使用した場合、その後のCDE内の各システムコンポーネントにログインする際には追加のMFAを使用する必要はありません。

脆弱性診断に関する主な変更点

PCI DSS v3.2.1からv4.0への変更点のうち、脆弱性診断に関わるポイントとしては以下の3点が挙げられます。

脆弱性スキャンの頻度は「四半期に一度」だったところが「3カ月に1回」へと変更されました。PCI DSSの時間枠要件の意図は「その時間枠を超えない範囲で、できるだけ近い感覚で実行されること」であるところを、「四半期に一度」では最大半年ほど間隔があいてしまうことも許容することになってしまうため、厳格化されたものと思われます。

認証スキャンの実施については、十分な特権ユーザのID/パスワードのアカウント、もしくはクライアント証明書を保持した状態であることが必要になります。十分な権限による脆弱性スキャンができない事情がある場合は、当該システムについて文書化することが求められます。

ペネトレーションテストに求められる内容については、PCI DSS v3.2.1では、業界承認のテスト方法（NIST SP800-155など）であればよいと規定されていましたが、結果としてペンテスターへの依存度が高くなり、さまざまな形態のペネトレーションテスト結果の提出が許容される形となっていました。こうした状況を是正し、準拠レベルを標準化するため改定されたのではないかと考えられます。

脆弱性診断実施にあたって求められる対応

PCI DSS v4.0では脆弱性診断実施にあたって求められる対応にも変更があります。高リスクの脆弱性（CriticalやHigh）以外の脆弱性、すなわち中・低リスクの脆弱性（MediumやLow）についても、ターゲットリスク分析の上で対応をすることが要求されています。また、脆弱性は日々新しいものが発見・更新されていますので、各種のスキャン等で検出された高リスクの脆弱性対応だけでも大きな負担であるところを、さらに中低のリスクとされる脆弱性についても対処が必要となると、脆弱性管理は非常に負担の大きな作業になることが予想されます。

PCI DSS v4.0に求められる脆弱性診断のポイント（診断実施機関の長期化・診断実施時のリスクの考慮）

QSA(Qualified Security Assessors:認定審査機関)の見解次第ではありますが、ターゲットリスク分析の結果、『対処の必要なし』と判断した事業者側の意見が通った場合は別として、中低リスクの脆弱性についても対処が基本的に必要になると考えますと、今まで通りのやり方（PCI DSS v3.2.1手法の脆弱性管理）では指摘を受ける可能性もあります。この規定の”目的”部分を見ると、機械的に中小リスクだから対応は一律不要と判断するのではなく、ターゲットリスク分析において、きちんとした根拠を持って”対処が不要”とした事業者が結論を出す必要があると読み取れます。

脆弱性診断に関する主な変更点については、SQAT® Security Report 2023年春夏号
「PCI DSS v4.0で変わる脆弱性診断～2024年4月1日完全移行で慌てないために～」でも取り上げています。
以下より資料（PDF）ダウンロードいただけますので、ぜひご参考ください。
https://www.sqat.jp/sqat-securityreport/

PCI DSS v4.0への移行に向けて

PCI DSSの準拠対応を検討する事業者にとって、PCI DSS v4.0への移行は重要な課題です。新たな要件や変更点に対応するためには、準備が必要となります。

PCI DSS v4.0準拠までのステップ

●　PCI DSS v4.0の精査
●　現状の環境での差異を把握
●　詳細化・明確化要件の対応を開始
●　新規要件およびシステム化対応の予算を確保
●　新規要件およびシステム化対応の実施
●　全体の対応状況の確認

PCI DSS v4.0では、ここで取り上げたほかにも、クラウド環境でのセキュリティ要件の明確化、セキュリティ管理の強化といった変更点もあります。事業者はv4.0に準拠対応しようとした場合、従来よりも高いレベルのセキュリティを実現することが求められます。専門家の助言や適切なソリューションを活用することが、スムーズな準拠対応の一助となるでしょう。当社ブロードバンドセキュリティがその助けとなれば幸いです。

BBSecでは

BBSecは、PCI SSC認定QSA（PCI DSS準拠の訪問審査を行う審査機関）です。準拠基準についての疑問や対応困難な状況があるといったような懸念・不安などは曖昧なままにせず、QSAにご相談いただくことをおすすめいたします。準拠に向けた適切な対応を検討するためのアドバイスや、事情に応じた柔軟な対応も可能です。

お問い合わせはこちら
※外部サイトにリンクします。

PCI DSS v4.0対応脆弱性診断サービス随時対応受付中！

次回ウェビナー開催のお知らせ

・2023年10月18日（水）13:50～15:00
「自動車産業・製造業におけるセキュリティ対策のポイント -サプライチェーン攻撃の手口と対策方法-」
・2023年11月15日（水）13:50～15:00
「Webアプリケーションの脆弱性対策 -攻撃者はどのように攻撃するのか-」

アプリ開発のセキュリティ対策
―シフトレフトでコスト削減と品質向上アプリ開発のセキュリティ対策―

アプリ開発環境では各開発フェーズのセキュリティ確保が重要です。セキュリティを度外視した開発を行っていると、インシデント発生を招き、結果的に事業継続を脅かす恐れがあります。アプリ開発のセキュリティ対策で有効な、「シフトレフト」の考え方を実践されていますでしょうか？本記事では、シフトレフトの考え方に基づいた、対策実施のポイントを解説します。

アプリ開発におけるセキュリティリスク

建物や乗り物、日用品や食品といった、身の回りの製品が安心して利用できるものでなければならないように、我々が日々利用している様々なアプリケーションもまた、安全なものでなければなりません。

とにかく早くリリースすることのみを優先したり、労力を極限まで削ったりするなど、セキュリティを度外視したアプリケーション開発を行っていると、セキュリティインシデントが発生するのは時間の問題です。情報漏洩を起こしてしまった結果、ユーザや委託元企業への損害賠償、信用失墜による取引停止など、事業継続自体を脅かす危機に陥る恐れもあります。

設計・開発フェーズにおける脆弱性対処

とはいえ、アプリケーション開発におけるセキュリティについて、何がポイントなのか、どこから手を着けたらよいかわからない……ということもあるかもしれません。

IPA発行「脆弱性対処に向けた製品開発者向けガイド」（2020年8月）には、「リソースに限りのある製品開発者が、脆弱性への対処についてどれから着手してよいか判断に迷う」といった困りごとに対応するためのヒントが記載されています。

例えば、「設計・開発」フェーズにおける脆弱性対処として以下の項目が挙げられています。

脆弱性対処の不備によるリスク

では、開発工程において脆弱性対処が十分でないと、どのような影響があるか、確認してみましょう。

構成要素に脆弱性があると…

OS、アプリケーション、プログラム言語、またはライブラリ等の構成要素に既知の脆弱性が存在すると、これを悪用したサイバー攻撃を受ける可能性があります。日々、新しい脆弱性が報告されており、その情報が公開されています（下記例）。CVSSスコアの部分を見ると、深刻度の高い脆弱性も報告されていることがわかります。

▼オープンソースのプログラミング言語PHP関連で報告されている脆弱性の例

▼JavaScriptライブラリjQuery関連で報告されている脆弱性の例

後から脆弱性が発覚した場合、その対処には多くのコストがかかります。開発にあたってはあらかじめ構成管理体制ができており、それが継続して可能な状態であることが重要です。

セキュアコーディングでないと…

開発担当者のスキルに依存することなく、セキュリティレベルが適切に保持されるよう、セキュアコーディング規約を策定して、これをもとに開発を行うことが重要です。

脆弱性が作り込まれた状態で運用されていると、サイバー攻撃による情報漏洩・改ざんやシステム停止といった被害に遭う恐れがあります。実際に、国内でも次のようなインシデントが報告されています。


年月	事例
2022年 5月	フリマアプリより個人情報約275万件以上漏洩の可能性*7https://snkrdunk.com/information/130/ 原因：SQLインジェクション
2022年 6月	資格検定申込サイトよりメールアドレス29万件以上漏洩の可能性*2 原因：SQLインジェクション
2022年 12月	無線Wi-Fi製品問い合わせフォームに入力されたメールアドレス千件以上漏洩の可能性*3 原因：SQLインジェクション
2023年 4月	共同研究機関より研究参加者のメール5千件以上漏洩の可能性*4 原因：SQLインジェクション

デジタル庁発行「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」（2022年6月30日）によると、脆弱性を作り込まないようにセキュアコーディングを実施するにあたり、次のような対応が推奨されています。

●　セキュリティ実装においては、担当者によるミスやばらつきの発生を防止することが重要であるため、セキュリティ関連のコーディングや設定は、テンプレートの使用や、自動化機能を用いて対応することが望ましい。

●　アプリケーション開発は、安全で利便性の高い、セキュアコーディングをサポートするような機能を有した開発用ツールやフレームワークを活用することで、人為的なミスを抑え、セキュリティ確保することが有効である。

開発環境のセキュリティが確保されていないと…

工場に不審者の出入りが自由だったり、製造ラインが汚染されていたりすることで製品の安全性が脅かされるのと同様、アプリケーション開発においても開発環境のセキュリティ確保が重要です。

開発環境に係るセキュリティインシデント例として、次のようなものがあります。

[事例1]

自動車メーカーの委託先企業がGitHubにソースコードを公開し、5年間近くアクセス可能な状態に。個人情報29万件以上漏洩の恐れ。

[事例2]

クラウド型CI/CDツール（ソフトウェア開発支援ツール）のCircleCIにおいて、ユーザが利用するGitHub等のサードパーティリポジトリサービスに不正アクセス発生。

ソースコードリポジトリやCI/CDツールは今や効率的に開発を進めるのに欠かせないサービスである一方で、セキュリティ上の問題が発生すると、組織全体にその影響が及びかねないという側面もあります。サービス自体に潜む脆弱性やクラウド設定等、利用するサービスの特性を理解した上で十分注意を払う必要があります。

シフトレフト導入による効果

前述のIPA「脆弱性対処に向けた製品開発者向けガイド」では、「Ⅰ.方針・組織」「Ⅱ.設計・開発」「Ⅲ.出荷後の対応」の各段階におけるセキュリティ対策が解説されています。

開発ライフサイクルのより早い段階で、セキュリティに対する考慮を組み入れるのが、「シフトレフト」と呼ばれる考え方です。リリースの直前など、開発サイクルの後工程で脆弱性が発覚すると、その対処には時間も労力もかかるでしょう。とはいえ、対処しないわけにもいきません。手戻りを未然に防ぐことで、結果的に全体の開発期間を短縮し、コスト効率と品質向上を図る効果が期待できます。

シフトレフトは、もとはソフトウェア開発におけるプログラムの不具合（バグ）への対処において提唱されたものです。下記のような実態がみられるため、工程を前倒しにし（シフトレフト）、静的コードテストや単体テスト等を開発の前段階に組み込んでいくと、コスト削減効果がある、となったわけです。

ソフトウェアのバグとその修正対応の関係

●　バグの多くがコーディング段階で作り込まれる（青い線）

●　テストが後になるとバグの発見も後になる（オレンジ色の線）

●　バグの修正対応は後になればなるほどコストが増大する（赤い線）

ソフトウェアのバグとその修正対応の関係の画像 — Capers Jones「 Applied Software Measurement: Global Analysis of Productivity and Quality」
https://www.stickyminds.com/article/shift-left-approach-software-testing

では、バグへの対処をセキュリティ上の課題への対処に置き換えるとどうでしょうか。実際に、セキュリティにおいてシフトレフトを実践したGoogleが、トータルコストの減少効果があったと発表しています。*5下図で、シフトレフト導入前後で、セキュリティ上の欠陥に対処するコストを示している赤い線の状況が大きく異なることがわかります。

▼従来のセキュリティテストパターン

▼シフトレフト導入後のセキュリティの状況

セキュリティにおけるシフトレフトの実施内容

アプリケーション開発において、より早い段階でセキュリティへの考慮を組み入れる、とはどういうことでしょう。具体的な実施内容は、こちらのようなイメージになります。

これを実現するためには、開発の企画･設計段階からセキュリティを考慮する「セキュリティ・バイ・デザイン」の概念に基づいて、開発チーム（Developer）とセキュリティチーム（Security）と運用チーム（Operations）が、互いに協力し合うことで品質向上を実現する、「DevSecOps」の体制を組んで臨むことが肝要です。

実装工程におけるソースコード診断

アプリケーション開発のセキュリティ対応の実施において、たびたび登場するのが脆弱性検査です。検査の種類はいくつかあります。

●　ソースコード診断

●　Webアプリケーション脆弱性診断

●　ネットワーク脆弱性診断（プラットフォーム脆弱性診断）

●　スマホアプリ脆弱性診断

●　IoT脆弱性診断

●　ペネトレーションテスト　等

このうち、実装工程でソースコードに作り込んでしまった脆弱性を検出するのが、「ソースコード診断」です。他の種類の脆弱性診断では検出しづらい潜在的な脆弱性を、開発ライフサイクルのより早い工程で洗い出すことが目的です。他の脆弱性診断に先駆けて実施されるべき診断と言えます。

セキュアコーディングを実践しつつ、ソースコード診断を効率的に行うためには、自動診断ツールを利用するのも有効です。静的コード解析を行うソースコード診断ツールの選定においては、以下のような点がポイントとなるでしょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

ソースコード自動診断

システムの開発段階から対策を行うことで、リリース直前での手戻りを防ぎませんか？BBSecのCracker Probing-Eyes® Coreはソースコードに潜む脆弱性を具体的に特定することで、根本的な問題解決ができます。安価でできるツール診断により、スケジュールに余裕のない場合でもお気軽に、短時間で安全性の確認ができます。また新規設備投資も不要のため、コストや労力の削減にもつながります。

Cracker Probing-Eyes Core®　キャンペーン近日開始予定！
詳細につきましては、お問い合わせフォームからお問い合わせをお願いいたします。
お問い合わせはこちら

＜次回ウェビナー開催のお知らせ＞

・2023年9月27日（木）14:00～15:00
「知っておきたいIPA『情報セキュリティ10大脅威 2023』
～セキュリティ診断による予防的コントロール～」

クラウドセキュリティとは
-セキュリティ対策の責任範囲と施策-

クラウドセキュリティ、当事者はだれか？

セキュリティ対策をクラウド事業者任せにしてはいませんか？クラウドサービス利用でも、セキュリティ対策はオンプレミス同様、重要な課題です。本記事では、クラウドセキュリティの責任範囲と対策実施の施策について解説いたします。

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

総務省が公開する「令和４年通信利用動向調査の結果」（令和５年５月２９日公表）によれば、クラウドサービスを全社および一部でも利用している企業の割合は2022年時点で72.2％にのぼるとされています。このことから、現代では組織のクラウド活用は一般的なものとなっており、様々な業種・業態での利用が広がっていることが読み取れます。こうして普及しているクラウドですが、セキュリティには適切な注意が払われているでしょうか。クラウドサービス利用でも、セキュリティ対策はオンプレミス環境と同様かそれ以上に、重要な課題です。

クラウドセキュリティとその責任範囲

クラウドセキュリティとは、クラウド環境におけるデータやシステムを保護するためのセキュリティ対策のことを指します。クラウドサービスを提供する事業者は、セキュリティに配慮した安全な環境を提供することに注力していますが、責任共有という考えにもとづいて、クラウドで実行されるアプリケーションやデータを保護する責任は、クラウドの利用者にあるとされているのが一般的です。つまり、クラウドセキュリティにおいては、クラウドサービス事業者とクラウドサービスユーザ、双方に責任があるということになります。そしてクラウドサービス事業者の責任範囲とユーザの責任の範囲はクラウドサービスの提供形態によって変化します。詳細は以下の表のとおりです。

クラウドサービスを利用して業務を行う場合は、自組織が責任を負う設定や管理の範囲がどこまでかをよく確認し、適切にクラウドサービス事業者が提供するセキュリティサービスを設定して、利用者自身が必要なセキュリティ対策を講じる必要があります。

クラウド環境のセキュリティリスク

クラウドを利用することは、「コストの削減」「納期・システム開発期間短縮」「拡張性・柔軟性」「オンデマンドセルフサービス」「利便性や機能向上」「事業継続性」といった、多数の魅力的なメリットが存在しますが、一方で、注意するべきリスクも存在します。

リスクとして挙げられるのが、悪意ある第三者に侵入され、機密データやシステムにアクセスされる「不正アクセス」、サービス終了後に物理的アプローチによる完全なデータ消去が難しいことに起因する「情報漏洩リスク」、クラウドサービスの機能変更によって設定が変更されるなどして、低いセキュリティレベルで運用されてしまい、その結果インシデントが発生してしまう「設定ミスによるインシデント」、インシデントが発生した際に、クラウド事業者から十分な対応が受けられない「インシデント対応の不十分性」といったリスクです。こうしたリスクはクラウド固有のものではなく、オンプレミスと同様に、セキュリティに関連するリスクであり、サービスユーザが適切なセキュリティ対策を施したり、サービス提供事業者と連携したりすることで、リスク緩和を図ることが可能です。

国内のクラウドセキュリティ設定ミスによるセキュリティインシデント事例

近年、クラウドサービスのセキュリティに関する設定が十分でなかったために、意図せず、クラウドサービスで管理している機密情報を無認証状態で外部に公開してしまい、機密情報を漏洩させてしまった事例が相次いで報告されています。このように、クラウドサービスの設定ミスでセキュリティインシデントが多発している原因の一つとして考えられるのが、クラウドサービス利用を利用している企業や組織が対応すべき情報セキュリティ対策が曖昧になっていることです。前述しましたとおり、クラウドセキュリティでは、クラウドサービス事業者とクラウドサービスユーザはお互いにクラウドサービスに対する責任を共有する「責任共有モデル」を多くの場合採用しています。しかし、実際にはクラウドサービスユーザ側で、セキュリティ実施者としての当事者意識が低いというケースが散見され、そのために設定ミスによるインシデントが多発していると考えられます。

日本国内のクラウドセキュリティインシデントの報告事例（2020年12月～2023年5月）


時期	事業者	概要
2020年12月	ECサイト運営会社	セキュリティ設定不備により、不正アクセスが発生し、148万件を超える個人情報が流出した可能性あり*6
2021年1月	ホビーメーカー	セキュリティ設定不備により、不正アクセスが発生し、約150名の顧客情報が流出した可能性あり*2
2021年2月	ソフトウェアベンダ	権限設定不備により、個人情報を含む2,800件超えの情報が第三者によってアクセス可能に*3
2021年8月	医療機関	グループの公開設定不備により、業務メールや非公開情報が外部から閲覧可能に*4
2021年11月	教育サービス会社	自治体より委託された事業の申込フォームの設定不備により、他の申込者の個人情報が閲覧可能に*5
2022年5月	ITサービスベンダ	アクセス設定不備により、採用に関する個人情報が6年間にわたり外部から閲覧可能に*6https://www.a-tm.co.jp/news/29297/
2023年5月	自動車 ITサービスベンダ	セキュリティ設定不備により、車台番号、車両の位置情報が外部から閲覧可能に*7

クラウドセキュリティの対策例

では、セキュリティ対策として、どのような対策を実施すればよいのでしょうか。まず、クラウドのセキュリティではオンプレミスと同様の「基本的なセキュリティ対策」とクラウドに応じた「クラウド環境のセキュリティ対策」に分かれます。

前者の基本的なセキュリティ対策の具体的内容は、以下の図のとおりです。

前提として押さえておくべきポイントは、「クラウドサービスというものは、組織外部での利用が前提であり、環境によって管理する内容も異なるため、従来のオンプレミス環境でのセキュリティ対策に加え、クラウド環境特有のセキュリティ対策が必要となる」という点です。これを踏まえて、基本的なセキュリティ対策をおろそかにしないことが重要です。

そして、クラウド環境のセキュリティ対策については、以下の図のとおりです。

クラウドのセキュリティ対策の方法としては、クラウドサービスの設定に関わるベストプラクティス集を利用する方法があることも補足しておきます。これは各クラウドベンダから公開されているもので、日本語版も用意されています。また、CISベンチマークという第三者機関が開発したセキュリティに関するガイドラインも存在しています。ただし、これらは網羅性が高く、項目も多いため、必要な項目を探すには労力が必要となる可能性があります。

国内クラウドセキュリティガイドラインの紹介

自組織の環境の安全性をより高めていく上で、ツールやガイドラインの活用も有効です。

■クラウドサービス提供者向け
総務省
「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」
■クラウドサービス利用者・提供者向け
IPA
「中小企業の情報セキュリティ対策ガイドライン」付録6：中小企業のためのクラウドサービス安全利用の手引き」
総務省
「クラウドサービス利用・提供における適切な設定のためのガイドライン」
経済産業省
「クラウドセキュリティガイドライン活用ガイドブック」

クラウドセキュリティの対策実施のまとめ

最後に、繰り返しとなりますが、クラウドサービスを利用する際には、クラウド事業者とクラウドユーザの双方がセキュリティ対策に取り組む必要があります。セキュリティは単なるクラウド事業者の課題ではなく、クラウドユーザ自身の重要な責務であることを認識し、適切な対策を講じることが重要です。

クラウドサービスのセキュリティ対策は、基本的な対策では従来のオンプレミス環境での対策と同様の方法です。ただし、環境によって管理する内容も異なるため、クラウド環境特有のセキュリティ対策も必要となる点に注意が必要です。クラウドセキュリティの対策のポイントとしては、ベストプラクティスにもとづいた設定の見直しと、第三者機関による定期的なセキュリティチェックを受けることです。自組織において適切な対策を実施し、セキュリティリスクを最小限に抑えましょう。

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

クラウドセキュリティ設定診断サービス

CISベンチマークテストのほか、主要クラウド環境におけるベストプラクティスにもとづく評価や、クラウド環境上でお客様が用意されているプラットフォームの診断（オプション）も可能です。ワンストップで幅広いサービスをご利用いただけます。

＜次回ウェビナー開催のお知らせ＞

・2023年9月27日（木）14:00～15:00
「知っておきたいIPA『情報セキュリティ10大脅威 2023』
～セキュリティ診断による予防的コントロール～」

ChatGPTとセキュリティ
-サイバーセキュリティの観点からみた生成AIの活用と課題-

2022年11月にOpenAIによって公開された生成AI「ChatGPT」の利用者は、リリース後わずか2か月で1億人を突破しました。2023年になってからもその勢いは止まらず、連日のようにニュースで取り上げられ、人々の注目を集め続けています。ChatGPTを含めた生成AIは、今後のビジネスにおいて重要な役割を果たし、企業の競争力にも関わってくると考えられます。本記事では改めてChatGPTとはいったい何なのか？そしてサイバーセキュリティの観点からみたインパクトとリスクについて解説します。

ChatGPTとは？

ChatGPTとは、端的に言えば「人間が作った質問に自然な文章で回答を返してくれる、OpenAIが開発した人工知能システム」のことです。ChatGPTの主要機能は「人間同士の対話を模範すること」であり、その得意とするところは、「人間が自然と感じる回答の生成」です。

応答してくれる言語については、主要なものに対応しており、日本語で問いかけた場合は日本語で回答が返ってきます。

ChatGPTの返答イメージ

なぜそのようなことが可能かというと、人間の脳の神経回路の構造を模倣した「ニューラルネットワーク」を利用*8しており、大量のウェブページ、ニュース記事、書籍、社交メディアの投稿など、多様なテキストを学習しているからです。つまり膨大なデータで学習し、人間の脳を模倣した処理によって、人間が使う自然な言葉で、入力した言葉に対して回答を返してくれるのです。

多種多様な生成AI

生成AI（ジェネレーティブAI）とは
生成AIとは、学習したデータをもとに、画像・文章・音楽・デザイン、プログラムコード、構造化データなどを作成することができる人工知能（AI）の総称です。近年は様々な組織から多種多様な生成AIが開発、リリースされており、日進月歩の進歩を遂げています。なお、ChatGPTの「GPT」は「Generative Pre-trained Transformer」を意味しており、Gは生成を意味するGenerativeです。

ChatGPTは2023年6月現在、2つのバージョンが存在しています。2022年の11月に公開された無料で利用できるChatGPT3.5というバージョンと、2023年3月に公開された有償での利用が可能なChatGPT4というバージョンです。ChatGPT4は3.5に比べて事実にもとづく回答の精度が40％向上しているとされている他、いくつかの機能が追加されています。

また、人工知能チャットボットとしてはChatGPTの他にも「Google Bard」、「Microsoft Bing AI」「Baidu ERNIE」その他様々なモデルが登場しています。他にも文章や画像から生成する画像生成AIとして「Midjourney」や「Stable Diffusion」、音声から文字起こしを行うChatGPTと同じOpenAIの「Whisper」といったものもあります。最近では、MicrosoftがWindows11へ「Windows Copilot for Windows 11」というChatGPTを利用した対話型のアシスタンスの導入を発表しています。

こうした生成AIにはカスタマーサービスでの利用、ソフトウェアの作成やメール文章の作成から、ちょっとした日常生活の疑問の解決、様々なビジネス上のシナリオ作成からテストまで、幅広い活用の幅があります。


種類	提供元	サービス名	URL
文章生成AI	OpenAI	ChatGPT	https://openai.com/blog/chatgpt
文章生成AI	Google	Bard	https://bard.google.com/
文章生成AI	Microsoft	Bing AI	https://www.microsoft.com/ja-jp/bing?form=MA13FJ
文章生成AI	Baidu	ERNIE	https://yiyan.baidu.com/welcome
画像生成AI	Midjourney	Midjourney	https://www.midjourney.com/home/?callbackUrl=%2Fapp%2F
画像生成AI	Stability AI	Stable Diffusion	https://ja.stability.ai/stable-diffusion
画像生成AI	OpenAI	DALL·E	https://openai.com/dall-e-2
文章生成AI （文字起こし）	OpenAI	Whisper	https://openai.com/research/whisper
音声生成AI	ElevenLabs	Prime Voice AI	https://beta.elevenlabs.io/

無数に存在するAIの画像 — 無数に存在するAI
出典：Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyondより引用

ChatGPTとサイバー攻撃

このような幅広い活用を期待されているChatGPTですが、一方でサイバー攻撃においても悪用が注目されてしまっているという側面もあります。

ChatGPTのサイバー攻撃での悪用を考えるときに、まず考えられるのはフィッシング攻撃における悪用です。ある調査では「見慣れたブランドであれば安全なメールだと思っている」という人が44％いると報告されています。そのような人が被害にあいやすい、「もっともらしく見える、文面に不自然なところのない一見して信ぴょう性の高い文面」を、攻撃者はChatGPTを利用して簡単に作り出すことができます。加えて、攻撃者が標的の普段利用している言語を解さず、そこに言語の壁が存在したとしても、これもやはりChatGPTを利用することで容易に乗り越えることが可能となります。このような精巧なフィッシングメールを、攻撃者はこれまで以上に少ない労力で大量に生成可能となります。

また、ChatGPTにマルウェアで利用できるような悪意のあるコードを生成させようと検証する動きがあり、ダークウェブ上では前述のフィッシングでの悪用を含めて、活発な調査、研究が進められているという報告もあります。このような言語的、技術的なハードルの低下は、ノウハウのない人間でも攻撃の動機さえあれば、ChatGPTを利用することで簡単にサイバー攻撃が実行できてしまうという脅威につながります。

ChatGPTの活用におけるその他のセキュリティ課題

ChatGPTに対するセキュリティの観点からの懸念点は、他にもあります。

情報漏洩リスク

業務上知りえた機密情報や、個人情報をChatGPTに入力してしまうリスクです。ChatGPTに送信された情報は、OpenAIの開発者に見られてしまったり、学習データとして使われたりして、情報漏洩につながってしまう可能性があります。2023年3月末には、海外の電子機器製造企業において、ソースコードのデバッグや最適化のためにChatGPTにソースコードを送信してしまったり、議事録を作ろうとして会議の録音データを送信してしまったりという、情報漏洩が報道*2されています。

正しくない情報の拡散リスク

ChatGPTは過去に学習した情報を利用して回答しているため、間違った情報や意図的に歪められた汚染情報、セキュアではない情報にもとづいた返答をしてしまう可能性があります。また、蓄積情報についても大部分が2021年までの情報とされており、回答が最新情報とは限らない点にも注意が必要です。例えば最新の脆弱性情報について質問しても、間違っていたり、古い情報で回答をしてしまったりする可能性もあります。

ChatGPTのセキュリティ課題

ChatGPTのセキュリティでの活用

ここまでセキュリティの観点からChatGPTのリスクに注目してきましたが、ChatGPTは応答学習型のセキュリティ教育や、セキュリティの疑問に答えてくれるセキュリティボットの開発、インシデント発生時のセキュリティアシストや、脅威動向の把握など、セキュアな社会構築への貢献も期待されています。また、OpenAIからもAIを活用したセキュリティに関する「OpenAI cybersecurity grant program」という最大100万ドルの助成金プログラムを開始すると発表がされています。このことからも、AIを用いたサイバーセキュリティの強化や議論促進が今後進展していくものと考えられます。

基本的な対策こそが重要

AIとサイバー攻撃について述べてきましたが、気を付けないといけないのは、ChatGPTがなくても、攻撃者もマルウェアも既に存在しており、脆弱性があればそこを突いて攻撃が行われるのだということです。ChatGPTはあくまでサイバー攻撃の補助として悪用されているだけであり、ChatGPT自体が脅威なのではありません。危険なのはChatGPTではなく、サイバー攻撃を行う者や、脆弱性を放置するなど対策を怠ることです。

今後、ハードルが下がったことで、技術力の低い攻撃者が参入しやすくなり、攻撃の数は増えるかもしれませんが、過去からある基本的なセキュリティ対策を講じていれば、多くの攻撃は未然に防げることに変わりはありません。個人情報の漏洩や正しくない情報の拡散といったリスクについても、セキュリティポリシーの遵守や、きちんと情報の裏付けを取る（ファクトチェック）といった基本的な行動規範がリスクを緩和してくれます。基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。いたずらに怖がるのではなく、基本的なセキュリティ対策を踏まえたうえで、上手にAIと付き合っていくことが必要ではないでしょうか。

Security Report TOPに戻る
TOP-更新情報に戻る

2023年4月21日2023年10月4日

BBSec脆弱性診断結果からみる
― 脆弱性を悪用したサイバー攻撃への備えとは ―

Webサイトは、重要なデータの宝庫であり、サイバー攻撃者にとっては宝の山です。攻撃者はWebアプリケーションやシステムに存在する脆弱性を突いた攻撃を仕掛けます。では、自組織のシステムに脆弱性が存在した場合、攻撃者に悪用されづらくするためには何ができるでしょうか。本記事では、多くの企業・組織への診断実績がある弊社の視点で、サイバー攻撃への備えの一つとして、脆弱性診断を活用した予防的措置をご紹介いたします。

脆弱性を悪用したサイバー攻撃

事業活動に欠かせないIT環境では、様々な個人情報や機密情報等が保管・やりとりされており、サイバー攻撃者にとってそれらは宝の山です。そのため、今この瞬間もあらゆる企業・組織がサイバー攻撃の脅威にさらされています。

そして残念ながら、多くのWebアプリケーションやシステムには脆弱性が存在している可能性があります。宝の山に、宝を盗める抜け穴、つまり脆弱性があるとなれば、悪意ある者に狙われてしまうのは当然といえます。

サイバー攻撃者はどのような脆弱性を狙うのか

では、サイバー攻撃者が狙う脆弱性とは、どのような脆弱性でしょうか。
それは攻撃者にとって「悪用がしやすい」、そして「うまみがある」脆弱性です。そのような脆弱性があるWebアプリケーションやシステムは、攻撃対象になりやすく、攻撃者にとって魅力的な標的です。

そして、攻撃者にとって「悪用がしやすい」「うまみがある」脆弱性とは、簡単に攻撃ツールやエクスプロイトコードが入手できる「蔓延度」、どれだけ甚大な被害をもたらすことができるのかという「危険度」、そしてどれだけ他の機能やシステム、あるいは世間にインパクトを与えることができるのかという「影響度」の3つを軸にして捉えることができます。

また、そうした攻撃者にとって魅力的な脆弱性が多数ある場合、一度の攻撃のみならず、何度も複数の脆弱性を突いて攻撃を行われる可能性があります。

脆弱性を突いた攻撃が成功した攻撃者のイメージ画像（自販機から飲み物が出てくる＝攻撃成功）

別の側面から見れば、攻撃者にとって魅力的な脆弱性がないWebアプリケーション・システムであれば、標的にされる可能性が少なくなるということです。

自販機に魅力的な脆弱性（攻撃してもうまみがない脆弱性）がないのをみて攻撃をあきらめる攻撃者のイメージ画像

サイバー攻撃者にとって攻撃対象にしづらいシステムとは？

ここまでみてきたように、攻撃者は「蔓延度」「危険度」「影響度」を軸に魅力的な脆弱性を判断することがあります。つまり裏を返せば、Webアプリケーションやシステムの脆弱性の「蔓延を防ぐ」「危険度を下げる」「影響度を下げる」ことで、攻撃者に脆弱性を悪用されにくくすることができます。そのためには各組織で脆弱性対策を行うことが必須となります。システムの欠陥をつぶし、脆弱性をなくすことが最も重要です。

古くから「無知は罪なり」という言葉もあります。情報セキュリティにおいては“まず知ること”が必要不可欠となります。脆弱性に対処するためには、「自組織のセキュリティ状況を見直し、リスク状況を把握して攻撃に備える」ことが重要です。

脆弱性の放置はサイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。サイバー攻撃によるインシデントは、組織にビジネスの機会の喪失、信用の失墜といった損失につながる可能性があるため、脆弱性の放置はそういった損失の潜在的な原因となります。

システムに存在する脆弱性の有無を確認するために有効な手段の一つが、脆弱性診断です。脆弱性診断により、日々変化する脅威に対する自組織のシステムのセキュリティ状態を確認できるため、適時・適切の対策が可能です。

BBSecの脆弱性診断サービス

システム脆弱性診断で用いるリスクレベル基準 — 「SQAT® Security Report 2023年春夏号」より

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しています。検出された脆弱性に対するリスク評価は5段階にレベル付けしてご報告しており、リスクレベルによって脆弱性対策の優先順位を判断しやすいものとなっています（右表参照）。

2022年下半期診断結果（多く検出された脆弱性ワースト10）

2022年下半期、BBSecでは12業種延べ510企業・団体、3,964システムに対して、脆弱性診断を行いました。結果として、なんらかの脆弱性が検出されたシステムのうち、5件に1件ほどはリスクレベル「高」以上の脆弱性が含まれているのが現状です。そのリスクレベル「高」以上の脆弱性を検出数順に10項目挙げると、下表のとおりになります。

2022年下半期におけるWebアプリ編ワースト10の上位3項目は、上半期同様、攻撃者にとって悪用しやすくうまみのあるインジェクション系の脆弱性がランクインしています。いずれもよく知られた脆弱性ばかりなため、悪用された場合、世間に基本的なセキュリティ対策を怠っている組織と認識され、信用失墜につながります。

また、アプリケーション等のバージョンアップを行わず、古い脆弱なバージョンを使用し続けているWebアプリケーションも多く存在し、ワースト10のうちの4項目がそういった脆弱性でランクインしています。すでに他組織で悪用された実績のある脆弱性を放置した状態となっている等、攻撃者にとっては同様の攻撃を複数の組織に対して行うだけで成果が出るので、こちらも悪用しやすくうまみのある脆弱性といえます。

ネットワーク編のワースト10でも過去と同じような脆弱性がランクインしていますが、9位の「SNMPにおけるデフォルトのコミュニティ名の検出」は初のランクインとなりました。SNMPは、システム内部のステータスや使用ソフトウェア等の各種情報取得に利用されるプロトコルで、管理するネットワークの範囲をグルーピングして「コミュニティ」としています。コミュニティ名には、ネットワーク機器のメーカーごとに「public」等のデフォルト値がありますが、SNMPにおけるコミュニティ名はパスワードのようなものであるため、デフォルトのままだと、これを利用して攻撃者に接続され、攻撃に有用なネットワークの内部情報を取得される恐れがあります。

脆弱性診断を活用した予防措置

ここまでお伝えしたように、攻撃者はより悪用しやすくうまみのある脆弱性を狙ってくる中で、自組織のWebアプリケーション・システムに脆弱性が存在するのか、また存在した場合どういったリスクのある脆弱性なのかを知り、脆弱性対策を行うことは組織として重要なことです。

脆弱性を悪用したサイバー攻撃への備えとして、BBSecとしては、脆弱性診断を推奨します。下図の攻撃方法は一例となりますが、影響範囲として機会損失から業務停止まで引き起こされる可能性がある、という実態はどの攻撃方法でも同じです。脆弱性を悪用された場合、どの攻撃方法であってもそういった被害が出る可能性があるため、悪用されやすい脆弱性は早急に対応しなければなりません。

早急に対応するポイントは「自組織のシステム状態を知り、優先順位をつけながら必要な対策をする」こととなるのですが、自組織におけるセキュリティ対策の有効性確認には、専門家の目線をいれることをおすすめしています。

脆弱性を悪用したサイバー攻撃に対して、予防的にコントロールするといった観点も含め、よりシステムを堅牢化していくために脆弱性診断の実施をぜひご検討ください。

半期（6か月）毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
最新号のダウンロードはこちら。

SQAT脆弱性診断サービス

Webアプリケーション脆弱性診断-SQAT^® for Web-

Webサイトを攻撃するハッカーの手法を用いて、外部から動的に脆弱性を診断することで、攻撃の入口となる可能性のある箇所を検出します。診断は最新のセキュリティ情報に基づき実施されますので、開発時やリリース前ばかりでなく、既存システムに対する定期的な実施といった、現状の脆弱性対策の有効性を確認するために活用することをおすすめしています。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

ネットワーク脆弱性診断-SQAT^® for Network

悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。ネットワークを標的とした攻撃のリスクを低減するため、脆弱性を徹底的に洗い出し、システムの堅牢化をご支援します。システムの導入・変更・アップグレード時のほか、運用中のシステムに対する定期チェックにご活用いただけます。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

Security Report TOPに戻る
TOP-更新情報に戻る

増え続ける脆弱性

脆弱性管理とその目的

脆弱性管理の必要性

脆弱性管理のライフサイクル

各プロセスの概要とポイント

脆弱性管理におけるIT資産管理

脆弱性管理とIT資産管理の連携

適切な脆弱性管理のためのポイント

“漏れなく”管理するには

資産の把握・管理：ソフトウェアコンポーネントの管理

資産の把握・管理：シャドーITの撲滅

一般的なASMの特徴とイメージ

脆弱性情報の収集：脆弱性診断で補完

ASMや脆弱性診断の実施頻度

BBSecでは

アタックサーフェス調査サービス

SQAT脆弱性診断サービス

ウェビナー開催のお知らせ

注目するべきは「ランサムウェアによる被害」「内部不正による情報漏えい等の被害」

「情報セキュリティ10大脅威 2024」 注目の脅威

1位「ランサムウェアによる被害」

3位「内部不正による情報漏えい等の被害」

6位「不注意による情報漏えい等の被害」

引き続き警戒が必要な脅威

2位「サプライチェーンの弱点を悪用した攻撃」

4位「標的型攻撃による機密情報の窃取」

5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」

7位「脆弱性対策情報の公開に伴う悪用増加」

8位「ビジネスメール詐欺による金銭被害」

9位「テレワーク等のニューノーマルな働き方を狙った攻撃」

10位「犯罪のビジネス化（アンダーグラウンドサービス）」

脅威への対策

セキュリティ基本10項目

組織全体で対策へ取り組みを

BBSecでは

SQAT脆弱性診断

ペネトレーションテスト

ウェビナー開催のお知らせ

ゼロトラストとは

境界型セキュリティの限界

クラウド利用/テレワークの普及

サイバー攻撃の高度化

媒体経由感染/内部犯行等のリスク

VPN利用に係るリスク

進むゼロトラストの普及

ゼロトラストの基本原則

ゼロトラストを実現するためのポイント

まずはセキュリティ状況の可視化と有効性の確認を

BBSecでは

SQAT脆弱性診断

自システムの状態を知る

ペネトレーションテスト

攻撃を受けてしまった場合の対策の有効性を確認

【コラム】ゼロトラストに対する疑問

ウェビナー開催のお知らせ

APIとは

【APIの活用例】

API活用のメリット

Web API

スマホアプリとAPI

増え続けるAPI活用

APIに対するセキュリティ脅威

APIを狙ったサイバー攻撃の増加

OWASP API Security Top 10

APIのセキュリティ対策

BBSecでは

スマホアプリ脆弱性診断

Webアプリケーション脆弱性診断

ウェビナー開催のお知らせ

アタックサーフェス（攻撃対象領域）とは

攻撃事例とアタックサーフェス

拡大するアタックサーフェス

サイバー攻撃者によるアタックサーフェスへのアプローチ

サイバー空間における脆弱性探索行為

ASM（アタックサーフェスマネジメント）で自組織を守る

ASM導入ガイダンス

ASMにより得られる効果

ASMのプロセス

プロセス(1) 攻撃面の発見：

プロセス（2） 攻撃面の情報収集：

「情報セキュリティ10大脅威 2024」注目の脅威

【コラム】
ゼロトラストに対する疑問

プロセス(1)　攻撃面の発見：

プロセス（2）攻撃面の情報収集：