SITA、新たな航空会社のデータ漏洩に責任を負う / SITA Responsible For New Airline Data Breach（転載）～JALの顧客データも流出～

世界の複数の航空会社の旅客データが、世界的な情報技術企業であるSITAのサーバーがハッカーによって侵害されたことが明らかになりました。

JAL、ANAを含む十数社近くの航空会社が、航空券の予約から搭乗までのトランザクションを処理するSITAのPassenger Service System（PSS）に侵入者が侵入し、一部のデータがアクセスされたことを乗客に伝えている。

影響を受けた旅行者の総数は明らかになっていませんが、210万人以上となっており、そのほとんどがヨーロッパ最大規模のルフトハンザグループのマイレージプログラム「Miles & More」およびアワードプログラムの参加者となっています。

スターアライアンス、ワンワールド・アライアンスの航空会社が影響を受ける

SITAは木曜日の短い声明でサイバー攻撃を確認し、影響を受けたPSSの顧客および関連するすべての組織に連絡したと述べました。

SITAの担当者がBleepingComputerに語ったところによると、侵入は以下の航空会社の乗客のデータに影響を与えているという。各社とも、すでに顧客に通知したり、侵入についての公開声明を発表している。

  • ルフトハンザ - 子会社を合わせると、搭乗者数でヨーロッパ第2位の航空会社であり、スターアライアンス加盟航空会社であり、Miles & Moreのパートナーでもあります。
  • ニュージーランド航空 - ニュージーランドのフラッグキャリア航空会社
  • シンガポール航空 - シンガポールのフラッグキャリア航空会社
  • SAS - スカンジナビア航空（ここで開示）。
  • キャセイパシフィック航空 - 香港のフラッグキャリア
  • 韓国初・最大の格安航空会社、済州航空
  • マレーシア航空 - マレーシアのフラッグキャリア航空会社
  • フィンエアー - フィンランドのフラッグキャリア、最大の航空会社
日本航空も影響を受けているという報道もある。最初の4社は、26社が加盟する世界的な航空会社ネットワーク「スターアライアンス」に属しており、ルフトハンザは5つの創業メンバーの1つです。

より多くのキャリアが影響を受けている可能性があるが、SITAは、侵害に関する声明を公表する前に、その名前を公表することを辞退した。

SITAは「2021年2月24日にデータセキュリティインシデントの重大性を確認した」としているが、影響を受けた個人の数や攻撃がいつ発生したのかは明らかにしていない。

ルフトハンザの担当者はBleepingComputerの声明の中で、ハッカーが1月21日から2月11日の間に、スターアライアンスに加盟しているアジアの航空会社の予約システムに侵入したと述べている。

スターアライアンスは2月27日にSITAからPSS侵害に関する通知を受けた。スターアライアンスは、すべての加盟航空会社が影響を受けているわけではないとの通知を受けたとしているが、その可能性を排除していないとしている。

シンガポール航空は木曜日に今回の侵害を公表し、同社のマイレージプログラム「KrisFlyer」の会員約58万人のデータが流出したことを説明。また、同社は顧客に対して、SITAのPSSは利用していないが、別のスターアライアンス加盟航空会社は利用しており、SITAは全スターアライアンス加盟航空会社で共有されているフリークエントフライヤーデータの制限されたセットにアクセスしていることを意味すると電子メールで伝えている。

Miles & Moreマイレージプログラムでは、26社のスターアライアンス会員を含む37社の提携航空会社をご紹介しています。その他の提携航空会社は以下の通りです。

  • 高級ホテルと手頃な価格のホテル(Althoff, Hyatt, Marriott International, Jumeirah, Kempinski, Meliá, BestWestern, H-Hotels, HRS, Hyatt, IHG)
  • レンタカー会社(Sixt, Hertz, AVIS, Europcar, Enterprise, Budget)
  • ポイント交換ショップ(Dezerved, Heathrow Rewards, Heinemann, Lufthansa WorldShop, Bicester Village Shopping Collection, welcome Shop)
  • 金融会社(UniCredit, Visa)
  • 旅行代理店(Get Your Guide, Kreuzfahrten)
ルフトハンザによると、ハッカーはスターアライアンスにも加盟している未公表のアジア航空会社の予約システムに侵入したため、Miles & Moreの顧客データも今回の事件の影響を受けています。

盗まれた情報は、サービスカード番号、ステータスレベル、場合によっては参加者の名前などです。より機密性の高い詳細情報（パスワードや電子メールアドレス）は影響を受けていません。

スターアライアンスは、会員が旅行特典の付与に関連する顧客情報を共有していることをBleepingComputerに確認したところ、会員名、マイレージプログラムの会員番号、プログラムのティアステータスに限定されているとのことです。

なお、今回の違反の影響を受けた航空会社のうち、直接または間接的に影響を受けた航空会社は、ワンワールド航空アライアンス（マレーシア航空、キャセイパシフィック航空、フィンエアー）の加盟航空会社です。

フィンエアーは、顧客への電子メールで、SITA PSSの侵害の一環として、一部のフリークエントフライヤーデータにアクセスされたことを明らかにしています。シンガポール航空の場合と同様、同社はPSSを利用しておらず、フィンエアーが一部のフリークエントフライヤーデータを提携航空会社と共有しているために今回の事件が発生したという。

Yleによると、フィンエアープラスプログラムの約20万人の会員が影響を受けているとのことです。ただし、盗まれたデータは、そのプログラムのアカウントにアクセスするために使用することはできません。また、航空会社は「このデータが他の文脈で悪用されるリスクは比較的低い」と評価しています。

Labels: ,

Googleが10億の悪質なメール詐欺から学んだこと / What Google learned from 1 billion evil email scams（転載）～攻撃全体の5%は日本が標的～


What Google learned from 1 billion evil email scams:

Googleとスタンフォード大学の研究者が、世界的に送信されたフィッシング/マルウェアのメールを5ヶ月間分析した詳細な調査結果を発表しました。"メールベースのフィッシングやマルウェアに狙われているのは誰か？リスクを差別化する要因を測定する」と題して、10億通以上のメールを調べた。その結果は、インターネット測定会議でのプレゼンテーションに反映された。

Gmailによって自動的にブロックされたフィッシングやマルウェアキャンペーンについて調べたところ、フィッシングの世界での現在の傾向や出来事について、かなりのことを発見したそうです。

不正メール分析：主な調査結果

  • 攻撃の42％が米国内のユーザーを標的に
  • 英国の10％のターゲットユーザー
  • 日本に拠点を置くユーザーを対象とした攻撃は5%に上る

攻撃は主に北米と欧州を中心に行われ、米国はフィッシングやマルウェアメールの受信量が最も多い。しかし、最もリスクが高い国はアフリカとヨーロッパです。調査によると、16カ国が米国よりも平均的に高いリスクを示しています。

英語：詐欺の国際言語

ローカライゼーションは特に人気があるわけではなく、ほとんどの攻撃者は英語のメールテンプレートを複数の国に展開しています。フィッシングメールの83％、マルウェアメールの97％は英語で書かれている。しかし、日本国内のフィッシングメールの78％は日本語で書かれており、一部のローカライズが行われていることにも注目している。

1つのテンプレートは100～1,000人のターゲットに送信され、キャンペーンは平均して1～3日で終了します。小規模なキャンペーンでは、1週間で1億通以上のGmailユーザーを対象としたフィッシングメールやマルウェアメールが送られてきます。

年齢層、データ漏洩、デバイスの減少

ターゲットにされるリスクは、各年齢層が上に行くほど少しずつ増えていきます。もしあなたが55-64歳であれば、18-24歳や35-44歳の年齢層よりも魅力的な提案をされる可能性があります。これは、理論的には高齢者ほど詐欺に遭いやすいということなのか、それとも単にオンラインでの足跡を見つけやすいということなのか、どちらにしても決められていません。

過去のデータ侵害はリスクを高めます。データ漏洩で個人情報が公開された場合、攻撃される確率ははるかに高くなります。覆水盆に返らずですし、詐欺師が積極的にメールを列挙したり、人口統計学的情報を掘り下げたりするのは理にかなっています。

携帯電話に固執することで攻撃のリスクが最も低くなりますが、複数のデバイスを使用することで最も高いリスクが発生します。1台のパソコンを使用すると、その中間に位置することになります。

Labels: ,

Webシェル攻撃とはどんなものか（転載）

Webシェル攻撃とはどんなものか　Microsoft 365 Defenderが月間14万件も検出する脅威

　Microsoftは2021年2月11日（現地時間）、サイバー攻撃でWebシェルが使われるケースが増えていると公式ブログで報告した。『Microsoft 365 Defender』のデータによると、2020年8月から2021年1月末までの期間においてWebシェルが使われた脅威の件数は月平均14万件に到達しており、前年の7万7000件のほぼ2倍に達しているという。

　ユーザーが何らかの方法で任意のコマンドをサーバ実行するためにWebサーバにインストールして使うソフトウェアやその仕組みを「Webシェル」と呼ぶ。

　Webシェルは特定のソフトウェアを指すのではなく、PHPやASPのようなプログラミング言語の実行環境を指す。そうしたプログラミング言語にはシステムの任意のコマンドを実行するために幾つかの手段が用意されている。

　攻撃者はさまざまな方法でこの機能を使い、遠隔からサーバ上で任意のコマンドを実行できるようにして攻撃する。Webシェルがサイバー攻撃に使われていることは以前からよく知られており、増加傾向が続いていることも報告されていた。今回のMicrosoftの報告はこの傾向が継続しているのみならず、これまでよりも速いペースで増加していることを示した。

　Webシェルのインストールは通常、Webアプリケーションの脆弱性を利用する形で実行される。インターネットには脆弱性を修正するパッチが適用されないまま運用されているサーバが多数存在する。攻撃者はこうしたサーバをスキャンによって発見し、Webシェルのインストール先として利用する。

　Webシェルは比較的簡単に設置でき、効果的に利用できることから、サイバー攻撃において利用が活発化している可能性が指摘されている。攻撃のエントリーポイントとして使用できる他、攻撃を永続化する仕組みとしても使用できる。Webシェルは構成によっては検出が難しく、実際に実行されなければ危険性を検出できないものも多い。今後もWebシェルを使用したサイバー攻撃は増加することが予測されるため注意が必要だ。

Labels: ,

オープンソースの航空機データベース / Launching an Open Source Aircraft Database for Venezuela（転載）

Launching an Open Source Aircraft Database for Venezuela


近年、航空機の追跡は、オープンソースの研究者のツールボックスの中でも重要な役割を果たしています。航空機追跡サイトでは、警察の活動からCOVID-19ワクチンの配送まで、あらゆることを誰でも監視することができます。このガイドで書いたように、航空機が上空でどのような動きをしているかを知ることができれば、進行中のイベントをフォローしたり、ニュースを先取りしたりするのに役立ちます。

多くの民間航空局は、航空機の登録情報をオンラインで公開しています。米連邦航空局（FAA）のFAAレジストリ、カナダ運輸省のCanadian Civil Aircraft Register、英国のG-Infoレジストリなどがこれにあたります。航空機の登録番号を知っていれば、各国の登録ページで調べて、航空機のモデル、シリアル番号、登録者などの情報を得ることができます。

しかし、すべての民間航空局がこのように航空機の登録情報を公開しているわけではありません。ベネズエラの場合、民間航空局（Instituto Nacional de Aeronautica Civil：INAC）はこのような情報をオンラインで提供していません。そのため、ベネズエラの航空機登録情報を知りたい研究者は、他の情報源を探す必要がある。

2020年1月、ベネズエラで登録された航空機のオープンデータベースを開始しました。オープンソースのフライトトラッキングデータと、航空機追跡愛好家からの有益なアドバイスを利用して、このデータベースには約240機の航空機の詳細が含まれています。これらの航空機の大部分はベネズエラで登録されているが、中にはベネズエラと何らかの関係がある外国籍のものもある（詳細は後述）。

このデータベースは、登録番号やシリアルナンバーなどの航空機の識別情報を一元的に管理するためのものです。 このデータベースには、航空機のスポッターが撮影した写真や飛行履歴などの追加情報も含まれている。航空会社に登録されている民間航空機のように、航空機の所有権が明らかなものもありますが、他の航空機の所有者や運航者を特定することははるかに困難です。そのため、航空機がいつどこに移動したのかを知ることは、ベネズエラの富裕層や権力者の動きと関連があるかもしれないからだ。

データベースの概要

データベースに登録されている情報の大部分は、4つのフライトトラッキングプラットフォーム（addsbexchange.com、opensky-network.org、flightradar24.com、radarbox24.com）という複数のソースから得られたものです。データのほとんどは、過去1年間にこれらのサイトをライブモニターして収集したものです。また、航空機愛好家の方々からは、航空機に関するデータを提供していただいたほか、データベースをより便利にするためのフォーマットに関するヒントもいただきました。

データベースのカラムは、4つの「識別子」カラム、1つの「注記」カラム、そして（現時点では）10の「追加情報」カラムに分類されています。

以下では、各カラムの目的を説明するガイドと、このデータベースがどのように利用されているかを示す初期の例を紹介します。

列の入力には、Google SheetsのCONCATENATE機能を使用しています。これにより、文字列の結合やURLの自動入力が可能になります。フライトトラッキングサイトでは通常、検索を行うために飛行機の登録番号か24ビットのICAOアドレスのいずれかを入力する必要がある。

しかし、各サイトが検索後にどのようにURLを入力するかを見ることで、CONCATENATE機能を使って、他の関連する飛行機登録や24ビットICAOアドレスのために必要なURL検索の全文を予測し、自動的に入力することができます。

例えば、下の画像は、opensky-network.orgに登録されているYV2966という航空機の検索結果を示しています。このURLは「0D81C9」で終わっていますが、これはこの飛行機の24ビットICAOアドレスです。


opensky-network.org検索のURL構造が航空機の24ビットのICAOアドレスで終わることを知っているので、CONCATENATE関数を使ってこのデータを列に入力し、サイトへのリンクを自動的に生成することができます。下の画像では、「$D73」は、24ビットのICAOアドレスを含むD列と、YV2966のそのアドレスを含む73行を指しています。


それを踏まえた上で、コラムの内容をご紹介します。

このデータベースがスペイン語で書かれているのは、ベネズエラの研究者や市民ジャーナリストが、自国の空を記録することに興味を持つことを想定しているからです。

識別子

A列からD列には、航空機の登録番号、モデル番号、製造者シリアル番号、および固有のICAO 24ビットアドレス（「ヘックスコード」とも呼ばれる）が記載されています。これらの情報により、航空機を歴史的にもリアルタイムにも追跡することができます。多くの場合、データベース内の情報は、2つまたは3つの異なるオープンソースを使用して編集されています。

これらの欄の情報は、航空機がベネズエラの空域で観測された後に、上記のフライトトラッキングウェブサイトの1つに手動で入力されています。

メモ

E欄の「メモ」には、航空機に関する興味深い情報や潜在的な関連情報が記載されています。このノートには、その航空機が過去に行った旅行や、その航空機について言及したニュース記事やプレスリリースなどが含まれます。

例えば、このデータベースに登録されている十数機の航空機が、米国財務省が公表した制裁リストに登場しています。例えば、2020年1月21日に他の14機とともに制裁を受けたボンバルディア・リアジェット45のYV2738は、国営石油会社であるペトロロス・デ・ベネズエラ（PDVSA）の所有物であることが理由である。今回の制裁は、ベネズエラのニコラス・マドゥロ大統領の政権に「圧力」をかけるためにトランプ政権が行った広範な行動の一環である。

メモ欄には、カラカス中心部にあるGeneralissimo Francisco de Miranda空軍基地（俗称：La Carlota）からの着陸または離陸も観測されています。この空軍基地は軍事施設であり、少なくとも2014年以降は民間機の飛行が公式に禁止されているため、ここに着陸する民間機は注目に値する。一般の航空会社や民間航空機は、カラカスの南と北にそれぞれあるオスカー・マチャド国際空港とシモン・ボリバル国際空港を利用するのが一般的だ。それでも、セスナS550サイテーションSIのYV3310は、11月23日の朝、シウダー・グアヤナに向かうためにラ・カルロータを離陸しました。

ベネズエラのニュース「El Diario」によると、Conviasa（国営フラッグキャリア）は、滑走路が商業用に閉鎖されているにもかかわらず、La CarlotaからLos Roques島群島へのフライトを運航し、ベネズエラの富裕層や権力者にサービスを提供しているとのことです。データベースのフライトトラッキングツールを使えば、他にどのような航空機がこの基地を利用しているかを確認することができます。


追加情報

F列からO列には、各航空機の追加情報が記載されています。これらの情報は、飛行履歴、登録データ、インシデントデータ、写真、およびTwitterから取得したデータに分類されています。

各項目の説明は以下の通りです。

Flight history: F-I列には、adsbexchange.com、flightradar24.com、radarbox24.com、およびflightawareからのフライト履歴データが含まれています。フライト履歴は、サイトによっては様々な費用をかけて有料で提供されているため、各サイトによって大きく異なる場合があります。

Registration Data: J列はplanelogger.comからの登録履歴です。そのような情報が利用可能な場合、この欄には、航空機が持っていた以前の登録/所有者のリストが表示されます。Planeloggerによると、YV3016になってConviasaに所属する前は、FAB2592としてブラジル空軍に所属していました。 


Incident History: K列は、航空事故に関するデータをまとめたウェブサイト「Aviation Safety Network」から、航空機の事故履歴を示しています。例えば、YV1118のエントリーでは、2017年9月19日にサンタ・エレナ・デ・ウアイレン空港の着陸帯をオーバーランしたことが示されています。 

Planespotter Pictures: L列とM列には、人気の高い航空画像サイトであるplanespotters.netとjetphotos.comでplanespottersが撮影し、共有している航空機の画像へのリンクがあります。

これらの画像は、航空機に関する視覚的なデータを提供するだけでなく、航空機の飛行履歴に関する情報が含まれていることもあり、有用です。例えば、jetphotos.comのYV2152のエントリーには、2017年11月24日にグアテマラシティのラ・アウロラ国際空港で撮影された同機の画像が含まれており、その日に同機がその場所に存在していたことを視覚的に確認することができます。

Twitter Information: N列とO列には、航空機の登録番号や24ビットのICAOアドレスに言及したツイートの検索結果が含まれています。この2つの識別子は、趣味や研究者、ジャーナリストが航空機についてツイートする際に使用される可能性が高いものです。

これらのTwitter検索の情報は、航空機の所有者や過去の履歴に関する重要な情報を、その航空機についてのツイートやスレッドの形で提供することができます。

Other Details: P列には、ホビー用フライトトラッキングサイトであるopensky-network.comのデータが含まれています。この情報には、航空機のシリアル番号、年代、ヘックスコード、登録所有者などが含まれます。

Q列とR列は、航空機を空軍、民間、航空会社、国際に分類し、Conviasaに登録されているかどうかを示しています。

Labels: , ,

ゼロ・トラストはどこから始まり、なぜ重要なのか？ / 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から引用したものです。

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

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

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

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

みずほ、甘い想定重ね被害拡大　ＡＴＭ障害、顧客目線の業務体制課題（転載）～みずほ10年ごとに大規模障害を起こす？～


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

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

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月末。
Labels: ,

トラフィック分析演習(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.

    Labels: ,

    悲報！タイ国際航空、エアバス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の引退をどう思いますか？

    Labels: ,

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



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

    全文表示 / Read more »

    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 によるクラウドセキュリティ市場のさらなる拡大が期待されます。
    Labels: ,

    BECについて調査の観点がまとめられています。 Business Email Compromise Guide (BEC)　 A guide for forensic investigators（転載）

    BECについて調査の観点がまとめられています。 Business Email Compromise Guide (BEC)　 A guide for forensic investigators github.com/PwC-IR/Busines…: BECについて調査の観点がまとめられています。

    Business Email Compromise Guide (BEC)　
    A guide for forensic investigators
    github.com/PwC-IR/Busines…

    Labels: ,

    最先端の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改革”を聞く


    Labels: ,
    登録: 投稿 (Atom)