[開催レポート]GMO Developers Night#34 / ペンテスターから見た最近のセキュリティ状況

登壇:GMOサイバーセキュリティ byイエラエ株式会社

4/21(木)にGMO Developers Night#34 「ペンテスターから見た最近のセキュリティ状況」をオンラインにて開催しました!

今回は、GMOインターネットグループにジョインした「GMOサイバーセキュリティ byイエラエ株式会社(旧称:イエラエセキュリティ)」のホワイトハッカーたちが、幅広いトピックを対談式でディープに語りあかしました。

イベント告知:https://developers.gmo.jp/15344/

本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。

登壇者(敬称略)

  • GMOサイバーセキュリティbyイエラエ株式会社
    代表取締役CEO 牧田 誠
    オフェンシブセキュリティ部部長 ルスラン・サイフィエフ
  • 株式会社川口設計
    代表取締役 川口 洋

会社説明

牧田

当社のミッションは、「日本のセキュリティを守る」ということです。誰もが犠牲にならない、安全なインターネット社会を創っていきたいと思っております。
逆に言うと、現在はあまりセキュアではないということになるんです。

我々、ペンテスター、ホワイトハッカーから見ている世界、日本の最近のセキュリティの状況と、一般の方々が見ている世界では、少し違いがあると感じています。
我々はあまりセキュアではない世界を見ているんですけど、恐らく今日参加されている500名の皆様も、そこに気付いているからこそ参加されているのではと考えています。
今までの侵入テストの案件をすべて集計して統計をとったところ、90%以上の案件で侵入に成功しているという結果が出ました。
我々ペンテスターは、90%以上の会社やシステムに対して侵入できる、脆弱であるという景色を見ていて、この景色を、このあとの対談の中で少しでも参加者の皆様と共有できたらと思っています。

そして、GMOインターネットグループに4月にジョインし、新しい社名で活動していますが、その理由は、我々が掲げている「日本のセキュリティを守る」というミッションを最短で実現できるからです。
イエラエのホワイトハッカーが持つノウハウをプロダクトに落とし込んで、プロダクトをGMOインターネットグループのお客様、ドメインでいうと日本の90%、レンタルサーバーだと日本の60%のシェアを持っているわけですけど、我々のサービスでそれらのお客様を守るというのが、グループジョインの理由です。

対談

テーマ:ペンテスターから見た最近のセキュリティ問題

川口

最近のセキュリティ状況をペンテストで見てきて、話題はありますか。

最近のテーマは「監視」です。

ルスラン

川口

ペンテストで、お客様のシステムの監視はどのようにできているのでしょうか?監視をくぐり抜けてゴールを達成しているケースが多いように思いますが。

監視に検知されずにゴールを達成することもあるし、あとはゼロトラスト環境で端末が監視されていても不足していることが多い。
基本的に多くのお客様はセキュリティ製品を導入、運用している。しかし、そのような製品は今まで出ている攻撃やばらまき攻撃に対してはすごく有効だけど、そうでない攻撃を使えば、技術のある攻撃者なら監視をすり抜けることは可能です。

ルスラン

川口

依頼されるお客さんは、それなりにやってるからペンテストやろうといるのに、セキュリティの監視をやっているにも関わらずここは監視されてるだろうからこうやって抜ければいいよねとルスランさんはかいくぐってやっているということ?

それもあるし、案件やお客様の要望に応じることもあります。
例えば、お客様の中で我々のセキュリティ製品が本当に稼働しているか確認するために、Emotetのような攻撃を実行してみましょう、ということでテストして評価という感じですかね。ゼロトラスト環境を作ったので評価してあげるという感じですね。
例えばAzureのグローバル管理者を奪取することが最終ゴールの案件であればそこまでたどり着いたけど、監視チームに検知されなかったというのはあり得る話ですね。

ルスラン

川口

Azureグローバル管理者を取られたたら、為す術がない、アドミンとしては聞きたくない報告だ。
「ゼロトラスト」というキーワードは、マーケティングや営業のキーワードとしてよく使われていて、うちもそろそろゼロトラストを考えなければ、と導入する動きがここ2~3年進んできているけど、広くゼロトラストだと言っている環境においても、ペンテストで抜けていって、権限が取れたというケースがあるんですね。

あります。ゼロトラスト自体の考え方はモデルとしてはいいんですけど、実現しているベンダーさんや、導入している会社での実装状況によって変わっていったりします。

最近ですと、ゼロトラストといいつつVPNの代わりにVPNっぽいものを入れた製品もある。
あとは、SaaS化されたとか、SSOが実装されたとか、IdP(Identify Provider)としてはAzureやOktaを使っているという例も多い。

一つの例で言うと、セキュリティ製品がいろいろ導入されている端末、仮にEDRとかアンチウイルスとか全部あるという端末に感染ができた場合、外部遠隔操作ができた場合、かつEDRとかも検知されていない場合、通信も判別されていないという状態であれば、攻撃者としては全部SaaSなので、オンプレミス環境がない環境を考えてみると、すべてクラウドになると、すべての業務がクラウドになります、一番守りたい資産、社員の守りたい資産といえばブラウザになるんですね。ブラウザの中のCookie、多要素認証がいろいろ付けてあっても、人は対象のサイトに認証してあるんだったら、多要素認証を通しての形で、そのセッションを我々が取得できたら、外部からもどこからでもアクセスできる。
EDRは、そこの端末にあるからこそ動作するが、我々がVPNのセッションを修復できるのであれば我々の端末から内部に入れるとか、モニターできるツールをすり抜けるいうことも実現します。
ゼロトラストは端末がすべてだから、端末から来るものを全部監視するけど、通信がどう監視されるかは基本的に会社によるというということになります。

ルスラン

牧田

今の話はエッセンスが2つあると思います。
最初の「監視が大事」ということ、これはペンテスターの視点。我々のような一般の人は、防御の方へ行きたいじゃないですか、ファイアウォール、ゼロトラストやEDRといった防御の方に行きたい。監視が大事って話は、EDRやファイアウォールはバイパスできる前提で考えないといけないよ、というペンテスターの目線なんです。

2つ目は、ゼロトラストで全部クラウドになって、セッション1つでシングルサインオンで全部いける点、みんなにとっては便利だけど、攻撃者、ペンテスターにとっても便利であること。
オンプレミス環境だと、セッションが分かれていて、全部セッションをとらないといけなかったけど、シングルサインオンで、マルウェアに感染して、ブラウザのセッションをダンプすれば、そのあとは全部のセッションに行けてしまう。ゼロトラストは、ペンテスターにとっても便利だし、完全にセキュアではないという点。

川口

Cookieをとるとか、聞きたくない話ですね。攻撃者に入られて、Cookieを持っていかれましたとなると、そりゃそうだよね…となるけど、運用や設定でなんとかなるものなんですか?
Cookieを取られないようになんとかしようなのか、それともCookieを取られてもいい策をとるのか、どっちがよいでしょうか。

対策といえば、セキュリティ製品にすべて頼るというのは、現時点では見たことないです。
多少カスタムなものを作って、仮にChromeを使っている場合はChrome以外から使うことがないので、Cookieに触れた瞬間に監視してアラートを出すといったものを作るとか、現時点では有効な感じ。そのあとの話となると、不審アクセスのような感じでCookieが取られて、攻撃者であればあちこちにアクセスするとか、例えばAzureEDのようなIdPに外部からアクセスしてしまったとか、感染した端末を踏み台にすればIPアドレスも変わらないけど、外部からいきなりアクセスした場合はIPアドレスが変わる、といったような、細かいログを解析して不審だなといったのを見ていくしかないと思う。

こうなってくると、SaaS側ですべてのログを収集しながらやるという必要があるし、boxなどのクラウドストレージの場合は、いきなりいろんなファイルにアクセスしてダウンロードし始めたということならある程度見られるぐらい。

ルスラン

川口

守りにくいと思いますがどうですか?

牧田

そうです。開発者は守りたいじゃないですか。Cookieを取られないための対策もしますし、万が一取られても大丈夫なように、暗号化したり、端末のホスト名やユーザー名、macアドレスなど全部マッチしない限りセッションを有効にしないように工夫する。でもペンテスターの目線だと、ならばそこを解析すればいい、と考えるんですね。この暗号化方式で鍵はこれね、じゃあ復号して、macアドレス変えて、再暗号化すればいいよね、と。

対策が大変なのは、SSOみたいな感じで各サイトに認証するじゃないですか、SSO自体の対策としては、例えば各サイトにアクセスするにはまたIdPとか多要素認証、一番よければYubiKeyみたいなFIDOがあってさらに認証しなければいけないという導入ができるのであればよいが、ただし認証済みのセッションが取れるということは、基本的には、各サイトのCookieの有効期間がサービスによって異なるので、例えばAzureのSSOのCookieの有効期間を1時間とすればそれは1時間で切れるが、BOXやDropboxなどのほかのサービスでは1か月とか無限とか異なるので、そのあたりのコントロールは、ユーザー側、システム管理者側にはないので、そこがちょっと大変。

ルスラン

テーマ:開発者が使っているサービスで気になるもの

川口

開発者が使っているサービス、代表的にはGitHub回りだけど、ここになんか情報が入っているとなると、そこのアカウント権限が取れちゃうというところからスタートするというのがあって、日常のオペレーションでGitやGitHubを使わざるを得ないところにペンテスターが差し込んでくると、ここも攻略の糸口になっているケースが多いと思いますが。

我々のゴールはいろいろあるけど、やり方もいろいろあって、例えば感染済みの端末からスタートするとか、外部公開されている情報を探してそこからエントリーポイントを探しに行きます。両方とも外部の情報を集めるので、Gitから始めることはあります。

会社名を入れるとかいろいろ検索して、何も見つからない案件はほぼなく、そもそも企業の中に開発者がいない案件ぐらいかもしれないですね。あっちこっちに認証情報がどこでもあるというわけではありませんが、情報収集という意味ではかなり役に立つものがあります。
昔の事例でいうと、Gitってなにが悪いかというと、何か間違えてアップロードした後に消しても、コミットが消されていない状態であれば、誰でも履歴から過去のコミットを見て情報が得られるので、ある案件では、鍵が取れて、鍵から外部のサービスにAPIキーで入れて、そこから内部情報が取れたというケースがあります。

ルスラン

川口

ついうっかりコミットしたという例があると思う。認証情報とかをignoreに入れずについ入れてしまって、消したからいいだろうと思ったらコミットの方にあるみたいな。見えるよね、探れるよね、というところから、あとになって悲鳴が聞こえるパターンですよね。

牧田

一番びっくりしたのは、あるセキュリティ製品で、ソースコードが公開されたというもの。

あれは、開発者というよりは開発者のインターンが会社に入ってDropboxのリンクをメモの中に入れていて、Dropboxのリンクに入ると、機密情報が誰でもダウンロードできる状態だったのでかなり大変でしたね。

ルスラン

川口

Dropboxのリンクとか1回リンク作ってしまって期限なしになるから、それがどこかで漏れると、フォルダ以下だったらざくざく見れてしまいますね。

そうですね。プレミアムサービスに加入しなければ、基本的にアクセス経歴とかも取れない。

ルスラン

牧田

無料版で使っている場合は確かに。会社アカウントだけじゃなくて、個人のプライベートのアカウントで会社の情報まで間違ってコミットしちゃったというのがあって、ペンテスターってすごいですよね、すぐに人を特定して、この人がこのTwitterアカウントを持っていて、と紐付けて、そこで鍵が取れてしまって、とかいうのがあったりするので、プライベートで使う時は気を付けないといけないですよね。

川口

会社が創業期だったりすると、そのあたりが割と緩く管理されたりするじゃないですか、個人の能力に依存してシステムが開発されてたりしてとか、もしくは中途で結構できるエンジニアが入ってきたりすると、ちょっと境界線が甘い時期があって、そういうところが突かれると厄介。会社が大きくなると結構きっちり分けて管理するようになると思うけど、会社のステージによっては割とケアされてなくて、ペンテスト受けてみて気付くパターン。

牧田

僕が面白いと思ったのは、自分たちの会社で使うソースコードの中で、固有の言葉を入れて、それをクローリングしておくということ。
誰かが間違ってパブリックにした時に、固有値を検索して引っかかるのですぐ止められるというのは、賢い対策。
みんな気を付けて二重チェックとか三重チェックするといっても、注意力に頼る部分って限界があるので。

テーマ:運用管理体制のチェックが必要だと思ったこと

川口

今度は運用回りで、このあたりはもう少し気にした方が安全なのでは?という事例を聞きたいと思う。
開発できちんと作っていても、運用が一番ベタだけどシステムのパスワードを書いたExcelファイルがあって、パスワード管理台帳を取り出せるという例が結構あったりする。
わたしもいろいろ相談を受ける中で、パスワード管理台帳を持って行かれて、さんざんシステムをペンテスターにやられましたという相談を受けることがあります。

結構あります。特にオンプレミスのドメインがあるとファイルサーバーもあるので、「平文パスワードの管理」「共通パスワードの管理」「脆弱なパスワード」が報告書の中のTOP3。
たぶん最近はクラウドのみの環境になってきて、みなさんがパスワードマネージャーをきちんと使うようになってきて、少なくはなってきた。
でも、やっぱり大企業やオンプレがある環境とかだと整理が大変だし、昔ながらのやり方で残していることが多いです。

ルスラン

川口

ここまで頑張ってやってるのに、なぜパスワードリストやパスワードを書いた手順書がさらりと置いてあるんだという感じの相談を受けると、ここがなんとかなればもうちょっと安全なのにと、見つけたのがセキュリティベンダーの方でよかったなあと。

そうですね。平文パスワードはないにしても、基本的に我々がゴールとするシステムが、仮になにかしら特殊に作られたシステムにしましょう、そのシステムのパスワードが毎日変わるわけでもないし、たぶんいつか作られてずっと運用されている形になるので、どの会社でも「納品物」みたいな感じのフォルダがあるんですね、そこに仕様書があって、その仕様書の中にパスワードが書いてあるとか、それで半分以上のパスワードが取れるという感じ。

ルスラン

川口

納品物フォルダはゾッとしますね。あるあるですけど。

納品されてからパスワードを変えていればいいけど、そのままなので…。隣りに変えてはだめと書いてあるので。

ルスラン

川口

パスワードは想像できるが、APIの鍵のような鍵管理をどう安全に運用していくかというのは、鍵を使わないケースというのはせいぜいSSHの公開鍵ぐらいという組織もあれば、APIの鍵をバンバン使いこなす企業もあるけど、鍵管理はどうですか?

SSHに関していうと、そもそもSSHで鍵を使って認証しているのであれば、かなりいい方という感じ。
それにYubiKeyで二段階認証があれば、おお、すごいという。
となると、基本的にそのサーバーは対象にしない。ゴールを達成するためには絶対にその経路を通るということは必要ないので、ほかを探すことに決めます。
パスワードが分かっているSSHの証明書だったら、それはちょっと解析してみてみるとか、あとは社員個人のアカウントだったらそれで入ってみるとか、牧田さんと一緒にやった案件では、ある鍵ですべてのサーバーに入れたというところもありました。

ルスラン

牧田

各企業で監視用、障害対応のものを作りがちだけど、それが仮に攻撃者に取られたりすると、悪用されてしまう。

ほかのAPI鍵とかAWS鍵になってくると、今でも外部と内部という感じがあって、例えばある会社だと内部はセキュアという考え方で、その中では内部のGitがあって、内部のGitはそもそも認証なしでエクスプローラですべてのプロジェクトが見れたりして、それが内部だから鍵がそのままハードコードされていたりするのもあります。

そうなると、アクセス制限ができてない会社がかなり多い。要は、開発者であってもアクセスできる領域がどこまでかを決めなければならないはずだが、何でもかんでもできるとか、一般社員で営業なのにGitに入れてプロジェクトをクローンできるとか、認証なしでイメージをとれるとか、そこからいろいろ鍵をとって本番環境まで至ってしまうこともあります。

あとは、会社によっては、物理的にセキュアエリア、セキュアルームを作っているけど、論理的にはそこのネットワークに入れてしまうとあとは信頼性の高いエリアということで二段階認証もなにもないということもあります。
オンプレ環境で横展開してしまうと、監視に気付かなければずっとそこにいて何でもできるという状態になります。二段階認証を破らないと入れない環境だと、かなりできてるな、と喜ぶ。しっかりやってるなと。

ルスラン

牧田

せっかくセキュリティルーム、物理的に行かないとデータベースに触れないという制限を作っても、運用を考えると、障害が発生した時に自宅から緊急対応したいじゃないですか、セキュリティパッチを緊急で当てたいとか。そうした場合、物理的にセキュリティルームとかデータセンターに行くのが難しいので、皆さんどうしても遠隔でアクセスしたくなるんですよね。
で、メンテナンスの手順書を作り出して、きちんと鍵もパスワードもそこに丁寧に書きがち。そうすると、せっかく物理ルームにアクセス制限してるのに、緊急メンテナンス用、障害対応用のVPNの情報が見れてしまう、アクセスできてしまう場合が多いので、そこを使って入れてしまうということがあるんですね。

結局、緊急用の手順書や鍵を置いてあるところは仮にファイルサーバーとして考えても、ファイルサーバー自体がおそらく信頼のあるユーザーしかアクセスしないと考えられているかもしれないけど、ある権限までは入れてしまう、確かに物理的に行かないとどこかに入れないけど、手元に緊急用のVPNの認証情報がなんでもあるから、それを使い回してつなげばよいというのもある。もちろん繋げる時間を決めてあるかとか、繋がった途端監視されて切断されるとか、会社によってはプロセスがあるはずだけど、一番悪いシナリオでは、何も気付かれず監視されずだったらそこにまで入って終わってしまう。

ルスラン

川口

そんな危ないシステムを動かすのなら、Slackに一報を飛ばして欲しいですね。
本当にここが突破されたらまずいというところは、通知が飛ぶ仕組みになってないと気付きようがないですね。

通知はすごくいいと思います。
特に管理者側におすすめなのは、資産管理、どこに何があるかとか、そのシステム自体にはどのように入れるかを把握しておく、彼らが自分で考えて作った経路はあると思うけど、我々も中に入って社内wikiとかを読んで、正常に入れる経路を把握する、それがイコール我々がその経路を通ると検知されてしまう、だったらそれを通ってはいけない、だから同じサーバーなり同じシステムに、ほかには入る経路は何があるかとか、管理者自体がどんなふうに入ってメンテナンスするかを考えてみて、それを利用してしまうと実はそこには検知やアラートを出す仕組みをわざわざ入れてない、あるいは忘れたということがあって、最終のところまで入れてしまうということもある。検知を回避するという意味では。

ルスラン

川口

ある役所で相談を受けたとき、「分かりやすいところにパスワードを置いてありますから」と言ってました。悪い人が先に使うと思うので、先に使ってもらってアラートをあげてもらいますという。このバッチファイルなんですか、と聞いたら、「それはログインしたら危険なものです」という。分かりやすく置いてあるので、使われることをむしろ期待しているという、使った人がいたら速攻取り締まりますという。

それはいいですね、ハニーポット的な。

ルスラン

川口

わかりやすく置いていれば使われるんだという。たぶん、ログインすると全職員にアラート飛ぶんだろうなという。それは手間が掛からなくできそうだと。

その次のステップを考えないといけなくて、どこからやられたかとか、次に何を確認すべきか、という演習。IR(Incident Response)的な。要は、端末をネットワークから取り出さないといけないけど、どのくらい時間がかかるとか、ユーザーが高権限のアカウントをハニーポットにしてある場合は、高権限のアカウントで実は横展開されてしまった可能性はなないか、どういう風に実装していたかにもよるけど。

ルスラン

牧田

Active Directoryの問題があるじゃないですか、あれは非常に守りにくい。
たぶんルスランさんは侵入できなかったことがないと思うんですけど、以前印象に残っていたフレーズで、「Active Directoryの侵入方法は無限にあるから大丈夫だ」と。侵入できそう?大丈夫?と聞くと、「無限にあるから大丈夫」という。ならばどう守ったらいいのという。例えば「administrator」というダミーのアカウントを作って、使われたら取り締まるというアイディアはいいなと。

でも、どのアカウントでも作っていいというわけではない。ある会社で、ダミーアカウントを作りましたと、でも、どう見てもそのアカウントを使いたいという気持ちにならなかった。なぜかというと、権限も何もなにもない、ログインした経歴もない、パスワードが弱いかもしれないがそのアカウントが取れたところで何も変わらないという。

確かになんとかアドミンというアカウントだったけど、どうみても権限がなさ過ぎて逆に怪しいということは侵入者からは見えるんです。
生きているかのようなアカウントで、多少権限があって履歴があるようなものを作ってあげないとすり抜けてしまう。

ルスラン

川口

クライアント認証をやっているシステムがあると思うけど、こういう時に突破できてしまう、こういう設定さえあればよかったのに、というエピソードがあれば。

最近、かなり多いですね。
クライアント証明書、ウェブアプリとか、個人的にはすごくいいと思うけど、その認証はその証明書をどんなふうに保管するかいうのが大事になってくる。
WindowsのマシンであればTPMで保存している場合は基本的には現時点では安全ですね。
どこかにはまだ公開されていない攻撃があるけど、少なくても今のところはTPMからの証明書の奪取ができない状況ですね。

ただし、TPMじゃなくて、ファイルとして保存してあるとか、スクリプトプロバイダーとかほかの形で保存してあるとかであれば、システム権限さえとれればWindows端末から証明書の奪取ができてしまうのが現実です。
Macの端末の場合は違っていて、MacはKeychainというものがあって、ユーザー側とシステム側のKeychainがあって、ユーザーのセッションに会社から遠隔操作ができる状態になっていたら、基本的にはすごく簡単にダンプしてしまうということができる。
システム側のKeychainに入っている場合は、ユーザー自分自身でルート権限でGUIから取るしかないのでまだ安全。

ルスラン

川口

証明書をさらりと普通のフォルダに置いているケースがありそうで怖いですね。

大企業の場合はどこかに集めてそれを配布するんですけど、全部バックアップ用に証明書が置いてあるとか。

ルスラン

質疑応答

質問1:あるシステムに侵入しようとして、SELinux ON の場合に侵入失敗・断念する場合はどのくらいありますか?

我々がやってる侵入の中では、Linuxにエクスプロイトを使って侵入するというケースはかなり少ない。基本的に運用や設計の問題で何かしてしまおうということが多くて、Linuxへアクセスするなら普通にSSHで一般社員がやるような形でかつバレない形にします。
外部の場合は、例えばあるサービスが脆弱でそれを利用するということはないことはないけど、かなり少ないのかなと思います。

ルスラン

川口

SELinux自体を使いこなすことも難しいし、製品によってはSELinux OFFで使えということも書いてあるので、ONで使っている環境が圧倒的に少ないですね。
きっちりできればいいけど、それでも日常のオペレーションで開発者、運用者と同じオペレーションでこられると、SELinuxが評価されてますね。

例えばリバースシェルがとれて、そこから侵入しようとすると、SE Linuxはかなり邪魔になるけど、そもそも我々が得たいなにかしらの目的にはSE Linuxを突破する必要性はないことが多い。必要であれば頑張るしかないし、別に触らなくてもいいという時もあります。

ルスラン

川口

だいだい、パスワードのExcelファイルが取れてたりするとそのまま入っていくよねということになるので、SE Linux以前の問題ですね。

我々の目的が何でもかんでも侵入していくのではなく、会社の資産、クレジットカード情報、個人情報だったりソースコードだったり、これを入手するということなので、経路は何でもいいということもあるんですね。ムリにそこを通らなくてもいいと。

ルスラン

質問2:「9割侵入できる」ということですが、実際にそこからデータ窃取できる割合はどの程度なのでしょうか?

大体同じ割合です。
ただ、ゴールが何になるかで変わったりする。ドメイン管理者を取ることがゴールでそこで終わるケースもあるし、守りたい資産、データへ入れるかどうかというケースもある。侵入はどちらも成功しているので確かに9割以上になるけど、データの取得まで頼まれたところで、できなかったことはほぼない、といえます。

ルスラン

川口

データの取得がゴールの場合、できなかったことはないのはすごいいい答えです。方法は無限にあるからというのと一緒で、分かる気がするんですよ。
いろんな企業にお会いすると、ルスランさんにやられることを期待する企業の方が時々いるんですけど、ほんとにみんな取られたいんだなという。

簡単に言うと、時間と予算の問題もあるので、我々が例えばスコープとしてフィッシングも入れますか、内部フィッシングを入れますかとか内部IRを突破しながらやりますかとか、IRに捕まったらどうしますかとか、無限の質問があるんですけど、IRに捕まったら無意味みたいなシステムの脆弱性だけを見るんだったら短縮の時間でいろいろやってできましたということを見せればいいし、IRが強いとかいう会社ならば、じゃあIRのままでやってみましょう、捕まることは可能か不可能かというところを見てみましょうというケースもある。

ルスラン

川口

ここでIRというのは、SOCのチームがいますよとか、CSIRTとの連携ができてますとか、それも含めてのIR?

はい。例えば社内のSOCがあるとか、誰かレスポンスできるような守り側のチーム、セキュリティチームみたいな人たちがいるとか、アウトソーシングしている、委託のSOCがいるとか、いろいろあったりする。

ルスラン

牧田

ペンテストの目的がセキュリティを試すことというお客様もいますし、ブルーチームとか、
IR、セキュリティチームがちゃんと運用できているか確認したいお客様もいます。ノイズが多いじゃないですか、誤検知とか、アラート来たけど違ったとか、そんな時に1回本物のやつを入れてみる。
本物のやつが来た時に、24時間以内に検知して対策できるかどうか、そういう目的でやられるお客様もいらっしゃる。

質問3:多要素認証のあるWebサイトの認証を通すのが毎回面倒です。ユーザビリティを落とさないセキュリティ強化はありませんか?

川口

確かに、毎回多要素認証求めてくるなよ、というのはやる側もすごく思うところ。
このブラウザを覚えて欲しい、とすごく思うけど、多要素認証が全部入れば言うことないということだけど、それはなかなか社内で浸透させにくいし、開発者に関しても開発効率が落ちるから何とかしてくれと言われそうだけど、お客様との会話や報告会でどういうアドバイスをされるんですか?

セキュリティ=ユーザビリティではないからですね、残念ながら。

ルスラン

牧田

攻撃者目線を知ると、ちょっと我慢できるようになるかもしれませんね。
例えば、パスワードの話に戻るけど、IDとパスワードだけの認証の場合、いろいろなサービスから漏れたパスワードをそのまま使っている方々もいっぱいいるし、それをちょっと1文字変えてとかでできることもあるし、Active Directoryのドメインコントローラに侵入できて、ハッシュ値を取って、8桁だと何時間で解けるんでしたっけ?

ハッシュの種類によるけど、Windowsであれば我々のサーバーなら数時間。

ルスラン

牧田

むかし、パスワードを8桁にしようよ、6桁はだめよ、という話があったけど、8桁のパスワードで数時間。どうしてもパスワードは漏れる。Emotetのように、ブラウザに保存したパスワードはダンプできてしまうんですよね。全部保存をしていたパスワードとIDが漏れてしまう前提で考えると、やっぱり我慢しようかという風に思えるかもしれませんね。

川口

ブラウザにパスワードを覚えさせるのは、非ITの人にはしょうがないという気がするけど、IT業界の人にはパスワードマネージャーを会社で導入してなんとかしたいという気もしますよね。

牧田

ブラウザのパスワードをダンプする、そうすればパスワードマネージャーを使いましょうという。恐ろしいですよ、すべての履歴をとられてしまう。

パスワードマネージャーも端末で実行できるんであれば、ダメかなと。
ものによって、例えばシステム権限で動いていたりするので、権限昇格をしない限りはまだマシであったりすることもあるんですけど、我々がやるときは権限昇格が必要だったら、必要に応じてゼロデイを探して出してやるというところもあったりする。
時間が許す限りはやれるけど、テストの期間はそれほど長くないので、3日程度で見つけられるのなら探すんですけど、それ以上かかるものは期間内には触らない。

ルスラン

川口

ペンテスターがゼロデイを見つけてくるとさらりと言うのは衝撃的だと思う。

牧田

次回の話題にしたいんですけど、セキュリティ製品って権限が高いじゃないですか、セキュリティ製品にゼロデイがあるととんでもないことになる。
我々一般の人はセキュリティ製品を信じるけど、ペンテスターは、2~3日で見つけられるのならゼロデイ見つけておこうか、そんな感じ。

あとは多要素認証について追加で言うと、各サイトに与える認証とかがあると便利だけど、SSOはあるにしてもその中で多要素認証みたいなものを実現できるのであればいいと思ったりして、例えばAzureのIdPを使って、いろんなアプリケーションにテストするけど、それはそれでよいけど、ただし、何を追加して欲しいかというと、例えば一部のアプリを絶対に守らなければいけない、例えばAWSの管理コンソールとかAzureの管理コンソールとかがあったりしたら、そこだけに例えばFIDOの確認を追加する、SSOされるときにはそこにアクセスする瞬間、多要素認証を聞かれる、多要素認証もできる限りFIDOにする、というのを個人的におすすめだと思う。

ルスラン

さいごに

ご視聴・ご参加いただき、ありがとうございました。
参加いただいた方からは参考になりました、興味深かった、またやってほしいですなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。

映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。

ブログの著者欄

デベロッパーリレーションズチーム

GMOインターネットグループ株式会社

イベント活動やSNSを通じ、開発者向けにGMOインターネットグループの製品・サービス情報を発信中

採用情報

関連記事

KEYWORD

採用情報

SNS FOLLOW