Security-JAWS第7回レポート #secjaws #secjaws07

こんにちは、臼田です。

Security JAWS第7回が開催されましたのでレポート致します。

Security-JAWS 【第7回】2017年11月13日(月) - Security-JAWS | Doorkeeper

セッションレポート

Session1:フューチャーアーキテクト株式会社 前原応光さん「経済的にハニーポットとログ分析をするためのベストプラクティス？」

• フューチャーアーキテクトとは
  • ゴルフやったり
  • Vulsやその他のオープンソースもやっている
• ハニーポット x AWS x Elastic
• ハニーポットとは？
  • 高対話型
    • 本物のOSやアプリ
    • 情報が得られやすい
  • 低対話型
    • エミュレートしたアプリ等
    • 情報は限定的
• DionaeaとCowrieを利用
• Elastic Stack
  • searchやkibanaを利用
  • Logstach
    • ログのパースが楽ちん
• AWSでも低対話型なら大丈夫
• やりたいこと
  • いろんなリージョンに配置したい
  • リージョン毎変化があるか確認したい
• 料金はサンパウロとか高い
• どんなログを取得したいか？
  • マルウェアを収集してスキャンかけたい
  • ドメイン、IPで変化するのか
  • pastebinでドメイン、IPを書いたら変化するのか
  • 攻撃ログ
  • パスワードやユーザ名
• どうやってログを収集するか
  • Cowrie - Elastic stack - Dionaeaは辞めたい
  • 常にElasticStackを起動したくない
  • ログを喪失したくない
  • 常にログを取り出したい
• 構成
  • CloudwatchLogs、S3に保管
  • Dionaeaは4台建てた
    • それっぽいページやドメインを用意
  • pastebinに公開するしない
    • 4台でIP・ドメインをそれぞれpastebinに置く、置かないを変更
  • マルウェアのスキャン
  • Cowrieの準備
    • 各リージョンに構築
    • VPCフローログ設定
• Logstash
  • Cloudwatch Logsの各種ログ
  • GrokとJsonFilterを活用
  • AmazonESはお金とバージョンの問題で選択肢外
  • VPC Flow Logs
    • プラグイン利用
  • Route53
    • GeoIP取得
    • LogFormatはもともと綺麗なので楽
  • json
    • 問題なく取り込める
  • virus total
    • そのまま突っ込むだけ
• 結果
  • kibanaで見てみる
    • ドメインを取得してpastebinに書くと一番マルウェアの検知が多くなった
    • ユーザ名は国ごと違う
    • 南米はmotherとかがある
    • WannaCryがいっぱい検知できた
  • Cowrieの結果より
    • アクセウ件数はアイルランド、サンパウロ、シンガポールが多い
    • コスパはアイルランドが一番いい
    • そもそもt2.microなのでそこまででもないかも
  • Dionaea
    • グローバルIPだけでなくドメインがあると結果がだいぶ違う
    • pastebinに登録すると取得率が上がる
    • オンデマンドとSpotFleetで稼働すると圧倒的にSpotFleetが安かった
• まとめ
  • ログをAWSに寄せることで必要な時に取り出せる
  • 保管の料金も安く済む
  • リージョン毎に料金が違うので東京にこだわる必要がない
  • pastebinは有効なサービス
  • virustotalのAPI上限には気をつけて
  • AWSのログは親切
  • LogstashのGrokは闇深いけど楽しいよ！

感想

コストも観点に捕えた内容で興味深かったです。

引き続きいろんな検証を行なっていただきたいですね。

Session2:合同会社パロンゴ 近藤学さん「What you see is what you get 〜 インシデント対応するのに、まだログ分析で消耗してるの?」

• ログの分析していますか？
• 一つのログだけではわからないので、いろいろ掘っていきますよね
• いろんなSIEMとかダッシュボードで確認できるツールが最近増えている
• これをもう少し進めてみる
  • 結局ダッシュボードでもトレジャーハントに近い
  • 上手く見つけないといけない
  • できるだけ短時間で適切なログを見つけたい
• ProtectWiseとは
  • SaaSのサービス
  • 機能
    • DPI
    • ビジュアル
    • 相関分析
    • タイムマシン
      • 時間を戻してリプレイもできる！
  • サイバーキルチェーンの可視化を行う
  • ShowNetでも利用していた

• AWS上で構築されている
• マルチクラウドで連携して利用可能
• デモ
  • 一画面で様々な情報が確認できる
  • DPIや機械学習、ML等複数の検知エンジンを利用して相関を取り、可視化されている
  • ログを突き合わせた結果をつなげて表示してくれる
  • 機械生成されているDNS名等も検知している
  • 全てのパケットをProtectWiseに送っているので、大きなファイルの送信履歴を確認することもできる
  • 例えば、2MB以上のトラフィックを出すなど
  • 裏側でインデックスを入れているので速い
  • 送受信の流れや地理的な流れ等もすぐに切り替えてわかりやすく可視化
  • タイムラインの時間軸を変えて、時間毎のトレンドを出したりできる
  • 過去にゼロデイがあった場合に、情報が出た後にそのパケットを遡って検知する機能がある(レトロスペクション)
  • IDSの独自ルール等も定義可能
• 今後はVR機能も追加されるらしい
• 取得方法はプロトコル毎に変更できる
  • フル
  • headのみ
• サーチはインデックス入れているので全検索ほど重くない

感想

相関をきちんと辿れるGUIでSIEMの一歩先の未来を行っている製品であることを感じました！

GUIもめっちゃなめらかに動いているのでぜひ触ってみたいですね。

Session3:日本電気株式会社 釜山公徳さん「Infocage SiteShell on AWS」

• InfoCageとは
  • NECが提供するセキュリティ対策ソフトウェア群
  • コンセプト
    • セキュリティマネジメント
    • システムセキュリティ
    • プラットフォームセキュリティ
  • 様々なソリューションがある
• InfoCage SiteShellとは
  • WAF(Web Application Firewall)
  • 特徴
    • 用意に導入/運用可能
    • 高品質サポート
    • 国産WAF
  • クラウドに適した製品特性
    • 環境に応じた導入形態
      • ホスト型
      • ネットワーク型
        • リバースプロキシ
      • スニファー型
      • SaaS型
    • AutoScalingに対応
      • 管理コンソールにて一括管理
      • スケールイン/アウト管理
  • 導入フロー
    • Windowsの場合3画面程度設定
    • 初期設定はデフォルトの設定がありほぼいじらなくてもいい
    • テストモードで導入してチェックする
    • 様子を見て1-2週間で本番を始められる
    • 設定自体は数時間程度
  • ローリソース/ハイパフォーマンス
  • 機能は一通りある
  • 検索エンジンを多層化している
  • 運用管理機能
    • 運用管理コンソールがある
    • ログやレポートの表示
    • 攻撃検知時のメール通知など
  • 独自サービスとして製品カスタマイズが可能
    • しっかり保証もする
• 製品デモ
  • ショッピングwebサイトにSQLiを実行するシナリオ
  • SQLiでユーザの個人情報が表示できた
  • サーバ機にSiteShellをインストール
  • 管理コンソールはTomcat + PostgreSQLで動作
  • SiteShellを動かした後同じリクエストを行うとエラー画面となった
  • 管理コンソールから検知した攻撃を確認できた
• まとめ
  • 導入簡単
  • 運用簡単
  • NECの全力サポート

感想

インストールが比較的すぐにできるのは使いやすそうですね。

国産WAFであるところでサポートなど期待できそうです。

Session4:Auth0 Inc. 古田秀哉さん「Auth0でAWSの認証認可を強化」

• Auth0
  • 認証認可のサービス
  • 使ってみた
• 事業法人の課題
  • 様々な企業・ユーザ・デバイスとの相互連携
    • ネイティブアプリ・タブレット
    • B2B、B2C
    • SAML、Oauth2.0
    • ソーシャルアカウント
    • セキュアなAPIアクセス
  • 今までのサービスではSSOできなかった
• Auth0をいろんなシステムに組み込むことができ、一括でSSOできる
• マイクロサービスアーキテクチャー思想で簡単に組み込める
• 認証認可のシステムは通常のサービスだと、全体の30%ぐらい工数がかかるくらい重たい
• 外出するメリットがすごくある
• Auth0の柔軟な設定変更
  • 例えば、Facebook認証を許可したければ、フリッピングスイッチをオンするだけ
  • 各サービスごとにスイッチがあり、わかりやすい
  • サービス以外でも、認証オプションもスイッチで変更可能
  • Anomaly DetectionやMFA、Touch ID等も選べる
  • リスク認証も可能
• Auth0の実装にどれ位の時間がかかったか？
  • 94%の企業が1ヶ月以内と回答
  • 通常だと、認証認可の仕組みに半年程度かかる
• cognitoの代わりに利用することでモバイルとの連係機能の工数を削減した事例もある
• あらゆる環境に実装可能
  • githubで様々なフレームワークに対応したコードが上がっている
  • あらゆるフレームワークや言語、デバイスに対応
  • オンプレでも利用可能
• ブログもあるよ！
• Auth0自体はマルチテナントしている
  • マルチクラウド
  • ハイキャパシティ構成になっている
  • アメリカ、ヨーロッパ、オーストラリアで稼働している
• デモ
  • WebサーバだけではなくAWSマネジメントコンソールへのSSO設定もできる
  • Tokenを用いたリソースへのアクセス
• フリートライアルできます！
• 東京Node学園祭でもブースとワークショップがあるよ！

感想

Auth0は簡単に沢山のサービスと連携ができるので、非常に良いサービスですね。

トライアルから簡単に始められるのでぜひ使ってみましょう！

Session5:株式会社ゆめみ 仲川樽八さん「失敗事例で学ぶ負荷試験」

• 負荷試験ってセキュリティと関係あるの？
  • 可用性の担保にかかるよね！
• 負荷試験本書いたよ！
• クラウドを使って可用性を担保するのが大事
  • クラウドだから安心なわけではない

失敗事例1

• 店舗での購入に応じて抽選券を配る
• 当選者には割引クーポンを渡す
• リリース当日にすぐ落ちてしまう
• 実際に取られた負荷対策
• キャンペーンサイトにユーザが流入するためのリンクを全て落とした
• 当選したけどクーポン表示ができなくなった
• 自己申告で全て割引
• 現場は大混乱
• まともな負荷試験していなかった

失敗事例2

• RDS最上位のインスタンスを用意していた
• しかし、スケールアップしても性能が上がるとは限らない

失敗事例3

• 実装全部終わった後に負荷試験だけやってくれ
• ユーザ、スパイク想定などが全くない
• 負荷試験を見据えたヒアリングをしよう
• 負荷試験をスケジュールの最後に持ってくると大変

失敗事例4

• 商用環境と環境が違う
• きちんと同等の環境を作ろう
• ローカルマシンのプロファイリングは裏目に出ることがある

失敗事例5

• 商用環境をそのまま使う
• 負荷試験は落とすつもりで行うのでそれは正しい
• ただし、連係システムとの兼ね合いを検討
• ゴミデータ等も気をつけよう

どうすればいいか

• 商用環境の検証ではSSL使うのか？
  • できればhttpだけの方がいい(攻撃側が1台等少ない場合)
  • 負荷試験の時は負荷が1/10以下のスループットになる場合もある
• 攻撃力が足りない場合
  • ツールが良くない
  • キープアライブができていない
  • 距離が遠い
  • サーバの能力不足
• 時間がない時に社内ネットワークから負荷試験をかけてみた
  • 会社のメンバー全員のブラウザにキャプチャ認証が出た
• とにかく実施してから考えよう
  • シナリオのスループット: 100rps等
  • 結果は本当に正しいのか？
  • どこにボトルネックがあるのか
  • 雰囲気に頼るとわからなくなる
  • 数学の定理の証明のように少しづつ正しいと思える範囲を増やしていく
• 雰囲気に頼らない負荷試験の順番
  • 単体のWebサーバに対する試験
    • 正しく攻撃できている
    • 静的ファイル
    • 単純なHalloworld
    • 参照系
    • 更新系
    • 等など
  • WebサーバをELB配下に設置して行う試験
  • 詳しくは本で！
• システムがスケールしないとき
  • 原因はスケールさせていない部分
  • 共有の外部リソースへのアクセス等
  • コネクションプーリングなど活用
• 岡崎市図書館事件等もあったし、負荷試験大事だよ
• 負荷ツールは複数使って、同じような数値がでるか確認

感想

負荷試験…すごく…大事です…

本気になりますね！

Session6: 株式会社クラウドネイティブ 齊藤愼仁さん「AUTOMOXで俺たちのVulsが殺されるのか」

• VulsではなくAUTOMOXの話をします
• Vulsとは
  • 脆弱性管理のオープンソース
  • エージェントレスで軽量
• ある日ポッドキャストでAUTOMOXの話を聞いた
• AUTOMOXはVulsにかなり似ている
• ただし、Vulsと違ってお金を取ろうとする
• しかしダッシュボードはすごくかっこいい

• サーバだけではなくクライアントOSも包括してスキャンできる
• アップデートもポリシーで自動的にやってくれる
  • サーバ群で分けて管理ポリシーをあてれる
• レポートはまだちょっとイマイチ
• リスクの値は自分で決められる
• settingでSlackとインテグレーションができる
  • アラートが来たらSlackにボタンを表示してサーバのrebootとかが可能
  • Slackがあるとすごい生きてくる
• まだ日本語は文字化け
• AmazonLinuxなどは問題なく対応
• 古いパッチは指摘してくれる
• 脆弱性情報はCVEと紐付いている
• 30日間フリートライアルできる
• まだこれからと感じる部分も多いが、イケてる部分も多い
• VulsもGUIあるよ！
• AUTOMOXはデバイス単価

感想

脆弱性管理は運用でずっと課題になるので、GUIで使いやすく、機能的にも運用しやすいのはいいですね

AUTOMOXが使いやすくなっていくか、注目していきたいですね。

さいごに

さまざまなサービスやプロダクトが出てきましたが、特に運用管理のGUIが焦点になっている話が多かったですね。

GUIは運用担当者のつらみに直結するだけでなく、実際のインシデントレスポンスにもかかってきますから、イケているGUIの製品が沢山出てきているのはいいですね。