ITmediaが開催しているセキュリティのオンラインセミナー「ITmedia Security 2024 Summer」。 いくつか視聴しましたので内容と感想を残します。 2030年問題への処方箋――持続可能な次世代サプライチェーン統制の要諦 NRIセキュアテクノロジーズ株式会社 DXセキュリティプラットフォーム事業本部 本部長 足立 道拡 氏 標的が会社自体から、会社の委託先・サードパーティへ（サプライチェーンリスク） ちなみに、「サードパーティ」と「サプライチェーン」の違いは、 サードパーティ・・・業務上の関係、契約のある組織...
2024, Sep 06 —2024年の上半期を振り返ると、毎日のように情報漏洩とランサムウェアのニュースが流れて、セキュリティに難があるのがもはや当たり前のような時代になってしまっているな、という感じがあります、そんな状況下で読んだこの本はタイトル通り教科書的かつ初歩的な内容となっていますが、何事も基礎が大切であるということは言うまでもありません。CISSPでも出題される知識も記載されているので、復習がてら読みました。過去の記事にも書いていたかもしれませんが、この本で紹介されているようなリスク分析・評価と対策を1度会社でやったことがあります。その時は今より知識も不足していて、周囲に対しても協力を上手に得ることができず、中途半端な状態で終わりました。そも、各事業部のメンバーにとっては（こんなことやっている時間はないんだけどな…）と思われていたかもしれません。 この本の前半はどのような本でも紹介されているセキュリティの基礎知識なのですが、中盤からは脆弱性対応に使用するフレームワークやテストの方法、後半からはインシデントハンドリングフローへの理解など詳しく図で載っているのがとてもありがたいです。CSIRTに関する記事はネットに散見されるが本は少ない印象があります。また手を付けると終わりのない作業になるため、この本が基本レベルの記載で留まっているのが逆にありがたいです。まずここを抑えればよいと考えれられるので。ただセキュリティインシデントの対応手順を作る必要があることは分かっているので、参考になるサンプル手順書を紹介してほしかったなぁ。 セキュリティオペレーションセンター(SOC)の役割：リアルタイム監視、ログ分析、異常なふるまいの検知、インシデントの検知と暫定対応です。中小企業だとCSIRTが利用するものと定義づけられる、と自分は思っているのですが、（そもそもセキュリティ業務すら兼業）SOCはSOC、CSIRTはSCIRTとちゃんと役割がに分けられていて、必要に応じてアウトソーシングされることが分かりました。むしろ中小企業こそ、全部自分たちでやろうとするのではなく、パブリックSOC/共用SOC（セキュリティ企業が複数の企業をまとめて監視してくれる）を利用するべきと知りました（KADOKAWAのような大きな会社がプライベートクラウドを社内に構築する一方、中小企業がAWSを活用するように）結局一番お金がかかるのは人件費なので。SOCで使われるツール、SIEMやSOARはとても高機能で。現代はAIを活用してインシデント初動対応もやってくれるらしいです。 そしてCSIRT。CSIRTに関連する資料はいろいろなサイトに掲載されていますが、この本は日本CSIRT協議会に加盟している組織のエンジニアが記載した本だけあり、まずはおさえるべきポイント、勘所を列挙しています。CSIRTは各事業部の情報連携の役割が主であり、インシデントマネージャやインシデントハンドラーは本来別の組織が担当するべきなのですが、中小企業だとどうしても兼務になってしまいますよね。 一つ印象に残っているのが、CSIRTに求められる人物像について記載されていた点です。こういう血の通った解説はこれまで読んだことがなかったのでありがたいです。 CSIRTコマンダーに必要な能力 IT、セキュリティ知識 情報を正確にやり取りするためのコミュニケーション能力 聞く 理解する 伝える 交渉力 論理的思考力 精神力（現場では攻撃側ではなく防御側を責めることがある） 知識、技術があることのみならず（むしろそれよりも）社内で様々な関連部署（経営層、法務、広報、各事業部、そしてインシデントマネージャ）との折衝が必要になります。上の箇条書きを見る限り、自分が向いているとは思えない…。人間力が求められます。僕にはとてもできない、という気持ちになる…(-...
2024, Aug 25 —暑いですね…不要不急の外出禁止、という懐かしいフレーズがニュースで流れています。コロナも流行っているようです、皆さんお気を付けください。 今月取りあげる記事は偶然にもすべて障害発生後にフォーカスを当てた記事となります。それだけサイバー攻撃、インシデントが身近なものになってしまったということでしょうか。 今だから再認識したいセキュリティの原則 組織に最も必要なセキュリティ機能とは どんな組織にも絶対に必要なセキュリティ機能を取り上げます ＜略＞ その中から絶対に必要な機能を1つだけ選ぶとしたら、何になるでしょうか。究極の質問の答えは、「セキュリティインシデント対応機能」です。 どんな組織でもセキュリティインシデントは発生します。他業種に比べてセキュリティ対策に多額のコストを投じている金融機関であっても、社会のインフラとしてセキュリティ対策に一層の力を入れているクラウド事業者であっても、セキュリティインシデントに見舞われてしまうのは報道の通りです。企業においては、システムのバグや故障、悪意のある人間による攻撃などにより、セキュリティインシデントが起こるのは当然と考えたほうがよいでしょう。 これに関しては完全に同意です。毎日のように情報漏洩ニュースが流れています。この記事には “どんな組織であってもセキュリティインシデントは起こるとの認識のもと、対応機能を備えておく必要があるのです” と言われてしまいました。では何をするべきか。企業がセキュリティ対策としてすべきことは ID管理、ログ管理、資産管理といった予防的対策 インシデント対応訓練 とあります。現在はGoogle WorkspacesやOffice...
2024, Aug 05 —CISSPの勉強中ですが、かなり寄り道してOAuthの勉強をしていました。 OAuth、というか正確にはOpenId Connectを業務で利用しており、業務のアプリチームの会話についていかなくてはいけないことと、業務内でよく使われているのであればそれについて理解しなければ、その実装のセキュリティリスクについて想像もできないことから今回この本を取りました。そもそもその両者の違いがネットで調べてもちんぷんかんぷんだったのもあります。 OAuthはどういう場所で使われているかというと、一時期は流行ったＸ(旧twitter)と連携し、過去のツイートを分析し、診断結果をツイートする診断メーカーをイメージすると良いかと。診断メーカーを利用する際皆さんはtwitterのIDとパスワードでブラウザで認証し、その際「過去の自分のツイートを読み取ること」「自分のアカウントでツイートすること」を許可にチェックを入れてボタンを押すはずです。この”許可”こそがOAuthです。以下が登場人物です。 リソース所有者・・・私たち クライアント・・・・診断メーカー 保護対象リソース・・twitter（投稿機能や過去の投稿データ） ←単なるデータ置き場ではなく、認可サーバが返すアクセス・トークンを元に処理を行うため”保護対象リソースサーバ”のほうが役割のイメージが湧くと思います 認可サーバ・・・twitter側の認可サーバ 認可エンドポイント・・・・・Web API。ここに向けてクライアントは認可を求める トークンエンドポイント・・・ OAuthはクライアントにリソース所有者が自身が実行できる保護対象リソースの権限の一部を委譲させ、代わりに実行させるプロトコルです。そしてリソース所有者の権限を委譲する機能を持つのが認可サーバ。認可を行う認可エンドポイントは”認可コード”をクライアントに返します。クライアントはこの認可コードをトークン・エンドポイントに対して送付すると、トークンエンドポイントは保護対象リソースへアクセスするためのアクセス・トークン（投稿ができるよ、この人のタイムラインを閲覧できるよ、という情報を持ったクレデンシャル）をレスポンスで渡します。このアクセストークンを使ってクライアントは保護対象リソースにアクセスします。 OAuthは「誰がこの認可の委譲を許可したよ」「どの権限を付与したよ」は分からず、「権限の委譲が行われたよ」というトークンを認可サーバからクライアントに返すプロトコル。そのトークンを分割して必要な情報を解釈するのはクライアントと保護対象リソースサーバの間で行われます。 文章で読んでも「？」となってしまうのは分かります。自分で書いていても上手く説明できてないな…と思いますから。図で見ると分かりやすいのですが。そしてその図と、実際のクライアントおよび保護対象リソースサーバ内のコーディングが手を動かしながら学べるのがこの本です。OAuthはシンプルな構造と度々書かれていますが、実際にはいくつものプロトコルを組み合わせて使います。実装の方法も複数あり、OAuthは「これを使え」という決めはしていません（これを利用しろ、という規約は特定の業界で作っていたりしますが）。そのため一度に学ぼうとすると頭が爆発してしまうでしょう(^^;) この本はOAuthを0から1つずつ順を追って解説してくれているため分かりやすいです（それでも一回読んで理解できるものではありませんが…）、各構成要素の実装方法から脆弱性とその対策（徳丸本で学んだ知識が活きます）、さらに応用である認証機能や第三者に権限を委譲する方法なども紹介しています。発売は5年前と古いため最新の情報ではないかもしれませんが、基礎は変わらないはず。OAuthについて0から学ぶのであればふさわしい本と思います。...
2024, Jul 28 —セキュリティ担当として会社のプライバシーマーク更新のために日々活動しているのですが、そんな自分にPマーク審査機関の日本データ通信協会（デ協）が主催したオンラインセミナー案内が届きました。 https://www.dekyo.or.jp/kojinjyoho/contents/info/zenkokuseminar_kaishi_2024.html せっかくなので視聴しました。セミナーで使われた画像やスライドについては公開禁止とのことですが、感想を書きます。非公開のセミナーなので具体的な事例や数値などは掲載しないようにします。 講演①「個人情報保護法等改正の概要と実務への影響」 近年コーポレートサイトに「Cookie取得の同意を得るポップアップ」の実装を求められるようになり、その理由をはっきり理解していなかったのですが、その法律的根拠、社会的背景について理解することができました。厳密に解釈すればコーポレートサイトや自社商品を紹介するサイト（EC機能はない）でCookie同意は不要なのかもしれませんが、「やっておくほうが安心」「我が社はお客様のプライバシーに対して意識を払っているアピール」はできそうです。 講演②「情報セキュリティ10大脅威 2024」から考える攻撃者を“先回り”する対策 セキュリティの仕事をしていると名前を聞くJPCERT/CC。その組織の正体は 国の公的事業としてインシデントレスポンスチーム 国際間、国内連携における窓口の役割 インシデント対応の相談に乗ってくれる組織で、CSIRT（各組織のインシデント対応機関）のハブとなり取りまとめてくれるリーダー的存在です。そんなJPCERT/CCの人が2024年のセキュリティ脅威について語ってくれました。 最近毎日のようにセキュリティインシデントが発生している印象があります。その理由について「攻撃対象が広がった」ことと、個人情報保護法の改正で、明確に漏洩した事実が確認できない場合も事故報告対象になり、被害公表対象が増加していることがあるのではと分析していました。特にランサムウェアの攻撃対象が従来の業種、企業より広がった理由についての分析は目からうろこでした（ここに書けないのが残念…） あとはオフィスにあるネットワーク機器の脆弱性を突く攻撃が増えているという注意喚起もあり、情シスと連携しないと、と思いました。VPN目的で利用されることも多いFortigateの機器2万台に中国のハッカー集団が侵入した、という記事もあります。 中国のハッカーが世界中にある約2万台のFortiGateシステムに侵入しているとオランダ政府の軍事情報安全保安局が警告 講演③「苦情・相談対応概況と報道された漏えい等事故を踏まえた注意喚起」...
2024, Jul 21 —6月は気になるセキュリティニュースがたくさんありました。 「当社の情報が漏えいしました」──世間へどう発表すべき？ タイミングは？ セキュリティ専門家に根掘り葉掘り聞いてみた ふーん、という感じの記事でした。 何かあった際「対外的な発表に向けた動きはどうする」「記者対応はどうする」という訓練までしている企業は、そこまで多くないんじゃないかと思うんですよね。 ＜略＞ 社内情報がマスコミを通して漏れてしまうと、結果として企業は説明責任を果たしにくくなる。インシデントが発生した際にはこういう対応をしました、と（企業自ら）説明責任を果たせるかどうかも、訓練の有無で変わると思います。 まさに今ニコニコ動画がこの状況になってしまっています（NewsPicskがスクープで内部情報を暴露した）。 山口さん：ある通信系の社長さんは知識豊富で、記者からの技術的な質問にも回答できており、企業のトップとしてあるべき姿と思います。ただ、全員が全員同じ対応を取るのは難しい。 これは2022年のKDDIの障害対応のことでしょうね。アレは評価爆上がりでしたよね。 20 free cybersecurity tools you might...
2024, Jul 05 —CISSPリベンジにむけて取り組んでいます。ただ合格に向けてコスパ・タイパ重視しすぎると、大切なもの、本来必要なものを見落としてしまう、と考えています。地道に長いルートを行くことが結果として最短の道になる、こういう風に考えるようになったのも齢を重ねたからでしょうか。良いことなのか悪いことなのか(+_+) “安全なWebアプリケーションの作り方”いわゆる「徳丸本」はソフトウェア開発におけるセキュリティで気を付けなければならないこと、対応策が書かれている本としてはあまりに有名です。著者である徳丸氏はWebセキュリティの第一人者であり、執筆、講演などで活躍されています。 徳丸 浩X(旧twitter) Podcast番組 #33 | Webセキュリティの第一人者の素顔 徳丸本は実際に脆弱性のあるアプリ（Webサイト）が付録についており（当時はCD-ROMがついてきました）実際に手を動かして脆弱性を確かめてみよう、という点がエンジニアに評価される理由だったと思います。 僕もかつてこの本でセキュリティを学んでソフトウェア開発をおこなっていたこともあります。おそらく自分が読んだのは初版(2011年出版)ですが、今回は第2版(2018年)を読みました。 この本が書かれたのは6年前ですが、紹介されている内容はセキュリティの基本中の基本。そして現代現場で使われている知識としてはけして陳腐化していません。「jQueryが広く普及している」というフレーズに時代の流れを感じますが(^^;) そして最新の脆弱性もこれら古典的な脆弱性の延長線上にあることも多く、温故知新です。 この本に書かれていることは、ソフトウェアを書いていない人間であったとしても、ソフトウェアエンジニアと会話をするためには知っておかなければならない知識です。まして僕は会社でセキュリティ担当の肩書をつけているので、自分の業務エリア（組織のセキュリティマネジメントやインフラ回り）だけでなく、アプリケーション側もちゃんとセキュリティ対応できているのかな、というのを機を使わないとならない、そう思いました。最終章「安全なWebアプリケーションの開発マネジメント」は参考になりました。 2018年にタイムスリップした気持ちで読んでいましたが、当時のリスクはアプリケーションやブラウザのバグに起因することが多かったため、そのため開発側がしっかり対策を取る必要がありました。しかし2023年現在、セキュリティのリスクは電子メールを基としたフィッシングサイトや、VPNやRDPが多くを占める、つまり”ユーザ側の対策不備によるセキュリティインシデント”が主流だと感じています。アプリ開発はプログラミング言語ないしフレームワークが用意している安全な関数を利用することで古典的な脆弱性はだいぶ回避できます。しかしセキュリティの最前線そして最大の危険ポイント「人間」はソフトウェアほどに進化できていません。時間が足らず最新版パッチを当てることができない、仕事が忙しくて注意が散漫だった、というのはなくなりません。開発側が徳丸本に書かれているようなセキュリティ対策を取ることは当然として、ユーザ起因のセキュリティ事故を如何に減らすのか、それを考えていかないとという気持ちを強く持ちました。
2024, Jun 29 —最近大きくニュースになっているこの話題を共有します（前回と同じ導入ですねｗ） 「パスワードは定期変更の必要なし」総務省が国民向けサイトで正式見解 この国民向けサイトというのは”国民のためのサイバーセキュリティサイト”のことになります。このサイトを国民が見てくれるかは疑問符がつきますが、実際このサイトはかなり丁寧に書かれていて、私はシステムを“利用”する人向けの対策を参考に、従業員向けの教育資料を作成しました。で、その中でもタイトルの項目は目について「お！」と思ってクイズで出題予定なので、これがニュースでバズった（死語）のは僥倖ですね。結果として正解率が上がれば従業員に定着しますので。 パスワードを複数のサービスで使い回さない（定期的な変更は不要） これまでは、パスワードの定期的な変更が推奨されていましたが、2017年に、米国国立標準技術研究所（NIST）からガイドラインとして、サービスを提供する側がパスワードの定期的な変更を要求すべきではない旨が示されたところです（※1）。また、日本においても、内閣サイバーセキュリティセンター（NISC）から、パスワードを定期変更する必要はなく、流出時に速やかに変更する旨が示されています（※2）。 僕が思うに、長く複雑、使いまわししないパスワードを毎月のように変えればそのほうが安全でしょう。しかしそれは実際の人間の運用を無視した理想論。長く複雑になればデスクにポストイットでパスワードを貼ってしまうでしょうし、毎月のように変更しろなんて言われたらXXX01、XXX02なんてパスワードになることは目に見えています。自分も過去そのようなパスワードを設定したことがあります。 上記引用元にもあるように、専門家の間ではかなり前から「パスワードの定期的な変更は効果が薄いよ」と言われていたのですが、PPAPでもそうだったように、長く染みついた習慣を変えることは難しい。しかし今回行政からもお墨付きが付いたということで、一気に広がると良いですね。 今後パスワードは覚えるものではなく、複雑なパスワードをサービスごとにアプリで管理する、となるとパスワード管理ツールが必要になります。私が以前本ブログで紹介したBitwardenや、昔からWindowsPCで使用されているID Managerがあります。1passwordは非常に優れたアプリですが残念ながら有料(月3ドル)です。モバイル向けに作られているWindows Authenticatorは無料の上パスキーの機能も有しており神アプリなのですが、PC版はないのでPCでサイトにログインするときにモバイルに表示されているパスワードを入力する手間がかかるのが唯一の不満点。 あとはパスワード管理ツールにログインするパスワードをパソコン内に平文で保存しておくと一網打尽になってしまうので、スマフォなど別デバイスで管理したり、多要素認証で保護したりするのが良いでしょうか。本当はパスキーが完全に普及すれば安全簡単にWebを利用できるのですがもう少し先になりそうですし、しばらくはこの新しいパスワードルールを覚えていただきたいです。
2024, Jun 15 —