#ソースコード

BBSecの脆弱性診断

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しており、高い網羅性とセキュリティ情勢を反映した診断を実現するため、セキュリティエンジニアおよびセキュリティアナリストが高頻度で診断パターンを更新し、診断品質の維持・向上に努めている。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2023年上半期（1月～6月）実施結果より、セキュリティ対策の実情についてお伝えする。

2023年上半期診断結果

Webアプリ/NW診断実績数

2023年上半期、当社では12業種延べ553企業・団体、3,396システムに対して、脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションにおいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上（緊急・重大・高）の割合は17.5％で、6件に1件近い割合で危険な脆弱性が検出されたことになる。

一方、ネットワーク診断では、なんらかの脆弱性があるとされたシステムは約半数だったが、そのうちの危険度「高」レベル以上の割合は23.8%で、5件に1件以上の割合であった。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2023年上半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

長年知られた脆弱性での攻撃

「Webアプリ編」について、1位、2位は前期同様「クロスサイトスクリプティング（以降：XSS）」と「HTMLタグインジェクション」となった。3位以下は、脆弱性項目は前期からあまり変化はないものの、「SQLインジェクション」が順位を上げた。

3位の「サポートが終了したバージョンのPHP使用の可能性」など、サポートが終了したバージョンのコンポーネント（プログラム言語、ライブラリ等）の使用がワースト10の4項目を占めている。サポート終了とはすなわち、新たに脆弱性が発見された場合でもコンポーネントの提供元は基本的に対処しないということであり、危殆化に対する利用者側での対策が困難となるため、継続利用は危険である。例えば、サポートが終了した製品についての脆弱性情報の公開が契機になり、攻撃コードが公開され、攻撃が活発化することも考えられる。最新バージョンへのアップデートを迅速に、定期的に実施すべきである。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

アクセス制御が不適切な認証機構の検出がランクイン

「ネットワーク編」のワースト10については、ワースト4までが前期と変わらず、5位、6位は順入れ替えという結果で、あまり大きな変動は見られなかったが、8位の「アクセス制御が不適切な認証機構の検出」が前期圏外からランクインした。「アクセス制御が不適切な認証機構」には、特権アカウントやデフォルトアカウント等を使用してログインできる脆弱性も含まれる。特権アカウントがデフォルトのまま、もしくは推測されやすい認証情報で設定されていた場合はさらに危険である。デフォルトアカウントやデフォルトパスワードを使用せず、推測されにくい複雑なパスワードを設定することや、ログイン画面に対するアクセスを強固に制御すること、特権アカウントは必要最小限のユーザにのみ付与することなどが推奨される。

カテゴリ別の検出結果詳細についてはこちら

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

2023年4月10日2024年3月26日

診断結果にみる情報セキュリティの現状
～2022年下半期　診断結果分析～

SQAT® Security Report 2023年春夏号

BBSecの脆弱性診断

脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2022年下半期（7月～12月）実施結果より、セキュリティ対策の実情についてお伝えする。

2022年下半期診断結果

Webアプリ/NW診断実績数

2022年下半期、当社では12業種延べ510企業・団体、3,964システムに対して、脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションにおいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上（緊急・重大・高）の割合は19.0％で、5件に 1件近い割合で危険な脆弱性が検出されたことになる。

一方、ネットワーク診断では、なんらかの脆弱性があるとされたシステムは約半数だったが、そのうちの危険度「高」レベル以上の割合は23.3%で、5件に1件以上の割合であった。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2022年下半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

長年知られた脆弱性での攻撃

Webアプリ編ワースト10の上位3項目は、前期と同じで、いまだ検出数が多い。いずれもよく知られた脆弱性ばかりなため、悪用された場合、セキュリティの基本的な対策を怠っている組織と認識され、信用失墜につながる。

「クロスサイトスクリプティング」に起因する情報漏洩は実際に報告されている。4位の「不適切な権限管理」は前期7位より順位を上げた。この脆弱性は、本来権限のない情報・機能へのアクセスや操作が可能な状態を指し、「OWASP Top 10（2021）」では、首位の「A01:2021-アクセス制御の不備」に該当する。一般ユーザであるはずが、処理されるリクエストを改竄することで管理者権限での操作が可能になる等により、個人情報や機密情報の漏洩・改竄、システムの乗っ取り、といった甚大な被害を招く恐れがある。外部から値を操作できないようにするのはもちろんのこと、各機能に対する適切なアクセス制御を実装することが推奨される。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

SNMPにおけるデフォルトのコミュニティ名の検出

ネットワーク編のワースト10もほぼお馴染みの顔ぶれであるところ、「SNMPにおけるデフォルトのコミュニティ名の検出」が9位に初ランクインした。SNMPは、システム内部のステータスや使用ソフトウェア等の各種情報取得に利用されるプロトコルで、管理するネットワークの範囲をグルーピングして「コミュニティ」とする。コミュニティ名には、ネットワーク機器のメーカーごとに「public」等のデフォルト値がある。SNMPにおけるコミュニティ名はパスワードのようなものであるため、デフォルトのままだと、これを利用して攻撃者に接続され、攻撃に有用なネットワークの内部情報を取得される恐れがある。コミュニティ名にはデフォルト値を使用しないこと、また、SNMPへの接続には強固なアクセス制御を実施することが推奨される。

カテゴリ別の検出結果詳細についてはこちら

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

2023年1月16日2024年3月18日

診断結果にみる情報セキュリティの現状
～2022年上半期　診断結果分析～

SQAT® Security Report 2022-2023年秋冬号

BBSecの脆弱性診断

当社のシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施している。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2022年上半期（1月～6月）実施結果より、セキュリティ対策の実情についてお伝えする。

2022年上半期診断結果

Webアプリ/NW診断実績数

2022年上半期、当社では12業種延べ611企業・団体、3,448システムに対して、脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションにおいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上（緊急・重大・高）の割合は22.3％で、5件に1件以上の割合でリスクレベルの高いものが出ていることになる。

一方、ネットワーク診断では、脆弱性ありと評価されたシステムは半分強というところだ。ただし、検出された脆弱性に占める危険度高レベル以上の割合は22.1%にのぼり、こちらも5件に1件以上の割合となる。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2022年上半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

長年知られた脆弱性での攻撃

上位ワースト10はいずれも、Webアプリケーションのセキュリティ活動を行っている国際的非営利団体OWASP（Open Web Application Security Project）が発行している「OWASP Top 10（2021）」でいうところの、「A03:2021 – インジェクション」「A07:2021 – 識別と認証の失敗」「A06:2021 – 脆弱で古くなったコンポーネント」「A02:2021 – 暗号化の失敗」「A01:2021 – アクセス制御の不備」等に該当する。

1位の「クロスサイトスクリプティング」や6位の「SQLインジェクション」は、長年知られた脆弱性である上、攻撃を受けると深刻な被害となりかねないにも関わらず、いまだ検出され続けているのが実情だ。

攻撃者による悪意あるコードの実行を許さぬよう、開発段階において、外部からのデータに対する検証処理と出力時の適切な文字列変換処理の実装を徹底していただきたい。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

推奨されないバージョンのSSL/TLS

1位の「推奨されないSSL/TLS」が圧倒的に多い。既知の脆弱性がある、あるいはサポートがすでに終了しているコンポーネントの使用も目立つ。このほか、特にリスクレベルが高いものとして懸念されるのが、FTP（4位）やTelnet（7位）の検出だ。これらについては、外部から実施するリモート診断よりもオンサイト診断における検出が目立つ。つまり、内部ネットワークにおいても油断は禁物ということである。FTPやTelnetのような暗号化せず通信するサービスはそもそも使用するべきでなく、業務上の理由等から利用せざるを得ない場合は強固なアクセス制御を実施するか、暗号化通信を使用する代替サービスへの移行をご検討いただきたい。

カテゴリ別の検出結果詳細についてはこちら

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

2022年6月28日2024年2月29日

診断結果にみる情報セキュリティの現状
～2021年下半期　診断結果分析～

SQAT® Security Report 2022年春夏号

BBSecの診断について

当社では、Webアプリケーション、ネットワーク（プラットフォーム）に対する脆弱性診断をはじめとして、スマホアプリ、パブリッククラウド、ソースコード、IoT、ペネトレーションテスト、標的型ランサムウェア攻撃におけるリスク可視化等、様々な局面における診断サービスを提供している。こうした診断による検出・分析結果は、メリハリある的確なセキュリティ対策の実施にお役立ていただいている。

診断品質向上のために

当社の脆弱性診断サービスは、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施している。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

高い網羅性のある脆弱性の検出、お客様のシステム特性に応じたリスクレベル評価、個別具体的な解決策の提供が行えるよう、セキュリティエンジニアおよびセキュリティアナリストが高頻度で診断パターンを更新することで、診断品質の維持・向上に努めている。

2021年下半期診断結果

Webアプリ/NW診断実績数

2021年7月から12月までの6ヶ月間に、当社では14業種延べ560企業・団体、3,949システムに対して、システム脆弱性診断を行った（Webアプリケーション/ネットワーク診断のみの総数）。前期2021年上半期（1月～6月）より、診断対象システム数は300件近く増加した。

9割のシステムに脆弱性

「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーション診断では、なんらかの脆弱性が存在するシステムの割合が9割前後で推移し続けている。検出された脆弱性のうち、危険度レベル「高」以上（緊急・重大・高）の割合は21.0％で、検出された脆弱性全体のおよそ5件に1件がリスクレベルの高いもの、ということになる。前期の高レベル以上の割合は23.9％だったため今期微減だが、ほぼ横ばいと言える。

「ネットワーク診断結果」の棒グラフでは、脆弱性なしと評価されたシステムが４割強を占めている。しかしながら、検出された脆弱性に占める危険度高レベル以上の脆弱性の割合は30.8%にのぼり、検出脆弱性のおよそ3件に1件が危険度の高い項目、ということになる。前期の高レベル以上の割合は28.3％だったため今期微増だが、ほぼ横ばいである。

以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2021年下半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

Webアプリケーション診断結果

高リスク以上の脆弱性ワースト10

5つに分類された各カテゴリの検出割合（「2021年下半期カテゴリ別脆弱性検出状況」掲載の円グラフ参照）については、前期とほぼ変わらず、各カテゴリにおける脆弱性の検出数ごとの数量も大幅な変動はなかった。リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

代表的な脆弱性はいまだ健在

上位ワースト10はいずれも、Webアプリケーションのセキュリティ活動を行っている国際的非営利団体OWASP（Open Web Application Security Project）が発行している「OWASP Top 10（2021）」に含まれていることがわかる。

ワースト1となった「クロスサイトスクリプティング」（以下、XSS）はWebアプリケーションにおける脆弱性の代表格とも言える。認知度の高い脆弱性でありながら、いまだに根絶されていない。XSSが存在するシステムには、ワースト2の「HTMLタグインジェクション」が共に検出されることが多い。出力データの検証が適切に実施されていないことがうかがえる。

ワースト6の「SQLインジェクション」もまた、メジャーな脆弱性の1つだ。XSSと同じく入出力制御に問題がある。昨今でもなお、SQLインジェクションによる情報漏洩事例が報告されている。データベースの不正操作を許せば、事業活動に必要なデータをすべて消去されるといった最悪の事態も発生しうるため、放置するのは非常に危険である。

独立行政法人情報処理推進機構（IPA）および一般社団法人 JPCERT コーディネーションセンター（JPCERT/CC）に対する届出においても、XSSが58%と約6割を占め、SQLインジェクションもそれに次ぐ多さとのことだ。*1

いずれの脆弱性も、セキュアなWebアプリケーション構築を実践できていないことを証明するものだ。開発の上流工程において、そうした脆弱性が作りこまれないような対策を行うことが大切である。

ネットワーク診断結果

高リスク以上の脆弱性ワースト10

ネットワーク診断結果に関しても、5つに分類された各カテゴリの検出割合（「2021年下半期カテゴリ別脆弱性検出状況」掲載の円グラフ参照）において、前期と比較して特段目立つような差は見られなかった。ただ、「通信の安全性に関する問題」に関しては、「推奨されない暗号化方式の受け入れ」「推奨されないSSL/TLS方式の使用」「脆弱な証明書の検出」に分類される脆弱性項目が、それぞれ200件前後ずつ増加していることがわかった。

リスクレベル高以上の脆弱性で検出数が多い10項目は下表のとおりである。

推奨されないバージョンのSSL/TLS

先に述べた、前期より検出数が増加している「通信の安全性に関する問題」のうち、「推奨されないバージョンのSSL/TLSのサポート」はリスクレベル高以上である。これは、SSL2.0、3.0、またはTLS1.0、1.1を使用した暗号化通信が許可されている場合に指摘している項目で、今期ワースト1の検出数だ。CRYPTREC作成/IPA発行の「TLS 暗号設定ガイドライン」は、2020年7月に第3.0.1版が公開されている。こちらを参考に、SSLの全バージョンとTLS1.1以下を無効にし、もし、TLS1.2、なるべくなら1.3の実装がまだであれば、早急に対応する必要がある。

カテゴリ別の検出結果詳細についてはこちら

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

2022年1月31日2024年2月29日

診断結果にみる情報セキュリティの現状
～2020年上半期　診断結果分析～

SQAT® Security Report 2020-2021年秋冬号

BBSecの診断について

当社では、Webアプリケーション、ネットワーク（プラットフォーム）、スマホアプリ、IoT、パブリッククラウド、ソースコード、標的型攻撃に対するリスク可視化等、様々な局面における診断サービスを提供することで、お客様のニーズにお応えしている。

当社の脆弱性診断サービスは、専門技術者による高精度の手動診断と独自開発のツールによる効率的な自動診断とを組み合わせ、検出された脆弱性に対するリスク評価について、右表のとおりレベル付けしている。お客様のシステム特性に応じた脆弱性の検出、リスクレベルの評価、個別具体的な解決策の提供が適切に行えるよう、高い頻度で診断パターンを更新し、診断品質の維持と向上に努めている。

2020年上半期診断結果

当社では、2020年1月から6月までの6ヶ月間に、14業種延べ533企業・団体、4596システムに対してシステム脆弱性診断を行った。2020年上半期はコロナ禍の影響でテレワークへと移行する企業も多い中、診断のニーズは変わらず存在し、診断案件数は2019年下半期とほぼ同じであった。脆弱性の検出率は以下のとおり。

診断の結果、Webアプリケーション診断では、脆弱性が検出されたシステムが全体の83.9%と、前年同期（2019年上半期）の88.2%に比べて微減しているものの、依然として高い割合である。ネットワーク診断においては、脆弱性検出率は減少を続けているものの、42.8％と4割ほどのシステムに何らかの脆弱性が検出されている。

検出された脆弱性のうち、早急な対処が必要な「高」レベル以上のリスクと評価された脆弱性は、Webアプリケーションでは28.7%、ネットワーク診断では29.7%検出されている。前年同期比（2019年上半期「高」レベル検出率：Webアプリケーション27.0％／ネットワーク診断　23.6%）でいうと、Webアプリケーションはほぼ横ばいだったが、ネットワークは6.1%増えた。ネットワークに関しては、リスクレベルの高い脆弱性は増加傾向にある。当サイトでは、「2020年上半期カテゴリ別脆弱性検出状況」とし、当社診断で検出された脆弱性を各性質に応じてカテゴライズし、評価・分析をした結果をまとめた。以降、診断カテゴリごとに比較的検出数が多かったものの中からいくつか焦点を当ててリスクや対策を述べる。

Webアプリケーション診断結果

Webカテゴリ結果の36.0%を占める「システム情報・ポリシーに関する問題」のうち、「脆弱なバージョンのOS・アプリケーションの使用」についで検出数が多かった、「推奨されない情報の出力」に着目する（検出割合は以下参照）。

システム構築時のデフォルトファイル、ディレクトリや初期画面には、攻撃者にとって有用な情報が含まれていることが多く、攻撃者にシステムへ侵入された場合、その情報をもとにした攻撃に発展し、甚大な被害につながりうる。よって、重要情報を含むファイル等には特に強固なアクセス制御をすべきであり、削除して差し支えない情報は消してしまうことが望ましい。初期画面については、表示しない設定にするのがよいだろう。

不用意な情報の出力の例として、「推奨されない情報の出力」の内訳にある、「WordPress管理者機能へのアクセスについて」をピックアップする。WordPressの管理者機能に対するアクセスが外部から可能だと、「総当り（Brute-Force）攻撃」によって、攻撃者に管理者用の認証を奪取されることで、さまざまな情報の漏洩や改竄をされる危険性がある。そのため、外部から管理者機能へのアクセスが可能な状態にしておかないことがベストだ。業務上外部からのアクセスが必要な場合は、パケットフィルタリング等の強固なアクセス制御をすべきである。

ネットワーク診断結果

NWカテゴリ結果の45.8%が「通信の安全性に関する問題」であった。その中の検出数トップ「推奨されない暗号化方式の受け入れ」に続いて検出数が多かった「推奨されないSSL/TLS通信方式の使用」に焦点をあてる。

DROWN、POODLE、BEASTといった既知の脆弱性が存在するバージョンのSSL/TLSを使用した暗号化通信を許可していると、攻撃者に脆弱性を利用され暗号化通信の内容を解読される恐れがある。推奨対策としては、SSL 2.0、SSL 3.0もしくはTLS 1.0による暗号化通信の使用を停止し、TLS 1.2以上の通信保護に移行することである。

さらに第3位「脆弱な証明書の検出」に注目し、強度の低いハッシュアルゴリズムを使用した証明書を使っている場合について述べる。強度の低いハッシュアルゴリズムは衝突攻撃に弱く、攻撃者が衝突攻撃によって元の証明書と同じ署名の証明書を作ることができ、なりすまし等の被害に繋がる可能性がある。また、主要なブラウザでは強度の低いハッシュアルゴリズムをサポートしておらず、環境によってはユーザがサイトを利用できなくなる可能性もある。よって、本番環境での運用には信頼された認証局から発行された強度の高い証明書が利用されていることを確認すべきである。

カテゴリ別の検出結果詳細についてはこちら

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

2021年11月5日2024年2月26日

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

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（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

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

2021年3月9日2024年2月26日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

出典：「サイバーセキュリティ経営ガイドライン」Ver2.0（経済産業省/IPA）
「中小企業の情報セキュリティ対策ガイドライン」（IPA）

さらに活発化するOSS

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

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

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

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

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

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

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

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

2020年4月23日2024年3月26日

ソースコード診断の必要性とは？目的とメリットを紹介

WEBアプリケーションは、プログラムの集合体であり、ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。このプログラムの集合体は現在では人間から読み書きしやすい言語で書かれていることが多くWebアプリケーションは人間にも読みやすいプログラムのテキスト、ソースコードの集合体と言い換えることができるようになっています。

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことですが、その中でも診断対象によりさまざまなサービスがあります。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは？

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことを指します。
診断対象により、さまざまな脆弱性診断サービスがあります。

まず、企業が開発したWebアプリケーションが挙げられます。
問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。
次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するネットワーク診断があります。
そのほか、近年増加の一途をたどるスマホアプリケーションや IoT機器を対象とした脆弱性診断もあります。

このうち、ソースコード診断とは、アプリケーションのソースコード（開発者が書いたプログラム）を解析して、セキュリティ上および品質上の問題をコーディングレベルで検査する診断のことをいいます。

ソースコード診断

ソースコード診断には、ツールを用いて自動的に処理するツール診断（自動診断）と、セキュリティエンジニアが目視で確認する手動診断があります。

効率的に網羅性を確保できる自動診断ツールの支援は欠かせません。

一方手動診断は、機械的に検出できず、人間による判断が必要な脆弱性を発見します。手動のみで行う場合もありますが、多くはツール診断と組み合わせて網羅性と精度を上げていきます。

ソースコードを開示するため、ソースコード診断はホワイトボックステストと呼ばれます。これに対して、ソースコードや設計書を見ずに、システムの外部からアクセスして脆弱性や動作を検証する方法をブラックボックステストと呼びます。

ソースコード診断の特徴とメリット

ブラックボックステストでは検出が難しい脆弱性がソースコード診断なら検知できる場合があります。具体的には 「ソースコード診断で検出できる脆弱性」で後述します。

ブラックボックステストは、すでにソフトウェアあるいはシステムが機能していることを前提とした、リリース前あるいはリリース後に実施します。これに対して、ソースコード診断はその前段である開発プロセスから実施できるため、テスト結果を受けてプログラムを修正することが可能です。

開発の手戻りを減らすことでコストや工数削減につながります。詳細は「ソースコード診断の有効性」を参照してください。

ソースコード診断を実施する目的

ソースコード診断の目的は、プログラムに作りこんでしまった脆弱性を網羅的に検出することです。開発時に繰り返し実施し、開発者が修正していく運用が想定されています。

ソースコード診断の有効性

ソースコード診断は開発段階初期から実施可能です。リリース直前やリリース後に脆弱性が発見される可能性を抑えることで、より効率的で信頼性の高いシステム開発が可能になります。

※CPE-Coreとはソースコード内の脆弱性と品質面の問題を検査する当社の自動静的解析ツールです。

システムのセキュリティを確保する方法

開発（Dev）、運用（Ops）、セキュリティ（Sec）を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsとは、開発の全工程において、開発チームと運用チームが相互協力し、その一環にセキュリティを組みこむことで、アプリケーション開発のセキュリティを確保していく考え方のことをいいます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

DevSecOpsにおけるセキュリティ対策

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

一般的なセキュリティ対策として多くイメージされている「Webアプリケーション脆弱性診断」は「テスト」「リリース」工程におけるセキュリティ対策の一つ。
その一つ手前工程の「製造」工程におけるセキュリティ対策の一つが「ソースコード診断」です。

セキュアプログラミング

ソースコード診断の前に、そもそもシステムの設計・開発段階で、開発者が脆弱性を作りこまないようにする手法があります。これをセキュアプログラミングと呼びます。セキュアプログラミングで開発し、本当に脆弱性を作りこんでいないかどうかソースコード診断でチェックします。

ソースコード診断で検出できる脆弱性

一般的なWebアプリケーション脆弱性診断（ブラックボックステスト）では検出しにくい脆弱性も、ソースコード診断（ホワイトボックステスト）では発見できる場合があります。
たとえば未使用のコード、ログファイルによる情報の露出、エラーメッセージによる情報の露出などは、ソースコードを直接確認することで検知可能になります。

以下はWebアプリケーション診断とソースコード診断の両方の観点で検出可能な脆弱性です。
ここでは代表的な脆弱性（セキュリティバグ）について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオーバーフロー

プログラムを実行する際に確保するメモリ上のバッファ領域に対して、このサイズを超過するデータを書き込めるようになっているバグです。攻撃者は超過する部分に不正なプログラムを書いて実行します。

フォーマットストリング

プログラム中の、書式設定用の関数（フォーマットストリング）の引数の処理に関するセキュリティバグです。正しくは、引数として不正な値が入力された場合には、処理を止めてエラーメッセージを返さなければなりません。

SQLインジェクション/コマンドインジェクション

SQL（データベースを定義、操作する言語）文や、その他のコマンドが入力された場合でも、エラーにせずに処理してしまうバグです。攻撃者の観点からは、コマンドを注入（インジェクション）する形になるため、この名が付いています。攻撃の入り口はアプリケーション上の通常の入力欄で、ここに不正な値を入力することで攻撃を開始します。

クロスサイトスクリプティング

悪意のあるスクリプト（プログラム）をユーザのコンピュータに注入して、複数のWebサイトをまたいで（クロスサイト）行う攻撃や、その攻撃で利用される脆弱性を指します。

まとめ

・ソースコード診断はソースコード（開発者が書いたプログラム）を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・一般的なWebアプリケーション脆弱性診断では検出しにくい脆弱性も、ソースコード診断を実施することで開発段階から検出ができる

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

2020年4月1日2024年2月26日

診断結果にみる情報セキュリティの現状
～2019年下半期　診断結果分析～

SQAT® Security Report 2020年春夏号

BBSecの診断について

2019年下半期診断結果

当社では、2019年7月から12月までの6カ月間に、14業種延べ537企業・団体、4808システムに対してシステム脆弱性診断を行った。情報セキュリティ対策に重きを置く企業・組織側の姿勢もあり、診断案件数は年々増加している。脆弱性の検出率は以下のとおりである。

診断の結果、Webアプリケーション診断では、脆弱性が検出されたシステムが全体の81.5%と、前年同期（2018年下半期）の84.9%に比べて微減しているものの、依然として高い割合である。ネットワーク診断においては、脆弱性検出率はシステム全体の47.8%であり、2017年下半期以降、減少傾向にあるが、およそ半数のシステムに何らかの脆弱性が検出されている。

検出された脆弱性のうち、早急な対処が必要な「高」レベル以上のリスクと評価された脆弱性は、Webアプリケーションでは26.9%、ネットワーク診断では30.4%検出されている。前年同期比（2018年下半期「高」レベル検出率：Webアプリケーション27.6％／ネットワーク診断　17.8%）でいうと、Webアプリケーションはほぼ横ばいだったが、ネットワークは12.6ポイント増えておりリスクレベルの高い脆弱性が増加傾向にある。当サイトでは、 「2019年下半期カテゴリ別脆弱性検出状況」とし、当社診断で検出された脆弱性を各性質に応じてカテゴライズし、評価・分析をした結果をまとめた。以降、診断カテゴリごとに検出数が多かったものの中から、特筆すべきことに焦点を当ててリスクや対策を述べる。

Webアプリケーション診断結果

Webカテゴリ結果の31.4%を占める「システム情報・ポリシーに関する問題」のうち、最も検出数が多かったのは、「脆弱なバージョンのOS・アプリケーションの使用」である。脆弱なバージョンのOS、アプリケーションを使用している場合、既知の脆弱性の影響を受ける可能性がある。最新バージョンへのアップデートが望ましいが、システム環境における制約等の理由でバージョンアップができないのであれば、必要なセキュリティパッチがすべて適用されていることを確認すべきである。

次にWebカテゴリ結果の検出割合が多かったのは、19.7%を占める「セッション管理に関する問題」。最も検出されたのは、「不適切なセッションタイムアウト」であった。ログインセッションのタイムアウト値が適切に設定されていないと、長時間操作を行わずアイドル状態のままでもセッションが維持されることから、セッションハイジャック等の攻撃が成功する確率が高まるほか、サービス運用妨害（DoS）攻撃につながる可能性もある。セッションタイムアウトは、Webアプリケーションのデフォルト設定として一般的に採用されている30分が望ましいが、ユーザビリティを考慮してタイムアウト値を長くする場合は、追加のリスク緩和策を講じることが推奨される。

ネットワーク診断結果

NWカテゴリ結果の52.3%が「通信の安全性に関する問題」であった。なかでも、「推奨されない暗号化方式の受け入れ」（検出割合は右表を参照）の検出数がトップであり、第2位の「推奨されないSSL/TLS通信方式の使用」と比べて2倍以上の差がある。

サーバがブロック長64ビットのブロック暗号をサポートしている場合、誕生日攻撃（birthday attack）を介して長い期間暗号化されたセッションを復号・解読される「SWEET32」と呼ばれる攻撃の影響を受ける可能性がある。「NVD（National Vulnerability Database）」などに本脆弱性の影響を受ける製品は公表されており、ベンダからも正式な対策が公開されていて、ベンダ情報を参照のうえ対策することが望ましい。

SSL/TLS通信において、強度の低い暗号化方式（RC4、3DESなど）が許容されていると、既知の脆弱性を悪用した攻撃（平文回復攻撃など）により、攻撃者に暗号化されたデータが解読される危険性がある。また、強度が低いハッシュアルゴリズム（SHA-1など）が許容されていると、衝突攻撃に弱くなり証明書の偽造等が可能となる恐れがある。鍵長が128ビット未満の暗号方式については、総当り（Brute-Force）攻撃への耐性が低く、中間者（Man-in-the-Middle）攻撃などの標的になりうる。強度の低い暗号化方式やハッシュアルゴリズムは使用を停止し、SSL/TLSによる通信の保護には鍵長が128ビット以上の暗号化方式を実装するべきである。SSHプロトコルにおいても、攻撃者に暗号文を解読される恐れがあるため、脆弱な暗号化方式およびハッシュアルゴリズムを許容しないことが望まれる。

カテゴリ別の検出結果詳細についてはこちら

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