U.S. GAO 国防省の15のシステム開発を監査してみて(転載)~米国の国防予算に占めるIT予算化比率は5.1%~



U.S. GAO 国防省の15のシステム開発を監査してみて・・・開発手法やセキュリティについてコメント付けてます:

U.S. GAO 国防省の15のシステム開発を監査した結果を公表しています。。。参考になりますね。。。報告書は63ページあります・・・ 

It requested about $36.1 billion for IT for fiscal year 2020. 

とありますから、国防省はIT予算として361億ドル、約4兆円の予算を要求しているんですね。。。日本の防衛予算は約5兆円ちょっと(2020.12.21 我が国の防衛と予算(案)-令和3年度予算の概要- )ですから、すごい金額ですね。。。まぁ、国防省の予算が7,000億ドル弱(77兆円)のようですから。。。(ちなみに、人件費・福利厚生費が40%弱を占めるみたいです)

Cost estimates decreased for 11 programs (ranging from .03% to 33.8%) and 10 programs experienced schedule delays (ranging from 1 month to 5 years).

とありますから、15のプログラムのうち11で開発コストが下がっているんですね。でも10のプログラムで遅延が発生していると・・・

10 of the 15 programs reported using commercial off-the-shelf software, which is consistent with DOD guidance to use this software to the extent practicable. Such software can help reduce software development time, allow for faster delivery, and lower life-cycle costs.

とあるので、10/15が市販ソフトを活用しているようですね。。。これはDODの方針にあっていると・・・

In addition, 14 of the 15 programs reported using an iterative software development approach which, according to leading practices, may help reduce cost growth and deliver better results to the customer. However, programs also reported using an older approach to software development, known as waterfall, which could introduce risk for program cost growth because of its linear and sequential phases of development that may be implemented over a longer period of time. Specifically, two programs reported using a waterfall approach in conjunction with an iterative approach, while one was solely using a waterfall approach.

ということは、ウォータフォールの開発手法だけではダメで、うまくアジャイルと組み合わせなさいという感じですかね。。。

In contrast, only eight of the 15 programs reported conducting cybersecurity vulnerability assessments—systematic examinations of an information system or product intended to, among other things, determine the adequacy of security measures and identify security deficiencies. These eight programs experienced fewer increases in planned program costs and fewer schedule delays relative to the programs that did not report using cybersecurity vulnerability assessments.

脆弱性のテストをしているプロジェクトが8/15あって、脆弱性テストをしているプロジェクトの方が、開発遅延やコスト増が少ない感じみたいですね。。。

GAOのこの強力な監査能力が結果的に政府の力を強めているのかもしれないと思うようになってきました。。。

2021年のサイバー脅威、「Nデイ脆弱性」とは!?(転載)


2021年のサイバー脅威、「テレワークの一般化」と「既知の脆弱性」がカギに:

トレンドマイクロは12月22日、脅威動向を予測したレポート「2021年セキュリティ脅威予測」を公開しました。あわせて公式ブログ記事も公開しています。

2020年は、新型コロナウイルス感染症(COVID-19)の拡大により、業務形態、流通網、生活様式など、世界中で幅広い変化が発生しました。サイバーセキュリティにおける脅威も、そうした変化で発生した隙をつくように、さらに巧妙さと危険度が増しています。

こうした背景から「2021年セキュリティ脅威予測」では、まず「自宅のテレワーク環境がサイバー攻撃の弱点になる」「テレワーク用企業向けソフトウェアやクラウドアプリケーションの深刻な脆弱性が狙われる」といった可能性を指摘しており、脆弱なホームネットワークから従業員の自宅のコンピュータを乗っ取って組織ネットワークへ侵入する事例などが予想されています。他方で、既にインターネット上では、脆弱性の影響を受ける特定のVPN機器のリストも公開されており、該当する組織での早急な対応が求められています。

また「新型コロナウイルスに便乗する攻撃キャンペーンの継続」「医療機関が直面するセキュリティリスク」も予測されています。2020年に日本国内では、マスク不足に便乗した偽の通販サイトや偽の給付金の申請サイトなどが確認されました。今後も、感染状況やワクチン関連の情報に偽装した不正サイトや不正メールが横行すると考えられます。一方で、医療機関やワクチン開発関連組織への諜報活動が懸念されます。

そして、サイバー攻撃に悪用される脆弱性(セキュリティ上の欠陥)において、ベンダからの修正プログラム(パッチ)提供などの対応策がない「ゼロデイ脆弱性」だけでなく、修正プログラムが提供されているものの、公開されたばかりでパッチが適用されていない可能性がある既知の脆弱性「Nデイ脆弱性」がより一層問題になると予測されています。

「2021年セキュリティ脅威予測」では、その他にも以下のようなトピックを解説しています。

・攻撃者はホームオフィスを新たな犯罪拠点に

・テレワークの導入によって企業はハイブリッド環境と持続困難なセキュリティアーキテクチャに直面

・外部からアクセス可能なAPIが企業の情報漏えいの攻撃経路に

・パンデミックで進む個人情報の収集と共有に注目するサイバー犯罪者

・セキュリティ強化の推進

「2021年セキュリティ脅威予測」(PDFファイル)は、トレンドマイクロの公式サイトから無償でダウンロード可能です。

バックアップ(非公開)

「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判(転載)~貴重な”しんがり”ネタ~


「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判【やじうまWatch】:


2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。

取り組んだこと

 
決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご提供するという性質上、突然のサービス終了は関係する方々のビジネスに直接的・間接的に大きく影響する可能性もあり、慎重にすすめる必要があります。

今回システム停止を計画するにあたり、下記の要件が存在しました。

  • お客さま・加盟店様・その他パートナー様への影響を出来る限り小さくするために、十分な事前告知と準備期間を経てサービス終了を行うこと。
  • 障害・不正利用等のシステムリスクを出来るだけ小さくすること。
  • サービス終了までのシステム維持コストを出来るだけ小さくすること。
当初から少なくとも半年以上はかかるプロジェクトとなることが見込まれていたため、複数フェーズに分けて段階的に機能を停止していく基本方針を置きました。 対外アナウンスや機能停止は一度行ってしまうと後戻りできないため、下記のように事前計画を入念に行いました。以下ではそれぞれの項目について紹介していきます(便宜上ステップのように順番に記載していますが、実際は途中段階で新しい事実が発覚して前段階に巻き戻ったりといったことを繰り返しながら計画を作っていきました)。

  1. 外部へ影響を与える機能・業務の特定
  2. 法務・コンプライアンス要件の特定
  3. サービス終了計画の作成
  4. システム停止計画の作成
  5. 計画に沿ったシステム停止と影響確認

1. 外部へ影響を与える機能・業務の特定 

サービスを段階的に停止していくにあたり、外部への影響度・内包されるシステムリスク・維持コストなどの観点から機能や業務を分解していきます。

今回Origami Payサービス終了を計画するにあたり洗い出した機能・業務の一例は以下のようなものです。

  • バーコード提示型のインタフェースによるお支払い
  • QRコード読み込み型のインタフェースによるお支払い
  • クレジットカードを利用したお支払い
  • 金融機関口座連携を利用したお支払い
  • ウォレット機能を利用したお支払い
  • 加盟店様による返金・金額変更
  • 加盟店様によるお支払い履歴確認
  • 加盟店様への売上金振込
  • 一般のお客さまからのお問い合わせ対応
  • 加盟店様からのお問い合わせ対応
機能・業務をどこまで細かく分解するかは、「停止タイミングが異なるか」を軸として行いました。例えばOrigami Payではクレジットカードを使ったお支払い方法と、金融機関口座を紐付けたお支払い方法が提供されていましたが、両者では不正利用リスクが異なるために「加盟店でのお支払い」と一括りにするのではなく個別に停止スケジュールを検討することとしました。

2. 法務・コンプライアンス要件の特定

サービスの特性によっては法務・コンプライアンス観点からサービス終了の進め方に要件が存在する可能性があります。

Origami社では資金移動業・第三者型前払式支払手段発行者・電子決済等代行業・クレジットカード番号等取扱契約締結事業者といった各種業法への登録や、PCI-DSSへの準拠を行っていました。 各事業廃止にあたり、リスク管理体制の維持や消費者保護の観点等から法務・コンプライアンスチームと連携して1で特定した機能・業務に抜け漏れがないか、またそれぞれを停止するにあたり注意を要する点がないか密に連携しながら要件を洗い出しました。 例えば資金移動業を廃業するにあたってはお預かりしている残高をお客さまに確実にお返しするために、メール連絡・ウェブサイト告知や官報掲載などのコミュニケーション計画が求められます。

3. サービス終了計画の作成

1で特定した機能・業務それぞれについて停止日・事前告知日等を定めていきます。

法務・コンプライアンス要件を満たすことは当然ですが、外部ステークホルダーの皆様との調整観点で営業・事業開発チームと、社内業務との調整観点でオペレーションチームやコーポレートチームと協力しながら計画していった結果、下図のような9ヶ月にわたるスケジュールが出来上がりました。


細かく全スケジュールに触れていくことは難しいので、システム停止に影響が大きいマイルストーンだけ下記にまとめます。

2020/2 ウォレット機能によるお客さま間送金の停止
2020/3 ウォレット機能によるお支払い停止
2020/4 クレジットカードによるお支払い停止・バーコード提示型のお支払い停止
2020/6 一般のお客さま向けサービスの停止・お客さま向けアプリの配信停止
2020/9 加盟店様向けサービスの停止・加盟店様向けアプリの配信停止

支払い手段ごとに細かく停止時期が異なっていますが、前記のようにシステムリスクや不正利用リスクを早期に小さくしていくことと、外部影響を鑑みて早期に機能を閉じられるかといった現実性をあわせて検討した結果、このように支払手段ごとに段階的な停止を行うこととしました。また、一般のお客さまによる利用が終わった後も返品等による返金・金額変更等が発生する可能性を考慮し、新規のお支払い停止から90日間のバッファ期間を経て加盟店様向けサービスの停止を行うこととしました。

機能の停止とその告知以外にも考慮すべきことはこのタイミングで洗い出します、一例として、広くサービス終了告知を行う際にはそれに便乗したフィッシング詐欺等が発生するリスクもあり、その対策として不正ログイン・不正取引の自動検知・監視体制強化も計画していきました。

4. システム停止計画の作成


サービス停止計画から各フェーズで停止できるサブシステムを特定し、システム停止作業のスケジュール・内容を計画します。

Origami PayはAWS上に構築されたバックエンドシステムとiOS, Android向けに提供されているお客さま向け・加盟店様向けモバイルアプリで構成されていました。バックエンドシステムはウェブアプリケーションの改修でリアルタイムに機能停止を行えますが、モバイルアプリは新しいバージョンをアプリストアに登録しても大多数のお客さまが最新バージョンにアップデートいただくまでにタイムラグがあります。今回はバックエンド側のフラグに合わせて各停止フェーズ向けの画面・挙動に切り替えられる仕掛けを内包したバージョンを事前にアプリストア上で配布し始めておくことで、実際の機能停止タイミングで表示をスムーズに変更する下準備を行いました。

AWS上に存在する内製システムを停止していくことに加えて、システムと接続されている外部サービスや、業務で利用しているクラウドサービスについて利用停止・契約解除タイミングも計画します。 各フェーズで停止する機能から不要となる関連サービスを特定していくのですが、それに加えて最終的にはすべての外部サービス利用が漏れなく終了している必要があります。年次の外部サービス棚卸しが終わった直後だったこともあり、外部サービス台帳を出発点として、各サービスの停止計画を作りました(参考までに下図がOrigamiで作成していた台帳のサンプルになります)。


内部システムと外部サービスの停止計画が決まったら、それをもとにサービス終了までのシステムコストの大まかな見積もりを行います。 AWS環境については構成変更によるコスト推移を完全に予想することが難しいのですが、Billing and Cost Managementを使うことで過去の請求実績の細かい内訳(サービス別・サイズ別・リージョン別など)が分析できるため、そこから各フェーズにおけるシステム停止後のコストを見積もりました。

5. 計画に沿ったシステム停止と影響確認


4のスケジュールにそって機能停止を行います。完全なサービス停止以前では一部機能のみを停止することになるため、予期せぬ影響がでた場合に備えて作業手順を細分化し、切り戻し手順を用意して実施します。数人でダブルチェックを行いながら作業をすすめる必要がありましたが、結果的に関係者が自発的に多く集まったこともあり盤石な体制で多くの作業を進められました。

停止作業・インフラ整理を行った後は数日間AWSコストの監視を行います。システム停止計画で事前に想定していた水準まで日次コストが下がっているかを確認し、想定したコスト減が達成されていない場合は要因を調査・解消します。 Cost Explorerを用いると日次コストのサービス内訳が確認できるので原因分析をしやすくなります。ECS・EC2・RDSなどのComputing / Database系コストは予測しやすいですが、Networking / Governance系等はコスト予想が難しく、目標コストを達成するためにフェーズごとの追加調整なども行いました。

下図が実際にサービスを運用していたAWSアカウントのコスト推移です。全機能の提供を終了したのは9月、そのインフラ整理を行ったのが10月なので11月にコストが大きく下がっていますが、その途中経過でもほぼ事前計画どおりの水準までコストを削減できました。事前にコスト計画を定めて進めたことで金銭的なコストを抑えられたことも勿論ですが、管理すべきリソースが減り、結果的にシステムリスク低減・人的な運用負荷の軽減にもつながりました。


6. (おまけ) Twitterをエゴサしてエモい気持ちになる

まったく余談ですが、事前告知でお支払い機能が停止される日時までお伝えしていたこともあり、停止前後はTwitter検索すると感想や思い出を投稿してくださった方もいらっしゃいました。中には、サービスが止まる直前を狙って記念決済をしてくださっているツイートなどもあり気持ちが温まるタイムラインを眺めながらシステム停止を行っていたりしました。

さいごに


これだけ慎重に時間をかけてサービスを終了していくという経験は初めてだった為、計画段階も実施段階も途中過程でいろいろな学びがありました。しかしそれでも運営してきたサービスを終了するというのは決して楽しい話ではなく、最後まで一緒にがんばってくれた関係者の方々には感謝してもしきれません。 サービス終了なんて頻繁に立ち会うことではないかもしれませんが、本投稿が将来そんなタイミングを担当される方の参考になれば幸いです。

私自身も含め、今回サービス終了を一緒に進めてくれたメンバーも参画してメルペイでは日々サービス開発を進めています。ミッション・バリューに共感できるエンジニアリングマネージャー・エンジニアを募集していますので、一緒に働ける仲間をお待ちしております。

【参考】

ZOZO、全社にパスワード管理ツール「1Password」導入(転載)~1Passwordの企業への導入事例は珍しいかも~


パスワード管理ツール1Passwordの全社導入から運用まで - ZOZO Technologies TECH BLOG:


 パスワード管理ツールの必要性


パスワード管理の基本は、強固なパスワードを作成し使いまわしせず、なるべく漏洩しないようにすることが挙げられると思います。ありがちなものとしては、以下のような方法があります。

  • 付箋や紙に書いて管理
  • PCのメモ帳で管理
  • Excelで管理
  • ブラウザに保存

ですがセキュリティや管理・運用のしやすさを考えると、上記の方法よりも専門ツールであるパスワード管理ツールを利用する方が優れています。

「パスワードなんてブラウザに保存できるからそれで事足りる」と思う方もいらっしゃると思います。しかし会社としてパスワード管理の基盤がないと、チームごとに管理方法が違ったりパスワードの共有に平文が用いられてしまったり様々なリスクが生じます。

パスワード管理ツールは、便利なだけではなくそういった問題を解決できるので、利用者側、管理者側ともに非常に有益なものと言えます。


パスワード管理ツールの選定


パスワード管理ツールは色々あります。

  • 1Password
  • LastPass
  • パスワードマネージャー
  • Keeper
  • True Key
  • Dashlane
  • Bitwarden

ざっと調査しただけで、上記が挙げられます。

上記の全てを比較したわけではありませんが、どれも基本的な機能としては大差ありません。例えば下記のような機能があります。

  • 複雑なパスワードの自動生成
  • ID・パスワードの自動入力
  • パスワードの強度や使い回しのチェック
  • 多要素認証
  • ID・パスワードの共有

強度の高いパスワードを生成でき、利用者は自身のマスタパスワードだけを覚えれば他のパスワードを覚える必要がなく、保存された情報は暗号化され安全に共有できます。もちろんパスワード以外のセンシティブな情報も保存できます。パスワード管理ツールはそのような機能を備えたツールです。


1Passwordの優位性


弊社では主に以下の点で、1Passwordを採用するに至りました。


Secret Keyの仕組みがある


1Passwordにはマスタパスワードに加えてSecret Keyがあり、たとえマスタパスワードが漏洩したとしても、Secret Keyを知らなければアクセスできません。マスタパスワードはデバイス上のデータを保護し、Secret Keyはデバイスからデータを保護してくれるとのことで、この二段構えの構成は安心できます。


グループ単位で管理できる


ビジネスプラン以上ではユーザグループを作成できます。グループにユーザを追加し、グループを保管庫(Vault)に紐付けることで権限付与が可能です。


CLI(コマンドライン)ツールがある


1Passwordにはコマンドラインツールがあります。コマンドラインツールに対応していることは、運用の自動化を考慮する上で重要な要素と捉えています。

例えば以下のようなことができます。

# ユーザ招待
op create user <メールアドレス> <氏名>
# ユーザの停止と再開
op (suspend | reactivate) <user>
# ユーザ削除
op delete user <user>
# 一覧取得
op list (users | groups | vaults | items | documents | templates) [--vault <vault> | --group <group>]


レポーティング(パスワード漏洩チェック)機能がある


1Passwordにはドメイン侵害レポートがあります。自社が管理するドメインを登録しておくと、漏洩に巻き込まれたアドレスを見つけることができます。このレポートを元にしてパスワードの変更をユーザへ促すことができます。


導入にあたっての課題


課題は大きく3つありました。

  • プランの検討
  • SSO(シングルサインオン)が可能か
  • プロビジョニングが可能か

プランの検討


1Passwordのビジネス向けプランは3つあります。
  • Teams
  • Business
  • Enteprise
結論から言うと弊社はBusinessプランを選択しました。

Teamsプランでは、詳細な権限管理ができないため、全社的に導入するとなると機能不足でした。

Businessプランでは、より詳細な権限管理からログ管理やレポート閲覧まで豊富な機能を備えているため、SaaS製品としての機能が十分であると判断しました。また、Azure Active Directory、Okta、OneLoginと連携できるのもこのプラン以上になっています。弊社としては、グループで管理できることが運用上大きなメリットでした。ユーザ単位で権限管理をするのは運用が煩雑になると思います。

Entepriseプランでは、上記の機能に加えて専用窓口を設けてくれたり、導入にあたりトレーニングを受けられるなどのメリットがあるそうです。ですが弊社ではそこまでのサポートは必要なく、Businessプランで利用できる機能さえあれば十分でした。

SSO(シングルサインオン)が可能か


弊社のシステム選定基準では、基本的にSSOが利用できるシステムを選定しています。しかし、1Passwordの仕様上SSOは不可でした。SSOできないことは利用者目線に立つとある程度の不便さはあります。ですが1Passwordの認証の堅牢性の土台となっているSecret Keyの有用性とのバランスを考慮して、SSO不可であることを許容しました。

プロビジョニングが可能か


プロビジョニングを行うためには1Password SCIM bridgeを構成する必要があります。
  • Google Cloud Platform Marketplace
  • Docker, Kubernetes or Terraformで構築
SCIM bridgeサーバを構築するために、主要なクラウドサービスにおいて試算を行いました。しかし、現状ではコストメリットが無さそうだったためプロビジョニングの導入は一旦見送りました。会社の規模拡大に合わせ、再度検討したいと思っています。プロビジョニングの代わりに、前述のコマンドラインツールを活用し運用することにしました。

実際の運用


全社導入前に一部の部署で1Passwordを先行利用していたのですが、その時はグループを利用しておらずユーザを保管庫に直接割り当てる運用をしていました。しかしこれでは統一性もなく管理が煩雑だったため、グループベースで管理するように運用を変更しました。ユーザからの利用申請も、kintoneを用いたワークフローで管理し、保管庫とグループの一覧はスプレッドシートにて管理することにしました。

スプレッドシートで管理した理由は2つあります。

1つはグループや保管庫、グループ内メンバーの一覧と、グループがどの保管庫と紐付いているかをユーザが確認できるようにするためです。ワークフロー申請時にどのグループの権限を変更するかなどを記載してもらう際に必要な情報だからです。

もう1つは各保管庫の運用管理者を把握し、ワークフローにおける承認ルートにその保管庫の運用管理者を入れるためです。1Passwordの管理者からでは、各保管庫が実際にどういった使われ方をしているのか分かりません。そのためメンバー追加などの依頼時に各保管庫の運用管理者の承認を確実に得た状態で、管理作業を行っています。

導入効果


パスワード管理の理想的な運用基盤を構築できたことが大きな効果でした。人に依存した運用ルールで安全にパスワードを管理することは限界があります。パスワード管理ツールを用いることで、半強制的にガイドラインに沿った運用へ切り替えることができました。また冒頭で記載した通り、パスワードを平文で保存することはセキュリティリスクになります。そのためパスワードを暗号化できるパスワード管理ツールは、セキュリティの監査に対する解決策の1つとしても有効です。

分かりやすい効果としては以下のようなものがありました。

共有アカウントのパスワードを安全に共有できる


様々なパスワードを覚える必要がなくなり、パスワードジェネレータによって強力なパスワードの生成が容易になりました。例えば自分が共有しているパスワードを変更したとしても、1Password上のパスワードさえ更新されていれば、他の人に新しいパスワードを都度共有し直す必要はありません。利用者は自分のマスタパスワードだけを覚えていればよく、パスワードが変更されたことを知らずともログインできるからです。

また、セキュアにID・パスワードの共有が可能になり、閲覧権限の範囲をコントロールし易くなりました。例えば範囲がチームをまたぐような場合でも、専用のグループを作って該当者を入れてそのグループに保管庫の閲覧権限を割り当ててあげればよいわけです。

多要素認証のワンタイムパスワードの代替


さらに便利だと思ったのは、多要素認証で使用するワンタイムパスワードを1Password上に保存できることです。Authenticator系のアプリと同じように秘密鍵を1Passwordに保存することで、1Password上にワンタイムパスワードが表示されるようになります。


通常、多要素認証ではSMS(ショートメッセージサービス)やAuthenticator系のアプリでワンタイムパスワード(認証コード)を得るため必ずモバイル端末が必要になってしまいます。多要素認証を1Password上に保存すれば端末に縛られない運用が可能になります。

具体的な手順を解説します。

  1. まずは設定したいシステムの設定画面で、多要素認証の追加(もしくは変更)を実行し、その手順の中で秘密鍵を取得

    Authenticator系のアプリで読み取るためのQRコードが発行される画面などで、秘密鍵を表示できる箇所があると思いますので調べてみてください。※各システムによって異なります

  2. 秘密鍵を入手したら1Passwordのアイテム編集に移動

  3. 1Passwordのアイテム編集画面でラベルの欄にある…(三点リーダー)アイコンを選択


  4. ワンタイムパスワードを選択


  5. ワンタイムパスワードの欄に、先程入手した秘密鍵を貼り付けて保存

以上の手順でワンタイムパスワードが表示されるようになりました。元の秘密鍵を入手した画面(手順1)に戻り、6で表示されているワンタイムパスワードを入力して認証し作業は完了です。

まとめ・残課題


実際に導入してみて、パスワード管理ツールに慣れていないユーザからはいまいちよく分からないツールだと思われてしまう印象がありました。そのためマニュアルとは別に使い方を解説する動画を制作し、ユーザがより理解しやすいように工夫しました。

パスワード管理ツールは入れて終わるツールではありません。例えばパスワードをブラウザへ保存してるユーザに対して1Passwordへの移行を促す必要があります。また、ドメイン侵害レポートをチェックし、漏洩したパスワードを使用しているユーザにパスワードの変更を呼びかけることも重要です。活用方法や正しいパスワードの管理方法などは都度啓蒙していく必要があると感じています。

telnetは暗号化できる!?


 telnetは認証情報含めて平文で通信されるため、今ではケシカラン行為の代名詞的なものになっている、、、はずだった。

ところが、最近、telnetが暗号化に対応しているらしい。

詳しくは下記の動画(35:00周辺)参照。


当然普通に使っただけでは暗号化されるわけはなく、オプションを使う。

例えば、Ubuntuにはtelnet-sslという実装があるようで、こういったパッケージを使う。

【普通のtelnetのキャプチャ】


【暗号化されたtelnetのキャプチャ】


今でもたまに「telnet使いたいんですけど」っていう問い合わせがまれにある。

今後は下記のような対応を心掛けたい

×:telnetは問答無用でダメです

〇:telnet-ssl等で通信が暗号化されるならOKです。


【参考】

telnetは通信を暗号化できる…らしい

現代のTelnetは暗号化できる



FireEye Red Team のツールに対する不正アクセスに関して~CommandoVMとは~



概要

国家支援を受ける高度な技術を持つ攻撃者が、FireEyeがRed Teamに用いるツールを窃取しました。攻撃者はこれらのツールを所有していると考えており、また攻撃者が盗んだツール自体を使用したり公開したりするかどうかは不明であるため、FireEyeはこのブログをもって数百もの対策を公開し、多くのセキュリティコミュニティがそれらのツールから自らを保護できるようにしました。私たちはFireEye製品にもその対策を反映させ、パートナーである政府機関とこれらの対策を共有し、攻撃者がRed Teamツールを悪用する可能性を大幅に制限しています。

これらの対策のリストは、FireEyeのGitHubリポジトリにて公開されています。

Red Teamのツールとテクニック

Red Teamとは、可能性のある攻撃者による攻撃や情報窃取を模倣して企業のセキュリティ体制を評価する、セキュリティ専門家からなる組織化されたグループです。当社のRed Teamの目的は、攻撃が成功した場合の影響を実証し、防御体制 (Blue Teamなど) が運用環境でそれらに対抗する方法を示すことによって、企業のサイバーセキュリティを向上させることです。当社は、世界中のお客様に対して15年間にわたりRed Teamアセスメントを実施してきました。その間、私たちはお客様のセキュリティ体制改善に役立つスクリプト、ツール、スキャナ、テクニックを開発してきました。残念ながら、今回これらのツールが攻撃者の窃取の対象となりました。

盗まれたツールには、探査の自動化に使用される単純なスクリプトから、CobaltStrikeやMetasploitなどの一般的に利用可能な技術のようなフレームワーク全体に至るまでさまざまです。Red Teamツールの多くはすでにコミュニティにリリースされており、オープンソースの仮想マシンであるCommandoVMで配布されています。

一部のツールは、基本的なセキュリティ検知メカニズムを回避するために修正された公開ツールです。その他のツールやフレームワークは、Red Team用に社内で開発されたものです。

ゼロデイ攻撃や未確認技術は含まれず

窃取の対象となったRed Teamツールには、ゼロデイ攻撃ツールは含まれていませんでした。対象となったツールは、世界中の他のRed Teamも使用している、既知かつ文書化された手法を適用したものです。これらの盗まれたツールが攻撃者の総合的な攻撃能力の進歩に大きく寄与するとは考えていませんが、FireEyeは万が一の自体に備えて、できうることをすべて行っています。

FireEyeは、攻撃者によるこれらのツールの拡散や利用を確認しておりません。また、セキュリティ・パートナーとともに、今後も活動を監視し続けます。

検知技術の提供でコミュニティを支援

組織的にこれらのツールを検知していくための支援として、ツールが実際に使用された場合、それを見分けるために役立つ対策を公開しています。今回のRed Teamツールの窃取の対応として、OpenIOC、Yara、Snort、ClamAVなど、一般に利用可能な技術に対する数百の対策をリリースしています。

FireEye GitHubリポジトリにてその一覧を公開しています。新たな検知技術や、すでにリリースされている検知技術の改善が行われるごとに、公共レポジトリにおけるホスト、ネットワーク、ファイルベースのインジケータなどの対抗策をアップデートし続けます。さらに、GitHubページでRed Teamツールの効果を制限するために対処する必要があるCVEのリストを公開しています。

FireEye製品による顧客保護

FireEyeは、チーム一丸となって、お客様と広範なコミュニティを保護するための対策の構築に取り組んできました。これらの対策を製品に取り入れ、国土安全保障省などのパートナーと共有し、製品に対策を取り入れ、広くコミュニティに対応しています。

利用可能な検知シグネチャの詳細については、GitHubリポジトリを参照してください。

バックアップ(CommandoVM)

実企業におけるサイバーセキュリティというのは、アドホックに臨機応変に構築するのが難しく、決められたプロセスに従って時間をかけてちょっとずつ改善と変化を積み重ねていくしかない(転載)


ポーランドのエキスパートに聞く「社員のスキル向上に投資したら、学ぶだけ学んで転職してしまうではないか」 (1/2) - ITmedia エグゼクティブ:

 この連載では、海外のサイバーセキュリティ分野の友人にインタビューする形で、サイバーセキュリティのエキスパートがどのように育ってきたのか、サイバーセキュリティはなぜ難しい課題なのか、企業がサイバーセキュリティと向き合う上でどういったことが重要なのかなどさまざまな考え方を紹介しています。

海外エキスパートインタビューシリーズ第3回は、ポーランドの友人パウエル・ヤツェヴィッチ(Pawel Jacewicz)の話を紹介します。

 海外のサイバーセキュリティ友達の中でも、ポーランド人は何名かいるのですが、「ポーランドにはサイバーセキュリティの専門家が育ちやすい事情があるのではないか」と個人的には考えています。

 パウエルに会ったのは、ポーランドの首都ワルシャワに訪れた際、国立研究所のリサーチプロジェクトの紹介を彼がしてくれたときのことでした。彼は話をするのが大好きなので、プロジェクトの説明を延々としてくれて、いつまでたっても話が終わらないので、彼の上司に中断されていたのが印象に残っています。それ以来、ポーランドに行ったときや、彼が来日したときには一緒に食事をしています。

では、内容に入ります。(元のやりとりは英語で行われていますが日本語に意訳しています)

筆者 パウエル(以下P)、今日はありがとう。まずは簡単に自己紹介をお願いします。

P 私の名前はパウエル・ヤツェヴィッチです。現在はスタンダードチャータード銀行のグローバル・サイバーセキュリティ・センターで働いています。サイバー脅威のハンティングを主な仕事にしており、銀行のサイバーセキュリティの中でも、サイバー攻撃の予兆などをプロアクティブに発見する仕事を主にしています。他にもいろいろな仕事はしていまして、人材育成や、内部むけのコンサルティング、自分の能力開発、新たなITの学習なども行っています。

筆者 ありがとうございます。これまでに、どのようにITやサイバーセキュリティを学んできたか教えてください。

P 自分は小さい頃から、モノがどのように作られているのか、どのように動くのかといったことに興味を持っていました。このスタンスは自分の職業人生のなかでも非常に重要な意味を持っていると思います。

 私がサイバー空間で冒険を始めたのは、1990年代後半に初めてPCを手にして、56kのモデム(筆者注:その昔、電話回線を利用してインターネットに接続するときに利用していたデバイスのことです)でインターネットに接続するようになってからです。インターネットに触れはじめて、書籍や友人達からは得られないほど膨大な知識を得られるようになったことに驚きました。

 時間をかければかけるだけ急速にいろいろなことを学びました。特に力を入れたのは、コンピュータやネットワークがどのような仕組みで動いているのかということですが、そのなかでもLinuxを使い始めてからDebianに恋に落ちました(筆者注:DebianとはLinuxディストリビューションの一つで、どちらかというと玄人に好まれる傾向があるように思います)。

 サイバーセキュリティに関わるようになったのは2009年からで、その年からポーランドのナショナルサートであるCERT.PL(筆者注:日本におけるJPCERT/CCのポーランド版です)働き始め、結局8年間そこで勤めました。サイバーセキュリティの仕事に深く関わることで、ネットワークセキュリティやサイバー攻撃の検知などかなり詳しく学ぶことになります。

 その間、世界中のセキュリティカンファレンスに参加し、サイバーセキュリティ業界で最も輝いている人たちに会うことができました。そういった経験が、自分の今の専門性を維持したり継続的に学び続けたりする姿勢を作り上げてくれました。

 CERT.PLの次は、ポーランド最大手の銀行のインシデントレスポンスチームで働き始めました。そこでは、企業におけるセキュリティ対策はどのようなものか、金融業界がサイバー攻撃の脅威とどのように向き合っているかを学ぶことになります。

 リアルタイムで起きている攻撃がどのようなものかを知りましたし、また実企業におけるサイバーセキュリティというのは、アドホックに臨機応変に構築するのが難しく、決められたプロセスに従って時間をかけてちょっとずつ改善と変化を積み重ねていくしかないということも学びました。

 銀行を辞めた後、いわゆるBig4と呼ばれる大手コンサルティング会社のインシデントレスポンスチームに加わりました。そこでは、大企業も中小企業もそれぞれの悩みをもってサイバーセキュリティの対策に取り組んでいることを知りました。

 大企業は既に構築されたサイバーセキュリティの取り組みを改善する方法を模索していますし、中小企業はごくごくわずかなリソースでサイバーセキュリティという強大な敵にたちむかうにはどうしたらよいのかということに悩んでいました。そこでの経験で、ポーランドにおけるサイバーセキュリティの課題は何かを深く学ぶことができました。

 今のスタンダードチャータード銀行に転職したのは2019年のことです。非常に優秀なサイバーセキュリティチームのメンバーたちと共に働くことができて大いに満足しています。

筆者 サイバーセキュリティをよりよいものにするためには何が重要でしょうか?

P 一昔前のサイバーセキュリティは誰にも注目されず、いわば会社の地下で何をやっているのか誰も知らないような仕事でした。誰にも邪魔されず自分たちの好きなことをやっていられたのです。

 けれども、今は社長をはじめ役員もサイバーセキュリティに意識を向けるようになり、ウイルスとはなにか、サイバー攻撃とはどういうものか、ランサムウェアとは何か、データが漏えいしたらどのような影響があるのか、といったことを日々聞いてくるようになりました。

 今日、サイバーセキュリティは望むとも望まずとも、全ての人の生活に深く浸透しています。サイバーセキュリティの課題を長期的に無視していれば、深刻な問題を引き起こすことは間違いありません。これは国という単位でも、企業や個人という単位でも同じ事です。現代の戦争はサイバー空間で発生しています。これは、われわれサイバーセキュリティの専門家が何年も言い続けていることです。

 これから来るであろう攻撃に備えて、企業はサイバーセキュリティに投資しなければなりません。特に重要なのは、「自社のネットワークやシステムで何が起きているのか」を知ることです。

 何か攻撃が起きていることを見つけた場合、企業は積極的に攻撃に関するデータを他社と共有すべきです。これがいわゆるインテリジェンスといわれているものです。これによって、同じ攻撃が大規模に成功することを防ぐことができますし、被害の範囲を最小化することができます。データの共有は非常に重要なのですが、法律や規制などが原因で難しい場合もあります。法律や規制は刻一刻と変化する脅威に適合し続けることが難しいのです。

 企業では、インシデント対応とモニタリングを所管するブルーチームの運営が一般的になってきました。そこに、脅威ハンティングのチームを加え、サイバー攻撃の予兆を早期に発見するようになり、さらに企業の防御システムを実際に攻撃することによってテストするレッドチームも加わってきています。

 最近ではパープルチームとしてブルーチームとレッドチームのせめぎ合いを調整する取り組みも見られます。このような取り組みはとても効果的ですが、中小企業が自力でやるにはコストがかかりすぎます。

 中小企業でサイバーセキュリティの専門スタッフを抱えられるところはごく限られています。現実的には、そういったところは外部のコンサルタントに依頼して、セキュリティサービスを購入しています。

 しかし私見を述べると、それは長期的な観点で効果的とはいえません。なぜならば、内部のスタッフが能力を身につけて、自社内でできるようになったほうが費用対効果の観点で効果が高いからです。もちろん短期的に問題を解決したい場合は外部のコンサルタントは非常に有効ですが、長期的な視点で捉えたときには違うと考えています。

 私が最初の銀行に勤めていたとき、常に外部のコンサルタントを活用していました。しかし、コンサルタントが何をしているのかを学び、その能力を時間をかけて身に付けることで、内製で実施できるようになり、結果的に外注コストが大幅に下がったという経験があります。

 私が推奨したいのは、業界ごとに固まって、監督官庁が主導する形で企業間の実務的な演習を企画、実施する方法です。そうすることで中小企業でもスタッフの教育を効果的に行うことができるでしょう。

 世の中では机上演習がよく行われています。机上演習は組織の意思決定の訓練にはなりますが、実際に手を動かして作業する人たちの訓練にはなりません。具体的にどんな作業をどのようにするのか、どういった環境や機材が必要なのかということを知る機会が必要です。 

 また、本番では絶対にできない「実験的に試す」といったことができるのも演習の良いところです。もちろん、机上演習は経営層など組織上層部むけの意思決定の訓練にはとても有効ですので、机上演習と実務的な演習を組み合わせて行うことが効果的でしょう。

筆者 サイバーセキュリティの仕事をしてきた中で特に印象に残っている出来事を教えてください。

P 私がポーランドの銀行業界で働くようになってからすぐに、業界全体を巻き込む歴史的なサイバー攻撃が発生したことによって業界全体が大混乱に陥る様子を目の当たりにし、業界横断的な協力関係の構築が不可欠だと実感しました。

 それは2017年の始め頃に発生した攻撃です。ポーランドの金融規制当局のWebサイトが改ざんされ、いわゆる水飲み場攻撃によって、ポーランド国内の多くの銀行の社内ネットワークでのマルウェア感染につながったものです。これは、現在に至るまでポーランドの銀行業界にとって最も深刻なものです。この攻撃が明らかになったのは、とある銀行の社内ネットワークでマルウェアの活動が発見されたことがきっかけでした。

 当初は誰も金融規制当局が関係していることなど考えもしなかったのです。そして何週間も気付かないまま攻撃は進展していきました。私は自分が勤めていた銀行の社内ネットワークを監視していて、不審な兆候を発見しました。

 社内にはネットワークやシステムのセキュリティ監視システムがしっかりと入っていたので、挙動をトレースすることで原因を突き止めることができました。社内ネットワークでマルウェア感染が明らかになり、それが金融規制当局のWebサイトからもたらされたものであることが判明したときは本当に驚きました。

 銀行というのは通常巨大な組織であり、こういった攻撃の分析を1人で行うのは不可能で、チームで仕事をする必要がありますし、社内外に多くのステークホルダーがいる状況です。分析には膨大な時間がかかるため、外部のリソースから協力を得る必要もあります。組織を越えて協力し合うことの大切さ、観測できたデータを共有することの大切さ、それがあって初めてインシデント対応は成功するということを、この事案対処の経験を通じて学びました。

 繰り返しになりますが、助け合うことやチームワークは非常に重要で、他の何にも代えがたい価値があります。ポーランドの金融業界のサイバーセキュリティコミュニティーでは、この攻撃は歴史上最悪なものだったけれども、業界として協力し合うことの必要性を気付かせてくれた最も価値のある事案でもあったと、現在でも話題になります。この事案を繰り返さないようにという思いで、われわれはサイバーセキュリティ能力の向上、サイバーレジリエンスの強化に取り組んでいます。

筆者 企業の役員はサイバーセキュリティについて、どの程度、どのようなことを理解しておくべきだと思いますか?

P サイバーセキュリティは投資であるという認識を持つべきです。企業活動は利益を上げることがメインです。そんなことは誰でも分かっています。企業の役員は、サイバーセキュリティチームは企業の目的や目標を達成するために必要不可欠な支援をしてくれていると考えるべきです。

 企業でサイバーセキュリティの仕事をする人たちの知識や能力は、どんなセキュリティ製品でも、サービスでも、監査でも得ることのできない貴重なものです。その企業のネットワークやシステムのことを隅々まで知り尽くしている人は社外にはいません。サイバーセキュリティの仕事をする人たちの能力に投資することは、企業がサイバー攻撃の被害を受ける可能性を低減することへの投資です。

 ある企業の役員が「社員のスキル向上に投資したら、学ぶだけ学んで転職してしまうではないか」と言ったことがありました。それに対して私は「人材のスキルに投資しなければ、何も学ばない人たちがずっと社内にい続ける、ということではないでしょうか?」と答えました。

 企業における一般社員はいわゆる一線の防御を担う役割がありますが、実際には彼らがもっとも狙われやすいポイントでもあります。一般社員がサイバー攻撃の最新の脅威のことを考えてくれなければ、到底企業全体を守り続けることは不可能です。世の中には無料で得られるサイバーセキュリティの情報ソースがたくさんあります。一般社員にも分かりやすいように解説されている記事もあります。そういった情報を共有するなど小さなことから始められる取り組みもあり、その積み重ねが未来の自社を守ることに繋つながるのです。

 従業員の一人がうかつにメールの添付ファイルをクリックしてランサムウェアに感染して、何億円もの身代金を払う事を考えたら抜群のROIだ、というのが私の意見です。

※筆者注:金融業界でよく使われる考え方にThree Lines of Defenseという三線防御でリスクコントロールするというコンセプトがあります。一線で一般社員が業務執行部門としてリスクオーナーとして対処する、二線でサイバーセキュリティを含むリスク管理の専門部署がリスクに対処する、三線は監査の観点でリスクに対処するという考え方です。

筆者 これからサイバーセキュリティを学ぼうと思っている人たちにアドバイスはありますか?

P 伝えたいことが3つありますが、その前にサイバーセキュリティはとてつもなく巨大なフィールドです。サイバーセキュリティの分野では、誰もが自分に向いている仕事を見つけることができるでしょう。

 それを踏まえた上で、1つ目に大事なのは何にでも興味を持つことです。そうすることで自分に適した仕事がどれなのかを発見することができます。

 2つ目に大切なのは壊してしまうことを恐れない。何かを深く知りたいと思ったら、それを分解して元に戻すということは仕組みを学ぶ上でとても大切です。誰かがやった記事を読んだりするだけではなく、自分の手でやらなければ理解することはできません。そのようなスタンスで学び続けることを楽しんで、同じような考え方をしてくれる仲間を見つけることも大切です。自分でやってみることで、他の人の経験からも理解することができます。

 3つ目に大切なのは、夢中になれることをやっている間は、体中の血液の巡りがよくなってずっと起きていられます。それは要するにあなたに向いている仕事だということです。

 今回はポーランドの友人、パウエルの話を紹介しました。公的な立場のセキュリティ専門機関から銀行へ転職し、そのあとコンサルタントへ転職、その後銀行に再び転職という経緯をへた彼ですが、実はいつか日本で働きたいという思いを持っています。

 来日したときに国内企業との面談をアレンジしたこともあるのですが、うまく折り合わず彼の希望は実現していません。今回の彼の話では、私もよく質問を受けるセキュリティの内製化に関して一つの考え方を提示してくれていると思います。

 また、セキュリティが好きでセキュリティの仕事をしている人たちがどういったメンタリティなのかということについてもその一つの姿を提示してくれています。