【第1回】「OWASP Top 10とは?アプリケーションセキュリティの基本を押さえよう」

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

近年、Webアプリケーションを狙ったサイバー攻撃が急増しており、企業にとってWebアプリケーションのセキュリティ強化は欠かせない課題となっています。その中で、世界中のセキュリティ専門家が指標として活用しているのが「OWASP Top 10」です。

今回は、Webアプリケーションの代表的な脆弱性をまとめた「OWASP Top 10」を通じて、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的とし、背景から各脆弱性カテゴリの説明、実例、対策方法までを全3回のシリーズに分けて解説します。

OWASPとは

OWASP(Open Worldwide Application Security Project)は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。開発者やセキュリティ専門家によって構成されており、セキュリティに関するツールやドキュメントなどを無償で提供しています。OWASPは中立かつオープンな立場から情報を発信しており、多くの企業や政府機関がそのガイドラインを信頼し、採用しています。

OWASP Top 10とは

OWASP Top 10は、Webアプリケーションにおける代表的なセキュリティリスクをランキング形式でまとめたもので、最も重要な10の脆弱性カテゴリを示しています。このリストはおよそ3年ごとに更新されており、業界の最新動向や実際の脅威傾向を反映しています。このTop 10は、アプリケーション開発やセキュリティ教育、脆弱性診断の指針として世界中で活用されており、情報システム部門にとってはセキュリティの共通言語ともいえる存在です。

OWASP Top 10:2021概要

OWASP Top 10:2021で挙げられているリスクとその概要について、SQAT.jpでは以下の記事でも取り上げています。あわせてぜひご覧ください。
OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

以下は、2021年に発表された最新版のOWASP Top 10のリストです。

項目番号リスク名概要
A01Broken Access Control
(アクセス制御の不備)
アクセス制御の不備により、本来アクセスできない情報や機能へアクセスされるリスク
A02Cryptographic Failures
(暗号化の不備)
暗号化の不備による機密情報の漏洩や改ざん
A03Injection
(インジェクション)
SQLインジェクションなど、外部から不正なコードを注入されるリスク
A04Insecure Design
(セキュアでない設計)
セキュリティを考慮しない設計により生じる構造的リスク
A05Security Misconfiguration
(セキュリティ設定のミス)
設定ミスや不要な機能の有効化に起因する脆弱性
A06Vulnerable and Outdated Components(脆弱かつ古いコンポーネントの使用)脆弱性を含む古いライブラリやフレームワークの使用
A07Identification and Authentication Failures(識別と認証の不備)認証処理の不備により、なりすましや権限昇格が発生する
A08Software and Data Integrity Failures(ソフトウェアとデータの整合性の不備)ソフトウェア更新やCI/CDの不備により改ざんを許すリスク
A09Security Logging and Monitoring Failures(セキュリティログとモニタリングの不備)侵害の検知・追跡ができないログ監視体制の欠如
A10Server-Side Request Forgery (SSRF)(サーバサイドリクエストフォージェリ)サーバが内部リソースにアクセスしてしまうリスク
出典:OWASP Top 10:2021より弊社和訳

各リスク項目の代表的な脅威事例

項目番号実例企業・事例概要
A01Facebook (2019)他人の公開プロフィールがIDの推測とAPI操作により取得可能だった*8
A02Turkish Citizenship Leak(2016)暗号化されていなかったデータベースから約5,000万人の個人情報が流出*9
A03Heartland Payment Systems (2008)SQLインジェクションにより1億件以上のクレジットカード情報が漏洩*10
A04パスワードリセットの仕様不備(複数事例)多くの中小サイトで、トークンなしにメールアドレス入力のみでリセット可能な設計が確認されている
A05Kubernetes Dashboard誤設定事件(Tesla 2018)管理用インターフェースが公開状態になっており、社内クラウドで仮想通貨マイニングに悪用された*11
A06Equifax (2017)古いApache Strutsの脆弱性(CVE-2017-5638)を放置していたことで1.4億件以上の個人情報が漏洩*12
A07GitHub (2012)認証処理の不備により、セッションを乗っ取られる脆弱性が悪用され、一時的にユーザが他人のリポジトリにアクセス可能に
A08SolarWinds サプライチェーン攻撃(2020)正規のソフトウェアアップデートにマルウェアが仕込まれ、多数の政府機関や企業を含めた組織に影響を与えた
A09Capital One (2019)AWS環境の不適切なログ監視により、Web Application Firewallの設定ミスから約1億600万人分の情報が流出*13
A10Capital One (同上)SSRF攻撃によりAWSメタデータサービスへリクエストが可能となり、内部資格情報を窃取された*14

企業はOWASP Top 10をどう活用すべきか

OWASP Top 10は、単なる「参考資料」ではなく、企業が自社のセキュリティ対策を体系的に見直すための実践的な指針として活用できます。以下に、企業の情報システム部門担当者等が実際に取り入れるべき活用方法を紹介します。

開発プロセスへの組み込み(セキュア開発)

アプリケーション開発において、設計段階からOWASP Top 10を参考にすることで、設計段階から脆弱性を防ぐ「セキュア・バイ・デザイン(Secure by Design)」の思想を組み込むことが可能です。とくにA04「Insecure Design」などはアプリケーション開発の初期段階での対策が鍵となります。

脆弱性診断の評価基準として

外部のセキュリティ診断会社や自社診断の基準としてOWASP Top 10を採用することで、リスクの見落としを防ぎつつ、業界標準の診断を実現できます。

セキュリティ教育・啓発資料として

企業の社員のセキュリティリテラシーを高めるため、開発者・インフラ管理者・経営層を含めたセキュリティ教育プログラムにOWASP Top 10を取り入れることも有効です。定期的な研修やハンズオン形式での演習と組み合わせることで、具体的な攻撃手法や防御策を理解しやすいため、セキュリティ意識の向上につながります。

OWASP Top 10はセキュリティ対策の出発点

OWASP Top 10は、Webアプリケーションの開発やセキュリティ対策に取り組む企業にとって、最も基本かつ重要な指標です。サイバー攻撃の多くは、実はこうした「基本的な脆弱性」から発生しており、OWASP Top 10で挙げられているリスクを理解することがリスク低減の第一歩になります。特に情報システム部門や開発チームは、OWASP Top 10を設計・開発・テスト・運用の各フェーズに取り入れ、継続的なセキュリティ対策を行う必要があります。また、社員へのセキュリティ教育や脆弱性診断サービスの評価基準としても有効活用することで、より実効性の高いセキュリティ体制を構築できるでしょう。

第2回では、API特有の脅威にフォーカスした「OWASP API Security Top 10」をご紹介します。APIを活用している企業にとって、見逃せない内容となっていますので、ぜひあわせてご覧ください。


―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」へ続く―

【連載一覧】

―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」―
―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」―

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

前倒しで対処 -セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とは-

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

シフトレフトとは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。ソフトウェアの開発工程の各フェーズにおいてセキュリティが組み込まれていないと、後工程での手戻りが発生し、修正コストもかかってしまいます。本記事では、シフトレフトによるメリットや開発におけるセキュリティ対策の実施例について解説いたします。

シフトレフト(Shift Left)とは

セキュリティにおける 「シフトレフト(Shift Left)」 とは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。元々この概念は仕様を満たしているか等の検証に対するソフトウェアテストのジャンルで使われていた言葉ですが、近年セキュリティの世界で注目されています。

ソフトウェア開発の主要工程である「設計」→「開発」→「検証」→「運用」の各プロセスは、計画書や図などで、通常左から右に向けて記載されます。図の左側(レフト)、すなわち時間軸の早い段階で脆弱性を作り込まない対策を施した開発を行えば、セキュリティリスクを低減させるだけでなく、品質向上、期間短縮、トータルコスト低減などの効果があります。

セキュアなWebアプリケーション開発を推進する国際NPO「OWASP(Open Web Application Security Project)」もシフトレフトを推奨しており、Googleをはじめとする先進IT企業ではこの考え方を採用したシステム開発を行っています。

シフトレフトの考え方

シフトレフトの考え方では開発工程からセキュリティ診断を組み込むことで、スケジュールに与える影響を最小限に、また計画的かつ定期的に実施頂くことで費用面、人材面のコストを抑えつつセキュリティの堅牢性向上を見込むことができます。

「要件定義」や「設計」等の上流工程の段階からシステム運用までの各フェーズで、セキュリティへの配慮を取り入れることが、より安全なシステムを構築するうえで重要となります。

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

「シフトレフト」と「セキュリティ・バイ・デザイン」「DevOps」「DevSecOps」との違い・関係

シフトレフトと関連する言葉に、「セキュリティ・バイ・デザイン」「DevOps(デブオプス)」「DevSecOps(デブセックオプス)」などがあります。

「セキュリティ・バイ・デザイン(SBD:Security by Design)」とは、開発の企画・設計段階からセキュリティを考慮することです。

「DevOps(デブオプス)」は、ソフトウェア開発チーム(Developer)と運用チーム(Operations)が互いに協力し合い、ソフトウェアとサービスのクオリティを向上させます。「DevSecOps(デブセックオプス)」は、開発チームと運用チームに、セキュリティチーム(Security)が加わり、セキュリティを含めトータルコストを低減しつつ、さらなるクオリティ向上を実現する仕組みです。

セキュリティ・バイ・デザインは概念、DevSecOpsは体制運用、そしてシフトレフトは工程管理の考え方ですが、いずれも、事故やトラブルが起こってから、あるいは脆弱性が見つかってから、といった事後対応のセキュリティ対策ではなく、事前対応、すなわち前倒しで実践する点で一致しています。

シフトレフトによって向上する品質

たとえば、ビルを建てた後になってから、建物の基礎部分に問題が見つかったら改修は容易ではありません。また、社会的な信頼も大きく損なうことでしょう。ソフトウェアも同じで、問題発見が早いほど、改修に必要な労力、費用、時間は少なくてすみますし、信用失墜の危険性も軽減できます。

リリース直前の脆弱性診断でWebアプリケーションに脆弱性が発見されたら、手戻り分のコストがかかるだけではなく、リリース日の遅れや、機会損失の発生を招き、ステークホルダーのビジネスにまで影響を及ぼしかねません。シフトレフトの考え方でセキュリティに配慮しながら開発を進めれば、こうしたリスクを低減でき、ソフトウェアの信頼度が高まります。

シフトレフトによるトータルコスト低減メリット

セキュリティに配慮せず開発を行えば、短期的にはコストを抑え、開発期間を短くすることができるでしょう。しかし、リリース後の運用過程で、もしサイバー攻撃による情報漏えいや知的財産の窃取などが起こったら、発生した損失や対応費用など、長期的に見たコストはより大きくなるでしょう。

こうしたトータルコストの低減効果こそ、シフトレフトによるセキュアな開発および運用の真骨頂です。

シフトレフトとは、発生しうるトラブルに事前に備えるということです。病気にならないように運動をしたり、食生活に気をつけたりといった、ごくごくあたりまえのことです。

つまり、これまでのソフトウェア開発は、その当たり前をやっていなかったとも言えます。シフトレフト、セキュリティ・バイ・デザイン、 DevSecOpsという言葉がいろいろな場面で見られるようになったことは、開発現場が成熟してきた現れでもあります。今後、こういった開発プロセスが新常識となっていくことでしょう。

シフトレフトを普及させた裁判の判決とは

ここで、セキュリティ視点でのシフトレフトの考え方を日本に普及させるきっかけのひとつになったとされる、2014年の、ある裁判の判決をご紹介します。

とある企業の開発依頼で納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性があったことで、不正アクセスによる情報漏えい事故が発生しました。依頼した企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として提訴、東京地方裁判所がそれを認め、開発会社に約2200万円の損害賠償支払いを命じました( 平成23年(ワ)第32060号 )。ただし、全面的に開発会社の落ち度としたわけではなく、発注会社側が責務を果たしていない点については、相当程度の過失相殺を認めています。

この判決は、これまで技術者がいくらセキュリティの必要性を説いても首を縦に振らなかった、セキュリティよりも利益を重視していた「開発会社の経営管理層」と、セキュリティよりもコストと納期を重視していた「発注者」の考えを変えるインパクトを持っていました。

将来事故が起こらないよう、トータルコストを抑えセキュリティに配慮した開発を行う有効な方法としてシフトレフトが採用されたのは、ごく自然なことといえるでしょう。

シフトレフトに基づく開発におけるセキュリティ対策の実施例

シフトレフトに基づく開発におけるセキュリティ対策の実施例は以下のとおりです。

●セキュリティ・バイ・デザイン
まず、セキュリティ・バイ・デザインの考え方に基づいて、企画・設計段階からセキュリティを考慮しましょう 。

●セキュアな開発環境
開発は、脆弱性を作り込まないようにするフレームワークやライブラリなど、セキュアな開発環境を活用して行います。

●ソースコード診断
開発の各段階で、プログラムコードに問題がないかを適宜検証するソースコード診断を実施します。

●脆弱性診断
もし、どんなセキュリティ要件を入れたらいいかわからなくても、独立行政法人情報処理推進機構(IPA)などの専門機関がいくつもガイドラインを刊行しています。「このガイドラインを満たすような開発を」と依頼して、それを契約書に記載しておけばいいでしょう。ガイドラインの中身を完全に理解している必要はありません。

リリース前や、リリース後の新機能追加等の際には、必ず事前に脆弱性診断を行います。また、脆弱性が悪用された場合、どんなインシデントが発生しうるのかを、さらに深く検証するペネトレーションテストの実施も有効です。

シフトレフト視点での発注の仕方

シフトレフトは主に開発者側の考え方です。では、ソフトウェア開発を依頼する発注者はどうすればいいのでしょうか。

まず、発注の際には必ずセキュリティ要件を入れましょう。納品されたシステムやWebアプリケーションにセキュリティの問題が発見された際に対応を要求しやすくなります。

もしそれによって見積額が上がったら、トータルコストのこと、シフトレフトというこれからの新常識のことを思い出していただきたいと思います。

・安全なウェブサイトの作り方(IPA)
https://www.ipa.go.jp/security/vuln/websecurity.html

シフトレフトの実現に向けて

とはいえ、今回ご紹介したシフトレフトの考え方が社会に広く普及するまでには、もう少し時間がかかりそうです。

システムライフサイクルの早い工程(シフトレフト)でのセキュリティ対策の実施例の一つに、「ソースコード診断」があります。

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

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

SQAT.jp を運営する株式会社ブロードバンドセキュリティが、リリース直前のWebサービスに脆弱性診断を行うと、山のように脆弱性が発見されることがあります。

その脆弱性の中には、2014年の裁判で開発会社の債務不履行とされたSQLインジェクションのような、極めて重大なものが含まれていることも多くあります。

業界が成熟し、シフトレフトによるセキュリティ対策が実践されていけば、脆弱性診断というサービスの位置づけ自体が将来変わることすらあるかもしれません。たとえば自動車のような、安全規格に基づいて設計製造された製品における出荷前の品質チェック、あるいは監査法人による会計監査のように、「きちんと行われている前提」で実施する広義のクオリティコントロール活動の一環になるかもしれません。

SQAT.jp は、そんな未来の到来を少しでも早く実現するために、こうして情報発信を行い続けます。

まとめ

・シフトレフトとは上流工程でセキュリティを組み込み、トータルコストを抑えるという考え方
・セキュリティを考慮せずにWebサービスを開発し提供するのは、たとえるなら建築基準法を考慮せずにビルを建ててテナントを入居させるようなもの
・セキュリティをコストととらえ費用を惜しむと、将来的により高い出費を余儀なくされる可能性がある
・シフトレフトによるセキュリティ対策には、セキュリティ・バイ・デザイン、セキュリティ要件の明示、セキュアな開発環境、早期段階から適宜に実施する各種セキュリティ診断等がある

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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


Security Serviceへのリンクバナー画像

BBsecコーポレートサイトへのリンクバナー画像

セキュリティ緊急対応のバナー画像

セキュリティトピックス動画申し込みページリンクへのバナー画像