【ブックレビュー】脅威インテリジェンスの教科書

この本の前書きに「セキュリティシステムは常勝を義務付けられているのに、攻撃者は一度勝つだけで良い」とあるようにサイバーセキュリティの世界は圧倒的に有利です。防御側の我々は組織内の『あれが危険』『これが足りない』と分かっていても、その工数も予算も捻出することはできません。だからといってそれを言い訳にセキュリティをなおざりにしてはならない・・・そんな状況で注目されているのが「脅威インテリジェンス」です。 攻撃する意図がある 攻撃できてしまう攻撃対象の状況がある 攻撃者自身に攻撃する能力がある この3つが揃ったときに脅威は現実化します。対してインテリジェンスとは 情報収集・加工・分析評価の成果物 成果物を作成するプロセス それらを行う組織 を指します。 単にデータ(Data)を収集するだけでなく、それを加工して情報(Information)とし、更に分析してインテリジェンス(Interlligence)とします。また脅威インテリジェンスも、対応する期間や組織などにより戦術・運用・戦略と分けられます。現代ではセキュリティは現場の技術者だけが考えればよいのではなく、経営者も検討する必要がある経営課題となっており、戦略が必要となっています。この本はその各分類に分けて、考えることをまとめています。本では様々なセキュリティに関する用語や組織が出てきます。MITRE ATT&CK(マイターアタック) どこかで聞いたことあるな・・・という用語はCISSPで学んだ知識でした。不合格なわけだ(ーー; 伝統的なリスク管理として『コンプライアンス型アプローチ』というセキュリティのAs isをTo beに持っていく方法がありますが、最初に書いたように資産が膨大、人は少ない状況ではすべてを対応するのは不可能です。ましてどんどん新しい脆弱性が生まれ、クラウドサービスなど外部ベンダーが保有するインフラ上で業務する場合、もはや手がつけられない分野も発生し、そこは相手がちゃんとやってくれることを信じるしかありません。...

Microsoft Authenticatorを使いパスワードレスでログイン

このブログでもたびたび名前を挙げていた「パスキー」 パスキーとは iOS・Androidも対応「パスキー」とはなにか? パスワード時代の終焉 パスワードの漏洩が不正ログインの根本原因ですが「複雑にしろ」「定期的に変えろ」「厳密に保管しろ」・・・「面倒くせぇ!」と僕らセキュリティ担当者ですら思います。一般の人ならなおさらでしょう。そりゃよく使われるパスワードも「password」「123456」「123456789」になるわけです。 世界で最も使われるパスワードは「password」「123456」 最新調査レポートにみるパスワード管理と各国の実態 セキュリティの一番の脆弱性ポイントは我々人間であり、パスワードというモノが使われる以上リスクは付きまといます。パスワードに対するブルートフォース攻撃やリスト攻撃、辞書攻撃に対して根本的な解決策として「パスワードレス」が叫ばれていました。 急に専門家っぽいことを書きますがw認証には3つのパターンがあります あなたの知っていること(パスワード・秘密の質問) あなたが所有しているもの(ICカード) あなた自身(指紋・網膜・静脈などの生体認証) 下に行けば行くほど精度の高い認証となりますが、導入にコストがかかります。 パスワードは最も簡単に実装できる認証でした。Webサイトのログイン画面に指紋認証機能を付けるのは非常にたいへんなのは分かると思います。 しかし、スマートフォンの普及が状況を変えました。今や世界中の人が所有しているスマートフォン、そしてスマフォのロック解除には指紋や顔認証など「あなた自身」を使います。これをWebサイトの本人確認でパスワードの代わりに使おう、というのがパスキーの考え方です。...

【ブックレビュー】ポストモーテム みずほ銀行システム障害 事後検証報告

twitterでも「GitHubが繋がらなくなった』「AWSが障害発生した」と度々トレンドになるように、たとえ一流のエンジニアが開発運用しているサービスでも障害は発生します。それはそうでしょう。規模も大きすぎてすべてをコントロールするのは困難でしょうし。トラブルのニュースが流れるたびに、中で奮闘しているエンジニアのことを思うと胃が痛くなります。 企業が利用・提供するサービスで障害あるいはヒヤリハットが発生した際、何が原因だったのか、どう対応したのか、改善しなければならない点は何か、をまとめたものをポストモーテムと呼びます。GoogleがかつてGmailの障害におけるポストモーテムを公開し、結果としてGoogleへの信頼が高まったという話があります。他社の障害対応はは他山の石になるため、僕ももっと読みたいのですが、企業秘密が関わることもあり、また恥ずべきものというイメージもあるのかなかなか公開されないのが現状。この本は2021年大きな問題となった、みずほ銀行のATMで障害が発生し、お金を引き落とせなくなるなど利用者に重大なダメージを与えた障害のポストモーテムとのことなので参考になるかと思い読んでみました。 ちなみにこの本、「ポストモーテム」と銘打っていますが、自分の考えるポストモーテムよりは些か文学的な書かれ方をされています。本来はこんな長文では書かれず、箇条書きで書かます。それだと読み物にはならないからでしょうが。 みずほは3つの銀行が統合して生まれたスーパーメガバンク。組織も従業員も顧客も大きいですし。そんなみずほ銀行が業務で利用しているシステムも間違いなく巨大なシステムのはず。エンジニアの苦労が忍ばれます。そんなシステムの大規模障害は、バグだけでなく、仕様の問題、ハードウェアの故障、検証で発覚した問題を解消しなかった問題、ヒューマンエラー、そして組織の体質。それらが超巨大なシステムの中で少しずつ連鎖反応あるいはタイムラグで1年にわたり発生していたようです。発生した障害のタイムラインを読むと、現場が地獄だったことが想像できます・・・。『7つの不手際のうち1つでも正しく処置できていればこれほど大きなトラブルにはならなかった』という結論は本当につらい。その不手際の真因も統合の前から脈々と続いていた問題だったことをみずほ銀行のシステムの歴史から紐解きます。そういえば大学生の頃、みずほ銀行で2重振込や2重引き落としのニュースがあったなぁ。「2重振込ならぜひ発生してほしいw」なんて冗談で当時言っていましたが、現場としてはたまったものではなかったのでしょう。 過去複数回の大規模障害を教訓に刷新された基幹系システムMINORIは過去のコードを採用せず、SOAを採用し、できるだけ生のコードを書かせなくして属人性を排除するなど優れたアーキテクチャで構成されていました。でもマシンだけでは駄目でマンも正しく動かなければならない・・・そのためにはやっぱり障害対応組織を作ることと、年に1度は復旧デモンストレーションを行うことが必要と、思ってはいるんですけど・・・てやつですね。 このポストモーテムから以下のような教訓を得ました。 疎結合=正義、密結合=悪ではなく、やりたいことを実現する優れたアーキテクチャをシステムの重要性などを考慮して採用する必要がある。 速度の関係でディスクではなくメモリにデータを保存する場合、容量のサイズには気をつける必要がある。なおAWSのマネージドキャッシュは自動で大きさを拡張するのでそこは大丈夫と思われる。念のためキャッシュサイズを監視することが大事。 利用者の声を聞くべく、twitterで自社名、自社プロダクトの単語を引っ張ってSlackに通知できるように・・・はtwitter APIの有料化により難しくなったのか。 障害発生時に自分たちで集まり、情報を共有、対応を勧めていけるようCSIRTはやっぱり必要。 事前に定めていた復旧手順では復旧できないというのはあるあるである。やっぱり年に1度は復旧デモンストレーションを行わなくてはという気持ちになりました。なった、だけだと駄目なのは分かっているのですが・・・。 「積極的に声を上げることでかえって責任問題となるよりも、自分の持ち場でやれることはやっていた、といえる行動をとる方が、合理的な選択」は大組織ならではなのかもしれませんが、風通しの良さと心理的安全性の大切さを感じました。

【ブックレビュー】今知りたいサイバー犯罪事件簿-セキュリティの「落とし穴」を示す15の事件-

サイバーセキュリティに関する書籍はこのブログでも何度も紹介していますが、今回紹介する本は3つの特徴があります。 1つは2023年に発売されたばかりの本ということ。サイバー犯罪における最新の情報を知る事ができます。日本でも現在進行系で発生しているランサムウェア攻撃、ロシア・ウクライナ戦争で使われているAIによるディープフェイク、SNSを活用したプロバガンダ・・・サイバー犯罪の進化はとどまることを知りません。一方で政府機関や企業がサイバー犯罪を防ぐための行動もまた、マルウェアを利用するなど物議を醸しています。サイバー犯罪の攻防はどちらも同じ技術が使われており、世のため人のためのために使う、と宣言した技術はいくらでも悪用可能なのです。 2つ目の特徴として、日本人が日本人向けに書いた本であること。日本人にも非常に読みやすい言葉が使われているうえ、日本で書かれた本ならではのエピソード「LINEのデータ管理」があります。LINEはコロナ対応でも使われるなど、日本社会にとって基幹インフラといえるアプリですが、その情報管理が甘かったことで批判を浴びました。クラウド上でのストレージにデータを保管することはどこでもやっています(僕の会社でももちろんやっています)が、データを保存している現地の法律が適用されるので、特に個人情報を保管する場合は注意が必要になります。 本書の最大の特徴は、一般人にとっては『それってサイバー犯罪なの?』と思いがちな「プライバシー」について多くのページを割いている点です。たとえば、Webサーフィンでブラウザに表示されるインターネット広告。これに用いられるユーザ識別子についても説明があります。「あなたが今欲しい商品、見たいサービスはこれですよね」が分かるインターネット広告はテレビのCMより効果が高いですが、裏を返せば企業に個人の嗜好を把握されているのです。Appleはプライバシーを重視する企業として知られ、また欧州ではプライバシーの意識が高く、GDPR のような法律も制定されました。プライバシーを侵犯することは犯罪という認識は世界で広がってます。みなさんも家の中が盗撮されていたり、読んでいる本がバレたり(思想の自由)するのは嫌なはず、しかし当たり前のように使っているインターネットサービスを提供している企業は同レベルのことが技術的に可能なのです。 一方でGoogleのサービスを無料で使えるのも、Googleがインターネット広告で利益を得ているからで、企業は利益を得られなければ存続できません。そのためOSや法律の規制を逃れてユーザ情報を取得しようという企業の動きは盛んです。にしても、Tiktokの『端末上の文字入力を取得してサーバに送信』は流石にやり過ぎでは・・・。 ユーザの閲覧履歴だけでなく、位置情報もプライバシーとなります。Googleマップを使っていると、位置情報のありがたさを実感します。その一方で『いつ、どこにいる』『どこに住んでいる』という情報は悪用された場合大きな問題となります。Googleの”ダーク・パターン”は、スマフォの設定で位置情報をOFFにしても、他の様々な場所のオプションをOFFにしない限り、Google自体には位置情報が送られ続けていた、というスクープです。不誠実ですよね。現代において『利便性』と『プライバシー』はシーソーの関係です。インターネット広告も僕にとっては「欲しい物がレコメンドされる」ということでありがたい面もあります。とはいえプライバシーには配慮してほしい。バランスが求められます。 僕自身インターネットを利用してサービスを提供する会社で働いているセキュリティ担当、この本に書かれていることは知っていなくては、そして考えなくては、と思いました。Googleがかつて標語としていた「Don’t be evil、(邪悪になるな)」は僕ら常々頭に入れておきたい。

【ブックレビュー】セキュリティの心理学

認知心理学や犯罪心理学を活用した情報セキュリティの防御策を検討している組織が日本には存在します。 https://www.iwsec.org/spt/ や  https://www.infosecpsychology.com/ です。 情報セキュリティにおいて心理学の効果はバカにならないはずです、すべてのセキュリティ専門家が口を酸っぱくして言っているように、セキュリティの最前線は結局人間であり、攻撃者は人間の心理をついてくるからです。アダルトサイトの請求や重要会議の議事録を騙る詐欺メールはその典型的な手口と言えるでしょう。事実セキュリティインシデントの最多要因は詐欺メールなのです。完璧な人間がいないように、完璧なセキュリティもありません。 1章ではセキュリティインシデントを引き起こすヒューマンエラーも偶発的なものではなく、「ある条件下では必然的に起きる」という研究成果を紹介し、それを導き出す理論やモデルが記載されています。内容を理解するのは非常に難しい・・・「お、おう、そうなのかー」という感想が占めますw が、ヒューマンエラーを起こす土壌には安全への軽視、なぜ安全が軽視されるか=正常状態の品質へのリソース傾倒という話は非常に重要で、セキュリティ担当者が経営層をちゃんと説得しなければいけない分野です。 2章では近年の情報セキュリティの対策が難しい理由が示されます。 セキュリティのCIAが情報資産によりまちまちである 1年前にはチャットAIは一般普及していなかったように、進化のスピードが早い OSSの普及によりアタックサーフェイスが増大 上記の結果として人間(ヒューマン)がついていけず、エラーを起こす よく我々は現代社会を生きていけますよね…。心理的側面からリスクをコントロールする術が紹介されています。操作者をターゲットとした攻撃モデルには「直接型」「間接型」「それを組み合わせた集団型」があり、いずれの対策も必要にあります。登録セキスペのオンライン講習にも出てくる不正のトライアングル(「機会」「動機」「正当化」)を防止することが重要ですが、人間を完全にコントロール化に置くのはコンピュータよりも困難です。長文による分析と、様々なモデルが提示されていますが、ここまで考えるのは・・・セキュリティのソリューションを販売する会社が考慮して、僕たちはその恩恵に預かるではだめなのだろうか。 第3章ではいよいよヒューマンエラーを重点を置き、その対策を提示します。シンプルに、同じ用途のものは近くに置き、混ぜるな危険のものを近くに置かないようにしたり、判断情報を視覚的に付与したりするのは基本的ですが有効です。逆に認知の歪みや理論、推論を提示されると解決策が分からんぞ。論文のような内容なので文章が読みにくいし、読むにも気力を消費します。エラーを起こしにくい人へのインタフェース提示のやり方がある、と書いてあるようです・・・(ふんわり)...

セキュリティチェックシート

世の中にあふれるチェックシート。僕もたくさんのチェックシートを作成し、利用しています。思いつくだけでも AWSのアカウントのセキュリティ強化のためのサービス利用、設定のチェックシート 委託先企業のセキュリティ体制を確認するためのチェックシート 個人情報を取り扱うWebサービスのセキュリティが十分であるか問い合わせるためのチェックシート また、僕が社外にセキュリティシートの記載を依頼するように、社外からも僕の勤める会社自体の、あるいは開発するソフトウェアのセキュリティが保たれているかを審査するためにチェックシートの記入を依頼されます。今や一つの企業が単独でビジネスを成立させていることはなく、構築を担当したSIerや取引先が攻撃されると全体に被害が及んでしまいます。これを「サプライチェーンリスク」と言います。ロシアーウクライナ戦争直後にトヨタの取引先工場がサイバー攻撃を受けて、トヨタが国内工場をストップさせざるを得なくなったニュースに記憶にある人もいるでしょう。 トヨタイムズニュース:小島プレス、サイバー被害から1年 苦難乗り越え深めた絆 サプライチェーンリスクを防ぐために取り入れられているのが、取引先のセキュリティ状況を把握し、安全な会社と取引をしていこうとする”セキュリティチェックシート”。契約を締結する前に、相手のセキュリティレベルを把握するために各企業が独自のフォーマットでチェック項目を作成しています。 「やらないよりマシ」 徳丸氏が語る“セキュリティチェックシートの問題点” こちらは会員限定の記事になりますが、”体系的に学ぶ 安全なWebアプリケーションの作り方”シリーズでおなじみ徳丸先生がおっしゃるには、チェックシートでOKならば万事問題なし、とはならない、気休め程度と。で、その気休めのために、記入を依頼してくる企業によっては100近くある項目(本当にこれだけの項目があります)を書かなければならない、バカにならない工数です。しかも「こんなことを聞かれるのか」という時代錯誤な項目がリストアップされていたら、やる気も失せてしまいますよね。 僕は会社のセキュリティ担当として、様々な取引先から受け取ったセキュリティチェックシートを記入するよう社員から依頼され、依頼されたからには記入して返送したのですが、同じような質問を複数の会社が確認してくることから疲弊してしまいました。そのため、セキュリティチェックシートでよく聞かれる質問と我が社の状況というリストを会社のセキュリティポータルに掲載しました。社員にはこれを見て自分でチェックシートに記入してもらおうと。どうしても分からないトリッキーな問い合わせは自分にエスカレーションするようにしました。 しかし・・・プライバシーマークを取得している会社に対して、個人情報の取り扱いについて独自フォーマットのチェックシートで細かく質問されると「認定とは何なのか」という気持ちになってしまいますね。それだけPマークの威厳が不足しているのかもしれませんが…僕が最近思うのは セキュリティチェックシート自体は価値があると思うけど、各社がフィーリングと経験則に任せてチェックシートを独自作成するのではなく、業界として「この産業ならこのチェックシート」という共通規格を作ってほしい プライバシーマークやISMSの価値を向上させ、それらの認定を得ている企業であればセキュリティチェックシートを送付することが不要である、くらいの社会的地位を持たせてほしい - そのためにこれらの認定の取得難易度は厳しくしてほしい...

情報処理安全確保支援士のオンライン講習を受講しました(2022年度)

※”情報処理安全確保支援士”は長いのでこの後は通称の”登録セキスペ”という単語を使います。 登録セキスぺは資格制度なので、毎年更新する必要があります。その費用が高額なのにそれに見合うメリットがない・・・という話題は本制度が出来た当初からさんざん言われており、検索すればたくさん記事が出てきます。更新しないことにより登録セキスぺの総人数が減った、というのが昨年のニュースでありましたが今年はどうなっているのでしょうか。調べてみましたが、該当する記事は出てきませんでした。 とはいえ、僕が会社で「セキュリティエバンジェリスト」の役職をいただいているのも、僕がこの資格を保有しているのが一つの理由と思われます。去年も書いたように教材そのものはよくできているので助かっています。 ロシアーウクライナ戦争により、2022年ほど日本国内でサイバーなセキュリティが注目された年は無かったと思いますが、それはセキュリティに関わる仕事をしている人だからそう感じているだけなのかな・・・。いつどのような手で襲ってくるか分からない相手のための防御、しかも防御が有効な時は評価されないのに、一突きをされて炎上したら批判されるんですよ、たまらない職業ですよセキュリティ担当者は。バーンアウトする人が多いというのは分かります。社会がセキュリティを重要視するのであれば、政府が一定の規模以上の企業において登録セキスぺの所属を義務化(必置化)したり、「仕事を頼むなら登録セキスぺのいる企業に依頼したい」という社会の共通認識が醸成されてほしいです。当然そうなったらより責任は重大になりますが・・・。 オンライン講習の内容は守秘義務があるため多くは語れないですが、講習内容も毎年更新されています。今年はクラウドを利用した業務前提のセキュリティに対する考え方が大きく取り上げられていました。また、社会でインシデントが多発したことからか、インシデント対応における企業内での組織の作り方と、どのように対応するかの実践的技術に多くのページが割かれていました。 講習を完了した感想としては、自分が業務で実施済の内容が、自分が参考にしたドキュメントと同じものを引用したうえでかなり紹介されており、自分の職場での動きが間違っていないのだという実感が得られました。同時に「分かってはいるが実践できていない」というケースもかなりの量があり、言い訳になってしまいますが人手が欲しいと切実に思います。具体的には ”サイバーセキュリティは経営課題である”という考えに元基づく「サイバーセキュリティ経営ガイドライン」については、パワポで説明資料を作成して取締役に読んでもらいました。進めるよう了承をもらいましたが、現在別の業務が忙しく手を付けられていません。 僕の会社もグループウェアやサービス提供にクラウドを利用しているので、今回の講習に書かれているクラウド利用における考慮が必要なセキュリティ対策は参考になります、というか既にいくつかは本講習で紹介されたドキュメントを参考に実践しています。ゼロトラストについては「ゼロトラスト移行のすゝめ」という、「ゼロトラストやりたいけど、何から手をつければいいの?」という僕らの悩みの参考になるPDFをIPAが公開してくれたので、こちらを読んで第一段階を完了させました。第二段階にも手を付けたいのだけど、今少し時間と予算をいただきたい(どこかで聞いたフレーズ) 他社のインシデント報告書を読んで他山の石とする、のも実践しています。半田病院の報告書を読んで、自社でも対応できていないリスクを発見し、情シスと連携して解消しました。ランサムウェア攻撃は具体的手法は分からなかったりするので、対策取るにも何をすればよいのか…となりがちです。不幸にもインシデントが発生してしまった企業には事例を積極的に公開してほしいです。では自分達もそれをやれるのか、と胸に手を当ててみる・・・。 ソフトウェア開発のセキュリティ対策は、フェーズが進むほど難しくなるため、コストを抑えるためにも企画・要件定義から参加するのも現在業務で対応中です。利用する暗号化アルゴリズムやアクセス制限の方法、監査用のログをどこで取得するかなどをプロジェクトの最初から入っておくことで、最後に突貫でセキュリティ対策するより楽です。しかしコーディングのセキュリティ対策までは、さすがにすべての言語を把握するのは無理なので、AWS CodeGuru RevierやGitHub Copilotのように、脆弱性あるコードをAIが見つけてくれるサービスを利用するのが良いだろう、と読んでいて思いました。便利な世の中になったものです。 CSIRTの構築については従前からずーっと目標として挙げているのですが、2年間手を付けられていない…。社内にCSIRTを組織し、CSIRT協議会に参加するところまで持っていくのが自分のやるべきミッションだと考えています。有言実行せねば。

AWS認定DevOps Engineer Professionalを取得しました!

先月のブログ更新がおろそかになっていたのは、ゴールデンウィークというのもあるのですが、表題の通りAWS認定資格の受験勉強をしていたからです。 そしてさる5/28に受験してきました。結果は1発合格です!どや。不合格でも無料でもう一回受験できるキャンペーンを利用していたのは内緒だ AWS認定DevOps Engineer Professionalとは何か https://aws.amazon.com/jp/certification/ AWSの資格は多種多様ですが、僕がこれまで取得してきた「ソリューションアーキテクト」がシステム設計に重きを置いたもの、「セキュリティ専門知識」が文字通りセキュリティの専門知識に重きを置いたものに対して、「DevOps」はシステムのプロビジョニング(デプロイ)、運用、管理に重きを置いたものになります。システム開発(Dev)と運用(Ope)が協調する開発手法は今や多くの企業で採用されています。AWSも対応しているサービスを多数提供しており、それらを使ってAWS上でDevOpsを実現できるスキルを保有していることを問うのがDevOps Engineer。Professionalと付いていることから分かるように上位資格になります。 なぜAWS 認定 DevOps エンジニア - プロフェッショナルを取得しようとしたのか ソリューションアーキテクトプロフェッショナルを保持している僕ですが(この資格も今年失効するんだよな…)、現在の会社で稼働しているAWSのシステムはずっと昔に作られたもの。EC2+RDSで作られたクラッシックなアーキテクチャです。しかしさすがに古いので、モダンアーキテクチャでリニューアルしよう、という機運が高まっていることは以前ブックレビューAWSで実現するモダンアプリケーション入門で説明した通り。既に他の人が脱EC2インスタンスを進めてくれているのですが、そうなると単にアーキテクトをモダンにするだけでなく、テストやデプロイについてもなるべく先進的なものとしたい、そのための知識を得なければ、というのが本試験の受験の理由となります。資格取得の理由は大きく分けて二つ「現在保有している知識とスキルを保証する」「その資格の取得を目指すことで知識とスキルを身に着ける」ですが、僕の場合セキュリティ専門知識は前者、ソリューションアーキテクトプロフェッショナルとDevOpsエンジニアプロフェッショナルは後者でした。...