セキュリティの終わりのない道

2024年7月の気になるインターネット記事をピックアップ

暑いですね…不要不急の外出禁止、という懐かしいフレーズがニュースで流れています。コロナも流行っているようです、皆さんお気を付けください。今月取りあげる記事は偶然にもすべて障害発生後にフォーカスを当てた記事となります。それだけサイバー攻撃、インシデントが身近なものになってしまったということでしょうか。今だから再認識したいセキュリティの原則組織に最も必要なセキュリティ機能とはどんな組織にも絶対に必要なセキュリティ機能を取り上げます＜略＞その中から絶対に必要な機能を1つだけ選ぶとしたら、何になるでしょうか。究極の質問の答えは、「セキュリティインシデント対応機能」です。どんな組織でもセキュリティインシデントは発生します。他業種に比べてセキュリティ対策に多額のコストを投じている金融機関であっても、社会のインフラとしてセキュリティ対策に一層の力を入れているクラウド事業者であっても、セキュリティインシデントに見舞われてしまうのは報道の通りです。企業においては、システムのバグや故障、悪意のある人間による攻撃などにより、セキュリティインシデントが起こるのは当然と考えたほうがよいでしょう。これに関しては完全に同意です。毎日のように情報漏洩ニュースが流れています。この記事には “どんな組織であってもセキュリティインシデントは起こるとの認識のもと、対応機能を備えておく必要があるのです” と言われてしまいました。では何をするべきか。企業がセキュリティ対策としてすべきことは ID管理、ログ管理、資産管理といった予防的対策インシデント対応訓練とあります。現在はGoogle WorkspacesやOffice...

2024, Aug 05 —

【ブックレビュー】OAuth 徹底入門

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 —

2024年6月の気になるインターネット記事をピックアップ

6月は気になるセキュリティニュースがたくさんありました。「当社の情報が漏えいしました」──世間へどう発表すべき？　タイミングは？　セキュリティ専門家に根掘り葉掘り聞いてみたふーん、という感じの記事でした。何かあった際「対外的な発表に向けた動きはどうする」「記者対応はどうする」という訓練までしている企業は、そこまで多くないんじゃないかと思うんですよね。＜略＞社内情報がマスコミを通して漏れてしまうと、結果として企業は説明責任を果たしにくくなる。インシデントが発生した際にはこういう対応をしました、と（企業自ら）説明責任を果たせるかどうかも、訓練の有無で変わると思います。まさに今ニコニコ動画がこの状況になってしまっています（NewsPicskがスクープで内部情報を暴露した）。山口さん：ある通信系の社長さんは知識豊富で、記者からの技術的な質問にも回答できており、企業のトップとしてあるべき姿と思います。ただ、全員が全員同じ対応を取るのは難しい。これは2022年のKDDIの障害対応のことでしょうね。アレは評価爆上がりでしたよね。 20 free cybersecurity tools you might...

2024, Jul 05 —

【ブックレビュー】安全なWebアプリケーションの作り方

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 —

バッファローが一部Wi-Fiルーターで脆弱性の注意喚起。対応しました

最近大きくニュースになっているこの話題を共有します。バッファローが一部Wi-Fiルーターで注意喚起、bot感染増加を受け　パスワード変更やファームウェア更新をこちらがバッファロー公式のアナウンスです。 NICTERの投稿に関する重要なお知らせ感染の疑いのある商品シリーズは以下になります。 WHR-1166DHP2 WHR-1166DHP3 WHR-1166DHP4 WSR-1166DHP3 WSR-600DHP WEX-300HPTX/N WEX-733DHP2 バッファローのWi-Fiルーターは価格と性能のバランスが良いことから大きなシェアを獲得しています。僕の自宅のWi-Fiルータも、実家のWi-Fiルータもバッファロー製です。自宅のルータの種類を調べたところ「WSR-1166DHPL」でした。リストには載っていませんが念のため調べてみたところ、バッファロー公式Xのアカウントに、上記の機種は問題ないかを質問してくれた方がいました。感謝。以下がバッファロー公式の回答です。...

2024, May 25 —

2024年4月の気になるインターネット記事をピックアップ

ゴールデンウィークも終わり、また厳しい戦いの日々が始まります。3,4月に気になった記事をストックしていたので紹介します。 OTのセキュリティでこれから必須になるインシデントへの対応 “OT”とは産業制御のこと。IoTとは別のセキュリティ対策が必要になるということなので、無関係と言わず読んでみることに。ソフトウェアのみならず、物理的な産業機械も今やインターネットにつながるのは当たり前で、サイバー攻撃の被害を受けています（アメリカのコロニアル・パイプラインに対してや、トヨタ自動車工場に対して等）エネルギー業界では2023年12月21日に、「高圧ガス保安法等の一部を改正する法律」と「認定高度保安実施事業者制度」が施行された＜中略＞　「事故（インシデント）調査は、事業者の報告を受けて国が必要と判断すればIPAも携わることになる。国の機関も対応するということは当該業界にとって非常に重要なことを意味する」 IPAが調査に関わる場合は、書面による調査と現場の調査が行われ、最終報告書が作成される。一連の調査では、影響の可能性があるシステムや機器、ネットワークなどの各種ログデータの保全や分析といったことが実施される。事業者側もこうしたことを可能にしておかなければならず、新たな対応コストとノウハウや人材などの不足が問題になるセキュリティインシデント対応のため、統一されたフォーマットを各企業が用意する必要があるこの運用は今後産業制御業界だけでなく、ソフトウェア業界にも広がるのではないか、と思いました。クラウドセキュリティにおける具体的な対策を検討、実践する上で知らないと損する文書まとめ AWSを使っていますが、クラウドを利用することによるセキュリティのメリットは感じます。業界のセキュリティ標準に合致した様々なサービス（AWS Config、GuardDuty、Secutiry Hub、AWS WAFなどなど・・・）をマネージドサービスとして利用でき、EC2インスタンスやRDSのような基本サービス自体にもプロバイダ側がセキュリティ対策を施してくれています、その上冗長でシステムを作ることで全ダウンなどを防いでくれています、これを自力で同じものを作ろうとしたら時間もお金も膨大でしょう。そのうえで、我々がここでやらなければならないものもあります。どんな業務が、どれぐらい重要で、誰に割り当てられ、今どの程度できているのかを表にした「セキュリティ関連業務サービスポートフォリオ」を作ることを推奨する。...

2024, May 12 —