ゼロ・トラストはどこから始まり、なぜ重要なのか? / Where Does Zero Trust Begin and Why is it Important?(転載)



 ゼロトラストは、情報セキュリティアーキテクチャの重要な転換です。これは、過去の境界線の防御を詳細に記述したモデルから、最も価値のあるもの、つまりデータに近い制御層へと私たちを連れてきます。フォレスター社のアナリストが最初にゼロトラストを定義したとき、ゼロトラストは攻撃者の横移動を防ぐためにアプリケーションを隔離するネットワークに焦点を当てていました。その後、マイクロサービスを含むコンポーネント間の認証と保証を提供することで、粒度が高く浸透したものへと進化してきました。

ゼロ・トラストのメリットがますます明らかになるにつれ、このモデルの普及は明らかになり、NIST Special Publication 800-207で定義されているように、信頼されたコンピューティング・ベースとデータ中心の制御に依存しています。では、ゼロ・トラストがより普及するにつれ、それは何を意味するのでしょうか。IT およびサイバーセキュリティの専門家は、どのようにして導入を管理し、その有効性の保証を維持するのでしょうか?

ゼロトラストアーキテクチャ。絶対に信頼しない、常に検証する

ゼロトラストアーキテクチャは、スタックのどの層も、それがハードウェアであろうとソフトウェアであろうと、基礎となるコンポーネントを信頼していないという点を強化します。そのため、セキュリティプロパティは、最初の使用時と断続的な使用時に、すべての依存関係と相互依存関係に対して期待通りであることを保証するために検証されます(ゼロトラストの動的な認証と検証の考え方)。各コンポーネントは、隣接するコンポーネントや依存するコンポーネントが脆弱である可能性があるかのように構築されます。そのため、個々のコンポーネントは、それが主張された信頼レベルを保証するコンポーネントである必要があり、侵害または侵害の試みを検出できる必要があると想定しています。

これは、ゼロトラストがすべての層で分離の原則を植え付けるという点で、少し混乱を招くパラダイムである可能性があります。これは、コンポーネント間のいわゆるゼロトラストのポイントを強制しますが、セキュリティ特性とアイデンティティの検証は、期待される制御が満たされていることを保証するために継続的に実行されます。あるコンポーネントは、依存関係の期待される特性が保証されていない場合、実行しないことを選択するかもしれません。ゼロトラストアーキテクチャは、「絶対に信頼せず、常に検証する」ことを保証します。これにより、各コンポーネントの横移動や特権実行の検出と防止が可能となり、システムとソフトウェアの保証が向上します。

基本理念

アイデンティティ、認証、認可、アクセス制御、暗号化は、コンポーネント間の保証を検証するために意図的かつ動的な意思決定が継続的に行われるゼロ・トラスト・アーキテクチャの中核的な考え方の一つです。ゼロ・トラストは、フォレスター社の概念として生まれた結果、ネットワーク層で議論されることが多いですが、ゼロ・トラストの定義は、過去10年間でかなり進化し、インフラストラクチャ、デバイスのファームウェア、ソフトウェア、およびデータにまたがる普及した概念となっています。

ゼロトラストは、ネットワークに関連してよく議論されますが、ネットワークセグメントごとにアプリケーションを分離し、強力な暗号化や動的認証などの制御が満たされていることを保証します。ゼロトラストはマイクロサービスレベルでも適用でき、サービス間の検証を通じて制御と測定の保証を提供します。このモデルを詳細に適用することで、攻撃者の横移動の防止と検出がさらに強化されます。

インフラストラクチャの保証

ゼロトラストは、インフラストラクチャの保証から始まります。Hardware root Of Trust (RoT)は、Trusted Platform Module(TPM)にバインドされた暗号化されたアイデンティティで不変です。このインフラストラクチャ保証の例では、ゼロトラストアーキテクチャの原則を説いています。ブート時に、システムはまず、ハードウェアコンポーネントが期待通りであることを確認します。

次に、システムブートプロセスは、システムと各依存関係を、TPM 内の暗号化 ID を使用してデジタル署名で証明された、期待される測定値を含む、いわゆる「ゴールデンポリシー」のセットに対して検証し始めます。ポリシーの比較が一致しない場合は、プロセスが再起動されたり、システムのブートプロセスが停止されたりします。ハードウェアとソフトウェアベースの RoT オプションはいくつかありますが、ブートからファームウェアと BIOS の回復力のガイドラインは、一般的にポリシーと測定値の開発に従います。

認証は、ブートプロセスの各段階で RoT によって署名され、依存するコンポーネントを識別すると同時に、信頼の保証を提供するために使用されます。依存関係は連鎖させることもできますし、個別に検証することもできます。これらのアテステーションは実行時にも提供され、動的認証とアクセス制御(この場合はインフラストラクチャコンポーネント)の信頼ゼロ要件をサポートする。アテステーションは、コンポーネントの身元を確認するための要件を支援し、コンポーネントの保証を提供するために不可欠なものです。

コンポーネントやソフトウェアに侵入した攻撃者は、脅威であり続けるため、この動的で定期的な検証と認証で生き延びる必要があります。また、攻撃者は、権限をエスカレートさせたり、互いに信頼できない分離されたコンポーネント間で横方向に移動したりする方法を見つけ出さなければなりません。

信頼されたコントロールセット

NIST の Firmware Resiliency Special Publication に基づいた Trusted Computing Group (TCG) の Reference Integrity Manifest は、ファームウェアのポリシーと測定のための信頼できるコントロールを提供します。スタックを上げていくと、ゼロトラストに必要な検証を提供するための信頼されたコントロールセットには、CIS コントロールと CIS ベンチマークが含まれています。NIST、CIS、TCG などの信頼された第三者は、コントロールとベンチマークの要件を設定するために必要な外部で確立された検証プロセスを提供する。この例としては、特定の保証レベルのCISオペレーティングシステムまたはコンテナベンチマークに準拠するために使用される証明書が挙げられる。

ゼロ・トラストへのシフトを支える証拠は?

興味深いことに、ゼロ・トラスト・アーキテクチャが形になり始めたのとほぼ同時期に、ロッキード・マーチンはサイバーキルチェーンを開発した(2011年)。Cyber Kill Chain は、攻撃の段階を分離し、段階間での緩和と検知の防御を可能にするために最初に定義されました。MITRE ATT&CK フレームワークは、ロッキード・マーチンのモデルを基礎に、使用から学んだギャップや進化する脅威の状況を考慮して、今日では主に使用されている。本論文では、相関プロセスを単純化するためにサイバーキルチェーンを使用するが、MITRE ATT&CK フレームワークに抽象化することも可能である。

ロッキード・マーチンのキルチェーンは、サプライチェーン攻撃を含む高度な持続的脅威攻撃(APT)の巧妙化に対応するために開発されました。認証を介して(動的に)身元を証明する要件を含む、攻撃フェーズ間の防御と制御を実装することで、攻撃者の横移動や特権昇格の試みをより簡単に検知できるようになりました。キルチェーンの早い段階で検知と防御を行うことは、攻撃の成功(データの流出やネットワーク内の混乱など)を防ぐために理想的である。

検出と防御の技術をスタック内やアプリケーションや機能全体に広く適用し、認証済みコンポーネントを検証するために動的アクセス制御を使用することで、ゼロトラストのアーキテクチャのテネ ットをサポートし、キルチェーンの早期検出を可能にしています。ゼロトラストの考え方が機能している証拠は、攻撃者の滞留時間パターンによって証明されているように、キルチェーンの検出制御と併用して展開することを考慮すれば明らかです。

ドウェルタイムの低減

キルチェーンが初めて使用されて以来、攻撃者の滞留時間(攻撃者がネットワーク上で検知されずに留まる時間)は劇的に短縮されてきました。これは、地域によってサイバーキルチェーンとゼロトラストの防御策が採用されたことで、世界的な滞留時間と地域的な滞留時間の両方が変化したことで明らかになっています。FireEyeのM-Trendsの年次報告書によると、世界の滞留時間の中央値は2013年に229日、2020年の報告書では56日となっています。ゼロトラストのアーキテクチャパターンとキルチェーンとMITRE ATT&CKの防御フレームワークの採用には格差があることが知られており、地域別の数字もこのアーキテクチャアプローチの成功を裏付けています。

その両方をいち早く取り入れたのがアメリカであることが知られていました。2017年を例に挙げると、アメリカ大陸の滞留時間の中央値は75日、アジアの滞留時間の中央値は172日でした。小規模な組織や、どの地域でもリソースの少ない組織は、どの時点でも、大規模でリソースの豊富な組織とは大きく異なる滞留時間を経験する可能性があります。滞留時間の数値は、これらの管理が成功していることを具体的なデータで実証するのに役立つ。

ゼロトラストは、アプリケーションが分離されたネットワークのみの定義から、すべてのコンポーネント間の予期せぬ動作の検出をサポートするために、より詳細なレベルへと進化しました。ゼロトラストとロッキードのキルチェーンの間の論理的なつながりは、モデルの明確な価値を示しています。これはまた、ゼロ・トラストの将来を、インフラストラクチャの起動からマイクロサービスレベルに至るまで、その身元と保証レベルが検証されていることを保証する分離されたコンポーネントの基盤の上に構築され、ますますデータ中心になっていくと予測することにも役立ちます。

NIST SP 800-207では、ゼロトラストを次のように定義しています。

"ゼロ・トラスト(ZT)は、ネットワークが危殆化していると見られる状況下で、情報システムやサービスにおいて、正確で、要求ごとに最小の特権を持つアクセス決定を実施する際の不確実性を最小化するために設計された概念と考え方の集合体を提供します。ゼロ・トラスト・アーキテクチャ(ZTA)は、ゼロ・トラストの概念を利用した企業のサイバーセキュリティ計画であり、コンポーネントの関係、ワークフロー計画、アクセス・ポリシーを包括しています。したがって、ゼロ・トラスト・エンタープライズとは、ゼロ・トラスト・アーキテクチャ計画の成果物として、企業のネットワーク・インフラストラクチャ(物理的および仮想的)と運用ポリシーのことを指します。"

以下のリストは、NIST CSRC Publication SP 800-207から引用したものです。

  1. すべてのデータソースとコンピューティングサービスは、リソースと見なされます。
  2. 場所に関係なく、すべての通信が安全に行われます。
  3. 個々の企業リソースへのアクセスは、セッションごとに許可されています。
  4. リソースへのアクセスは動的なポリシーによって決定されます。
  5. 所有するすべてのデバイスと関連するデバイスは、可能な限り最も安全な状態になっています。
  6. すべてのリソースの認証と認可は動的であり、厳密に実施されます。
  7. ネットワークインフラの現状をできるだけ多くの情報を収集し、セキュリティ姿勢の向上を図る

ロッキードのキルチェーンの目的は、脅威を積極的に検知することである。ゼロ・トラストの原則は、キルチェーンの段階に沿った予防と検出を支援します。

ロッキードのキルチェーン

  1. 偵察。メールアドレス、会議情報、ネットワークデータの収集
  2. 武器化 配信可能なペイロードへのバックドアを持つエクスプロイトの結合
  3. 配信すること。兵器化されたバンドルをメール、ウェブ、USBなどを介して被害者に配信すること
  4. エクスプロイテーション。脆弱性を利用して被害者のシステム上でコードを実行すること
  5. インストールすること。アセットへのマルウェアのインストール
  6. コマンド&コントロールC2 犠牲者を遠隔操作するためのコマンドチャンネル
  7. 目的に対する行動。キーボードを手で操作することで、侵入者は本来の目的を達成することができます。

みずほ、甘い想定重ね被害拡大 ATM障害、顧客目線の業務体制課題(転載)~みずほ10年ごとに大規模障害を起こす?~


みずほ、甘い想定重ね被害拡大 ATM障害、顧客目線の業務体制課題

データ移行で発生したみずほ銀行のシステム障害についてまとめてみた

2021年2月28日、みずほ銀行でシステム障害が発生し、全国で同行のATMが利用できなくなる、キャッシュカードが取り込まれたまま戻ってこないなどのトラブルが発生しました。ここでは関連する情報をまとめます。

取り込まれ戻ってこないキャッシュカード

f:id:piyokango:20210301045353p:plain
みずほ銀行サイト上に掲載されたシステム障害発生の案内

障害が発生したのは2021年2月28日11時頃。障害により各地で生じた影響は以下が報じられるなどしている。なお、法人向けに提供されるサービスでは今回のシステム障害による不具合は確認されていない。

  • みずほ銀行の自行ATM5,395台の内、54%にあたる2,956台が停止し(2月28日19時40分頃時点)、預金引き落とし等が出来なくなった。台数はその後訂正され、最大4,318台が停止していたことが明らかにされた。 
  • 障害発生中は、ATMよりキャッシュカード、通帳が機器から戻されない事象が発生。取り出せなくなる影響を受けた件数は5,244件。
  • インターネットバンキング(みずほダイレクト)の一部の取引(定期預金、グローバル口座サービス)でもシステム障害が発生。



日時出来事
2021年2月28日午前定期預金のデータ移行作業中にシステム障害が発生。
同日 11時頃全国に設置されたみずほ銀行の一部のATMが利用できなくなる障害が発生。
同日 13時頃みずほ銀行がWebサイト上にシステム障害の発生を掲載。
同日 午後みずほ銀行がWebサイト上にデータ移行が原因であり復旧対応中であることを掲載。
同日 夜システム障害の復旧完了。
2021年3月1日7時店舗外のATMなどを中心に一部再開が出来ず。
同日 9時頃全国支店に設置されたATMなどをすべて復旧。
同日 15時頃稼働確認ができていなかった店舗外42台の復旧を確認。
同日 夕方みずほ銀行が今回のシステム障害について記者会見。頭取が謝罪。
2021年3月2日キャッシュカード、通帳の返却が8割完了。
2021年3月3日金融庁がみずほ銀行に報告徴求命令。

他行利用による手数料は後日返金

  • ATM不具合はイオン銀やゼブン銀、ローソン銀のATMでは発生しておらず、同行ATM以外を利用した際にかかる手数料は後日返金される。これ以外に代替手段により生じた費用についても取引店舗に相談するように案内が行われている。
  • ATMに取り込まれたままのキャッシュカードや通帳は後日返却対応が行われる。他行キャッシュカードの場合は他行経由での返却手続きとなることが案内されている。

機器再起動で順次復旧

  • Webサイト上にはシステム障害は解消したと掲示されている(3月1日4時頃確認)。
  • インターネットバンキング(みずほダイレクト)は3月1日0時時点で復旧済み。
  • ATMや通帳繰越機は機器の再起動が必要で、2月28日21時までに復旧作業は完了しなかった。
  • 再起動が行われた店舗より順次復旧していると説明し、2021年3月1日サービス開始時(朝7時)までの復旧を目指していたが、3月1日7時開始予定の拠点の内、主に銀行店舗外に設置されたATMが復旧できていないとしてリストが掲示された。8時以降にサービスを開始予定している拠点で現在作業中となっているのは51か所とした。(3月1日9時半時点)

データ移行中の不具合が原因


事前見積を超える処理量でシステム過負荷

www.youtube.com

  • 3月1日の記者会見でデータ移行と月末処理による過負荷が障害の原因であったことが明らかにされた。当時対応が行われていたのは定期預金のデータ移行45万件と月末処理25万件の70万件。
  • 通常は実施しない定期預金のデータ移行は事前のテストで処理量を見積もっていたが、月末に行っている25万件が通常より多く、結果として全体の処理量が想定を上回ってしまった。
  • システム障害の責任については、みずほ銀行とグループが責任をもって対処するものと頭取が回答。
  • 通常体制でトラブルシュートが可能と判断したことが障害への対応が後手になった背景にある。マニュアル通りに対応しようとしたことが要因と記者会見で回答している。

金融庁が報告徴求命令

  • 金融庁は2021年3月3日にみずほフィナンシャルグループ、みずほ銀行に対し報告徴求命令を出した。
  • 障害発生日に銀行側と連絡が取れずに長時間待たされるなど多数の顧客に影響が及んだ事態を重く見たため。
  • 報告の期限日は2021年3月末。

トラフィック分析演習(2021年2月版) - あなたは#pcapとアラートのリストを取得します - あなたのタスクは、インシデントレポートを書くことです。 / Traffic Analysis Exercise - you get a #pcap and a list of alerts - Your task is to write an incident report(転載)


TRAFFIC ANALYSIS EXERCISE - ASCOLIMITED

ASSOCIATED FILES:

  • 2021-02-08-traffic-analysis-exercise.pcap   (11,145,351 bytes)
  • 2021-02-08-traffic-analysis-exercise-alerts.jpg   (2,237,669 bytes)
  • 2021-02-08-traffic-analysis-exercise-alerts.txt   (6,442 bytes)

NOTES:

  • All zip archives on this site are password-protected with the standard password.  If you don't know it, look at the "about" page of this website.

SCENARIO

LAN segment data:

  • LAN segment range:  10.2.8.0/24 (10.2.8.0 through 10.2.8.255)
  • Domain:  ascolimited.com
  • Domain controller:  10.2.8.2 - AscoLimited-DC
  • LAN segment gateway:  10.2.8.1
  • LAN segment broadcast address:  10.2.8.255

 

TASK

  • Write an incident report based on the pcap and the alerts.
  • The incident report should contains 3 sections:
  • Executive Summary: State in simple, direct terms what happened (when, who, what).
  • Details: Details of the victim (hostname, IP address, MAC address, Windows user account name).
  • Indicators of Compromise (IOCs): IP addresses, domains and URLs associated with the infection.  SHA256 hashes if any malware binaries can be extracted from the pcap.

     

    ANSWERS

    • Click here for the answers.

    悲報!タイ国際航空、エアバスA380型機を退役 / Sad: Thai Airways Retiring Airbus A380 Fleet(転載)


    Sad: Thai Airways Retiring Airbus A380 Fleet:

    タイ航空がコロナウイルスの流行でA380を退役させる最初の航空会社になるようです。

    タイ国際航空、エアバスA380型機6機すべてを退役させる

    タイ国際航空は現在リストラを進めており、その一環として数種類の航空機が退役することが明らかになりました。最も重要なのは、タイ国際航空が6機のエアバスA380を退役させることです。

    これにより、タイ国際航空はエールフランス航空、ルフトハンザ航空に次いで3社目のA380全機を退役させることになりました。さらに、エティハド航空とカタール航空のA380フリートの将来については、まだ審査対象外となっています。

    タイ国際航空はA380型機の戦略をあまり練ったことがありませんでした。

    • 航空会社のほとんどは威信のためにA380を購入したようで、それがタイ国際航空の長年にわたる多くの悪い決断の原動力になっているようです。
    • ロンドン、フランクフルト、東京などへのフラッグシップ路線にA380を使用していたが、ロードファクターや歩留まりに苦戦していた。
    • このような少ないA380の編成は、あまり効率的ではありませんでした。

    タイ国際航空はA380の引退に加えて、ボーイング747とエアバスA330のフリートを引退させる予定です。タイ国際航空が747の全機を売りに出したことから、タイ国際航空が747を引退することはすでに知っていました。A380の場合、タイ国際航空は以前に2機を売りに出していたので、タイ国際航空がこれらの飛行機のうち4機だけを保有することを示唆しています。

    Thai Airways’ 747 first class

    タイ国際航空のファーストクラス終了?

    この時点では、タイ航空がファーストクラスを廃止する可能性が高いと思われますが、それは確かに残念です。確かに航空会社はこの商品でお金を儲けたことはなく、むしろ威信をかけず、王族のための商品にしていたのです。

    近年、航空会社は747とA380のファーストクラスしか提供していませんでしたが、この2機が退役したことで、タイ国際航空のファーストクラスの将来性はあまり感じられません。

    興味深いことに、タイ国際航空は間もなく3機の新しいボーイング777-300ERを受け取ることになっている。しかし、この時点で航空会社がこれらの飛行機の引き渡しを受けるかどうかは疑問であり、それに関しては、航空会社がたった3機の飛行機のために別々のサービスを提供し続けるとは思えない。

    私はいつもタイ国際航空のファーストクラスでのフライトを楽しんできましたが、特にバンコクのタイ国際航空の素晴らしいファーストクラスラウンジは、世界でも最高のラウンジの一つだと思っていたので、寂しくなります。

    Thai Airways’ excellent first class lounge Bangkok

    ボトムライン

    タイ国際航空がエアバスA380の6機を退役させることになり、A380の全機を退役させる航空会社は3社目となります。その上に747とA330も退役することになりますが、それはすでにわかっていました。

    これで、歴史的にはA380と747に限定されていたことを考えると、タイもファーストクラスを廃止する可能性が高いと思われます。

    タイ国際航空が計画していたA380の引退をどう思いますか?

    お客様の個人情報流出に関するお詫びについて 株式会社 NTT データ数理システム(転載)~お詫びメールについて不審メールではないか確認依頼を受けたのだが。。。。~



    [PDF] お客様の個人情報流出に関するお詫びについて 株式会社 NTT データ数理システム 2021年2月26日 msi.co.jp/paper20210226.…: [PDF] お客様の個人情報流出に関するお詫びについて
    株式会社 NTT データ数理システム
    2021年2月26日
    msi.co.jp/paper20210226.…

    2021年に注目すべきバグバウンティプログラムトップ5 / Top 5 Bug Bounty Programs to Watch in 2021(転載)

    bug-bounty-program.jpg

    Top 5 Bug Bounty Programs to Watch in 2021

    ガートナー社は、バグバウンティやクラウドセキュリティテストのための専用のマジック・クアドラントをまだ持っていませんが、ガートナー社のピアインサイトでは、すでに「アプリケーションクラウドテストサービス」カテゴリで24社のベンダーをリストアップしています。

    国際的なセキュリティ研究者の知識と専門知識を活用して、既存のソフトウェアテストを強化したいと考えている方のために、最も有望なバグバウンティプラットフォームのトップ5をまとめました。

    1. HackerOne

    数多くの評判の高いベンチャーキャピタリストに支えられたユニコーンである HackerOne は、おそらく世界で最もよく知られ、認知されている Bug Bounty ブランドです。

    最新の年次報告書によると、1,700社以上の企業がHackerOneプラットフォームを信頼して、社内のアプリケーション・セキュリティ・テスト能力を強化しています。レポートによると、同社のセキュリティ研究者は、2019年だけで約4000万ドル、累積では8200万ドルのバウンティを獲得しています。

    HackerOneは、米国防総省や米陸軍の脆弱性開示プログラムなど、米国政府のバグバウンティプログラムを主催していることでも有名です。バグバウンティや脆弱性開示プログラム (VDP) の他の商用プロバイダと同様に、HackerOne は現在、世界中から集められた、審査済みのセキュリティ研究者によるペネトレーションテストサービスも提供しています。HackerOneは、ISO 27001やFedRAMP認証などのセキュリティ認証の確固たるポートフォリオを持っています。

    2. BugCrowd

    サイバーセキュリティの専門家であるケイシー・エリスによって設立されたBugCrowdは、おそらく最も創造的で独創的なBug Bountyプラットフォームです。BugCrowdは、従来のクラウドセキュリティテストサービスだけでなく、攻撃面の管理やIoT、API、さらにはネットワークを対象とした幅広いペネトレーションテストサービスを積極的に推進しており、急速に成長するクラウド労働市場で競合他社の一歩先を行っている。

    BugCrowdはまた、多数のソフトウェア開発ライフサイクル(SDLC)統合能力を適切に宣伝しており、裕福なクライアントにとってDevSecOpsのワークフローをより迅速かつ容易にしている。

    BugCrowdは、Amazon、VISA、eBayなどの業界大手や、有名な(ISC)²サイバーセキュリティ教育協会のためのバグバウンティプログラムを主催していることで有名です。BugCrowd University、継続的なセキュリティウェビナー、BugCrowdが顧客や研究者のためにスマートに企画したトレーニングのおかげで、セキュリティ研究の初心者の多くがBugCrowdをよく知っています。

    3. OpenBugBounty

    急上昇中の OpenBugBounty プロジェクトは、我々のリストの中で唯一の非営利の脆弱性開示および Bug Bounty プラットフォームです。そのAlexaランクによると、OpenBugBountyは、ほとんどの商業的な競合他社を成功裏に凌駕しようとしています。

    1,200以上のアクティブなBug Bountyプログラムで、OpenBugBountyはまた、問題が非侵入的な手段によって検出された場合、任意のウェブサイト上のセキュリティ問題の調整された開示を許可します。バグバウンティプログラムの作成は完全に無料で、ウェブサイトの所有者は研究者に金銭的な支払いをする必要はありませんが、少なくとも研究者に感謝し、彼らの努力に公的な推薦を提供することが奨励されています。

    OpenBugBountyは、A1 Telekom AustriaやDrupalなどの企業向けにBug Bountyプログラムをホストしており、これまでに2万人以上のセキュリティ研究者と80万件近くのセキュリティ脆弱性を提出している。同プラットフォームによると、そのポリシーと開示プロセスはISO 29147規格に基づいているという。

    また、OpenBugBountyは、研究者が発見した内容を公開しない限り、脆弱性の詳細を秘密にする一方で、プラットフォームへの無料APIを提供することで、国のCERTや法執行機関と協力している。

    4. SynAck

    Intel CapitalやKleiner Perkinsなど、多くの有名VCファンドから支援を受けているSynAckは、2015年から2019年まで4回連続で「CNBC Disruptor」企業に選ばれています。SynAckは商用のBug Bountyプラットフォームの頂点に立っており、Gartnerの「Top 25 Enterprise Software Startups」にも選出されています。

    セキュリティの先見者であり、米国の国家安全保障機関の評判の高いベテランであるジェイ・カプランとマーク・カーによって設立されたSynAckは、「レッドチーム」(SRT)として知られる徹底的に吟味されたサイバーセキュリティ研究者の精鋭チームを提供しています。SynAck によると、SRT グループは、検証された経歴と信頼できる業界経験を持つセキュリティ専門家で構成されています。

    SynAckは、レッドチームに対して包括的なデューデリジェンスを実施し、将来の分析やレビューのために彼らの活動をすべて記録することで、信頼できるクラウドセキュリティテストサービスのリーダーとしての地位を確立しています。最後に、SynAckは、Microsoft、AWS、HPEなどの業界リーダーとのパートナーシップや技術提携を成功させ、さらなる成長の可能性を示しています。

    5. YesWeHack

    YesWeHackは2021年の新星です。ヨーロッパのバグバウンティと脆弱性開示企業の一つであるYesWeHackは、厳格なプライバシーとデータ保護を主な関心事とするEUベースの企業を効率的に誘致しています。最近では、YesWeHackは2020年にアジアで250%の成長を記録したと発表しており、ヨーロッパのスタートアップ企業がグローバルなスケールアップが可能であることを証明しています。

    BugCrowdと同様に、YesWeHackも人的資本に投資する準備が整っています。昨年、YesWeHack DOJOプラットフォームを利用して、バグバウンティハンターがハッキングスキルを磨くためのトレーニングプログラムを開始しました。これは、特定のセキュリティ脆弱性や遊び場に焦点を当てた入門コースとトレーニング課題を特徴としています。

    DOJOを利用することで、世界中のセキュリティ研究者はソフトウェアのセキュリティテストのスキルを向上させることができます。最後に、YesWeHackは、フランスのOVHコングロマリットのようなヨーロッパの評判の高い顧客を引き付ける能力を説得力を持って示しています。

    この記事では、5つのバグバウンティプラットフォームを紹介しましたが、ヨーロッパの倫理的なハッカーのネットワークをリードするIntigritiをはじめ、他にも優れたユニークなプラットフォームはたくさんあります。

    バグバウンティは、純粋なクラウドセキュリティテストからオールインワンのサイバーセキュリティプラットフォームへの転換を始めており、古典的な侵入テストやその他無数のサービスを提供しています。今日では、彼らの提供するサービスが従来のMSSPやサイバーセキュリティベンダーに対してどの程度の成功を収めるかを予測することは難しいが、Bug Bountiesは強力な可能性を秘めた新しい市場のニッチを生み出したことは間違いない。

    オープンでフリーなOpenBugBountyプロジェクトは、数十年前にオープンソースのLinuxがマイクロソフトに対して行ったように、ビジネスに成熟をもたらし、後に数十億ドル規模のレッドハットのビジネスを生み出しました。

    これは、バグバウンティ市場が大きくなり、競争が激化している一方で、新規参入者がまだゲームに参加していることを示している。今後は、ベンチャーキャピタルや M&A によるクラウドセキュリティ市場のさらなる拡大が期待されます。

    最先端のSOC(セキュリティオペレーションセンター)では何が行われているのか?(転載)~NTTセキュリティのケース~



    ブログで「最先端のSOC(セキュリティオペレーションセンター)では何が行われているのか?」を公開しました。https://insight-jp.nttsecurity.com/post/102gm2e/soc:

     

    はじめに


    「SOC(セキュリティオペレーションセンター)」というワードからどのようなことを思い浮かべますでしょうか?


    生体認証で厳重に管理された場所、サイバーチックな巨大モニター、24/365で稼働しているなど、外形的なイメージは沸いてくるかもしれません。しかし、具体的に「中」で何が行われているのかという点は想像がしにくいのではないでしょうか。SOC内の活動は大々的に発信されることが少なく、企業・組織によってもその特性が異なっていたりもしますので無理もありません。


    今回の記事では、SOCの「中」にスポットライトを当てるべく、弊社のSOC(正確にはセキュリティオペレーション部)ではどのような業務が行われているかを解説していきます。


    SOC業務の全体像


    弊社の場合、お客様が導入したセキュリティ製品を保守・運用するビジネスが先にあり、その後に、SIEMなどを駆使してログ・データを詳細に見る分析ビジネスが加わったという経緯から、オペレーション業務分析業務の大きく二つが存在しています。もともとはチームとしても分離されていたのですが、近年では縦割になってしまっていたチームの在り方を変えるべく、共通的な業務は連携して行う体制に移行してきています。


    MSS(マネージドセキュリティサービス)という観点で見ると、オペレーション業務はIPS/IDSやUTM、FWなどのセキュリティ製品あるいは同種の機能を持つクラウド型セキュリティサービスそのものを管理対象とした業務、一方で分析業務はそれらから出力されるログやパケットキャプチャなどのデータあるいは悪性ドメイン情報、マルウェア検体、攻撃手法などのインジケーターやインテリジェンスを管理対象とした業務と言えます。


    それぞれの業務について


    ここからは一つ一つの業務について説明していきます。各業務は数名~二十名程度のメンバーにより構成されています。


    リアルタイム監視


    お客様に提供しているセキュリティ製品やサービスの稼働状況を24/365で監視し、正常に動作していない場合、障害対応としてハンドリングし、セキュリティシステム環境の安定提供を実現する業務。


    デバイスマネジメント


    お客様に提供しているセキュリティ製品やサービスの設定変更依頼の対応や、シグネチャやパターンファイルのアップデートの対応を実施する業務。


    サービスオーダー


    グローバル含めた関連部署と同調しながら、各種の開通手続き、システム設定を実施し、お客様にスムーズにSOCサービス提供を開始するための業務。サービス提供中においても、追加オーダーや変更オーダーに柔軟に対応する。


    グローバル連携


    世界各国にあるSOCと協力し、分析や運用に関わる、グローバル全体でのナレッジ共有や、日本内製システムのグローバル展開、海外製システムの国内展開、相互トレーニングなどを実施する業務。


    運用化・標準化


    新たなサービス開発や、お客様からの要望に対し、突貫的な対応ではなく恒久的な対応が可能になるよう、属人化した手順の運用落し込みや、汎用的な適応が可能となるような標準化を実現していく業務。


    レポーティング


    お客様向け月次レポートの作成や、リアルタイム分析で用いるレポートのカイゼン、それらに関連する問合せ対応、サービス提供状態や応対履歴からセールス担当が戦略的なお客様提案ができるようなデータの取りまとめなどを実施する業務。


    情報発信


    ブログやホワイトペーパーの公開、外部カンファレンスでの講演、セキュリティコミュニティにおける勉強会・トレーニングなどを開催する業務。


    DevOps


    SOC内におけるあらゆる業務について、自動化システムの開発や、アナリストや運用者の支援をするようなツール開発、既存システムのクラウドへの移行などを内製で実現する業務。


    製品リサーチ


    新たなセキュリティ製品やサービスがマーケットに出てきた際に、それらの分析面や運用面での性能や品質の調査を実施する業務。


    新サービス検討


    分析や運用の能力をベースにした新たなインテリジェンスサービスの企画や、新たなセキュリティ領域に対するサービス付加価値の検討などを実施する業務。


    リアルタイム分析


    お客様の環境からログやデータを受け取り、SIEMや解析ツールを駆使しながら24/365で分析し、インシデントの発生をお客様にお伝えする業務。


    解析


    捕捉したマルウェアの解析や、脆弱性を突く攻撃の検証、お客様からの依頼に基づくインシデント関連の調査を実施する業務。


    リサーチ


    お客様にいただくログやデータに限らず、ネット上からマルウェアや悪性インジケーターを探索し収集する業務。


    ハンティング


    解析やリサーチで得られた情報をもとに、新たなSIEMロジックや特定のセキュリティデバイス(IPSやEDR)のカスタムシグネチャ、ブラックリストを作成し、それまで検知できなかった脅威を炙り出す業務。


    業務はどのように割り当てられますか?


    SOCの中には非常に多くの業務があることがご理解いただけたと思いますが、各メンバーにどのように業務が割り当てられるか説明していきます。


    モチベーション駆動型チームビルディング


    基本的なスタンスとして、SOCでは「やりたいことに集中できているときに一番成果が出る」という点を重視したチームの在り方を目指しています。この考えを前提にチームビルディング手法を開発し「Wants」と名付け、各メンバーの強烈なモチベーションをエンジンに組織を動かし続けています


    各メンバーの個性は多様です。マルウェア解析やリサーチが好きな人、お客様と近い存在でありたい人、システム・ツール開発が好きな人、セキュリティ製品マニア、ルーチンワークの鬼、などなど、得意分野や志向分野は十人十色です。それらのモチベーションを活かしてもらうには、やはり「やりたいこと(=want)を選択」してもらうことが一番重要です。


    というわけで、各メンバーには自主的に上述した業務の中からいくつか選択してもらうことにしています。概ね4つ程度の業務を選択する人が多いです。とは言え、もちろん仕事として「やらなければならないもの」もありますので100%やりたいことができるというわけではありませんが、この「Wants」施策により、メンタルヘルス調査の結果やToMo指数が良好であることが実証されています。


    またキャリアプランを考えるうえでも、組織内で取りうる選択肢が多いことはとても良い影響があります。例えば、セキュリティ未経験でリアルタイム監視から参加したメンバーがスキルを広げるためにリアルタイム分析をはじめたり、リサーチからさらに踏み込んだバイナリ解析に興味が移っていったり、デバイスマネジメントからお客様と距離をより縮めたくなってレポート業務にも携わったりと、長期的な志向の変化に合わせ、視野を広げたり、視座を高めたり、深く極めたりと、入社後も自身の可能性を広げていくことが可能となります。


    好き勝手やっていたら属人化しないでしょうか?


    各メンバーが自分の好きなようにやって収拾がつかなくなる、という課題は、正直に申し上げると「あり」ます。しかしながら、延長線上だけでなく、自由な創作活動がなければ大きな成果が得ることは難しいものです。


    尖るための良い属人化は認めクリエイティブな営みを促進しながらも、それを安定させるための開発や運用化をバランスよく実現する必要があります。尖った技術を運用に落とし込み自動化できれば、さらに次の創造のための時間が生み出され、新たな成果に繋げることができるというサイクルが重要です。


    そのサイクルを組織として実現するために、給与・評価制度の中で、個のパワーで技術的に尖っていく部分技術領域:図中、濃色)とチームのパワーで運用品質を高めていく部分運用領域:図中、淡色)を2軸で評価することにしています。個のメンバーにおいて志向がどちらかに傾倒しても、組織全体として技術領域と運用領域のバランスを取れていれば良しとする考え方です。この考え方を実現するためには、メンバーを束ね導くリーダーやマネージャーの存在も不可欠です。


    SOCのリーダーとマネージャー


    2つのリーダータイプ


    弊社SOCでのリーダー的なポジションとしては、各業務のリーダー(カテゴリマスター)と、日々の運用におけるリーダー(スーパーバイザー)の2つがあります。

    前者は今まで挙げた各業務の取りまとめ役で、後者は24時間365日のオペレーション上の取りまとめ役です。カテゴリマスターは各業務領域の特化型リーダースーパーバイザーは各業務領域の横断型リーダーと言える存在です。


    一見役割に重複がありそうなイメージを持たれるかもしれませんが、これは不確定要素への耐性を持つために必要なリーダー体制です。ここで言う不確定要素とは、「大規模なマルウェア感染が起きた」「緊急性の高い脆弱性情報が出た」「サービス障害が起きた」など、自分たちでコントロールできない運用上のトリガーの発生のことだと思ってください。これらがトリガーした場合、その解決にあたっては複数の業務領域にまたがって対応することが多く、ある領域に詳しいカテゴリマスターだけでなく、スーパーバイザーのような業務横断的に現場をリードできる存在も必要となります。


    マネージャーの3つの役割


    では、マネージャーの役割とは?ということになりますが、大きくは3つの役割を持ちます。


    一つ目は、チームの技術面、運用面での成果を最大化すること。個性豊かなチームを率いるため、1on1などを通じて各メンバーの「やりたい」を傾聴し、ときには「やりたい」をうまく引き出しながら、会社の方針とメンバーのモチベーションのベクトルを合わせ、世に対し価値の高い成果を出すことでビジネス的な成功に繋げていく役割です。


    二つ目は、SOC外の組織との調整です。社内にはセキュリティオペレーション部以外の組織ももちろんあり、サービス・インフラ統括、グローバル開発、マーケティング、情シス、総務、OT領域やアプリケーションセキュリティ領域に特化した組織などがあります。これらに加え、NTTグループ関連企業との連携なども含め、SOCの営みとしての受け入れ、SOCの営みをするにあたっての協力依頼など、各組織と協調し連動していくような調整・交渉を成功させる役割です。


    三つ目は、メンバーがハッピーに働ける環境を整備することです。適正なルールや基準による、透明性が高く公正なメンバー評価、各業務に必要となるシステムリソースの確保、トレーニング・研修の受講促進など、大きくは働き方の見直し(シフトの自由化、リモート環境の整備など)も含め、メンバーが気持ちよく成長しながら働ける環境を整備していく役割です。


    これらを各マネージャーが個々にやるのはなく、マネジャーでチームを組み(現在5名)SOC全体として実現していく形です。これら3つの観点はマネジャー陣にとっての「Wants」でもあります


    おわりに


    以上、弊社のSOCの「中」についてまとめました。これらはあくまで「今」の状況であり、これまでもそうであったように、クリエイティブなSOCであり続けられるよう、形を変えながら進化していきます。その進化を支えるのは、各メンバーが切磋琢磨しつつも、お互いの得意領域を活かし支え合いながら業務し、風通し良く、リスペクトし合う中でさらにスキルを身に着けていくという、一人一人のメンバーの成長です。


    他にもこちらの記事で活動内容をまとめています。興味ある営みがあればブログホワイトペーパーも合わせてご覧ください。


    取材いただいた下記の記事も合わせて読んでいただけるとより雰囲気が伝わるかもしれません。


    「つまらないSOC業務」からの脱却、NTTセキュリティ“5つのSOC改革”を聞く