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

世の中にあふれるチェックシート。僕もたくさんのチェックシートを作成し、利用しています。思いつくだけでも 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エンジニアプロフェッショナルは後者でした。...

SIMスワップ攻撃に注意するよう社内喚起しました

僕の会社での肩書が「セキュリティエバンジェリスト」和訳すれば「セキュリティ伝道師」ということで、社内にセキュリティを浸透、啓発するのがミッションです。 コンピュータ・インターネットなくして現代の仕事は成り立ちませんが、誰もが詳しい知識を持っているわけではありません。ことセキュリティに関して情報展開して会社のセキュリティレベルを高めることが大切と考えています。どんなに有用なソフトウェア、サービスを導入してもセキュリティの最前線は結局のところ人(攻撃者も、セキュリティリスクも)なので。 先日会社のグループウェアでSIMスワップ攻撃についてアナウンスしました。SIMスワップ攻撃(SIMスワップ詐欺、SIMハイジャックなどとも)とはアカウント乗っ取り攻撃の一種です。本人認証で使われていることも多いSMS(携帯電話番号)。電話番号は、SIMカードに紐づいていますが、何らかの形でターゲットに成りすまして自分のSIMカードと交換(スワップ)します。この攻撃が成立すれば、パスワードの初期化(パスワードを忘れた場合、SMSにパスワード初期化のURLが送られるシステムは少なくありません)ができてしまいます。そうすればやりたい放題ですよね。 SIMスワップ攻撃を使って友人のWebサイトをハッキングしてみた 上記記事のように事例自体は2021年には見られましたが、今月(2023年5月)には国内で初めて逮捕の事例が出るなど、国内でも徐々に広がってきています。 スマホ乗っ取る「SIMスワップ」詐欺か 他人装い出金容疑で女逮捕 警視庁 今回の記事のサムネイルは上記記事から引用しています。 このニュースは地元の新聞でも(新聞にすら、とも言えるかもしれません)報道されていました。いよいよ警戒が必要なのでは、と考え社内に展開しました。 例のごとく、いかに一般の人たちにセキュリティの記事を読んでもらうかを工夫しました。このブログでも書いた業務の中でも起こりうる情報漏洩については、当事者意識を持ってもらうために業務の中でも普通にやりそうな事例を実際にクラウド上のドキュメントファイルで体験してもらいましたが、今回は読んでもらうよう、気を引く文章を入れてみました。 「海外で発生した推理小説のような実例も併せて紹介しています、ぜひ読んでください」 この事例とは、セキュリティエンジニア御用達のインターネットラジオセキュリティのアレで紹介された以下の記事。 My phone, my credit...

【ブックレビュー】AWSの基本・仕組み・重要用語が全部わかる教科書

久しぶりの更新になります。今月末に受験する予定のAWS DevOpes Developers Professionalの最終追い込みをしていまして・・・いや、言い訳ですね。ゴールデンウィーク明けてもちゃんとWebラジオやブログ記事を更新している人たちを見ると、すごいという気持ちでいっぱいです。僕もまたギアを入れ直さないとです。 一応AWS Solution Architect Professionalを所有している僕ですが、今年が取得3年目なので更新が必要となります。 当時は100個を超えたところ、といったAWSのサービスは現在200ほどあるという。多すぎる・・・。そんな進化の早いAmazon Web Servicesを網羅した本が今年発売され、かなり好評だったのでこの度読んでみました。 まず手にとってわかる。分厚い!500ページ以上あります。2023年現在のAWSのサービスをすべて網羅しようというのですから、そうなりますよね。非とつい一つのサービスについても手を抜いておらず、知っていたサービスもより深く知ることができましたし、知らないサービスがたくさんありました。最近AWSは金融機関や医療機関など専門業種に特化したサービスもローンチしており、まず使わないであろうサービスもあり、それをすべて覚えることは資格取得に必須ではないと思います。 しかしこの本を読んで分かったのは、この本は単なるAWSサービスのカタログではないということ。現代のシステムアーキテクチャの主流であるマイクロサービスアーキテクチャやCA型/CP型/AP型のデータベースの特徴とメリデメ、CI/CD、コンテナなどの技術をきちんと説明したうえで、それがAWS内にどのように取り入れられているのかを丁寧に説明しています。渾身の一冊といってよいです。高評価なのも分かります。これからAWSを始める人にはもちろん、ある程度AWSは触っているけど最近の進化にはついていけてない人にも情報収集にぴったりな本です。 ただし技術の世界は習うより慣れよ。この本でAWSの各サービスについて知識を得たら、実際に自分のアカウントでいろいろ触ってみるとさらに理解が深まります。そのための書籍が手元にあるとなおよいでしょう。僕は10年以上前にAmazon Web...

ドッペルゲンガードメインにご注意を

「ドッペルゲンガードメイン」という言葉をご存じでしょうか。 「ドッペルゲンガー」とは自分とうり二つな分身、もう一人の自分、遭遇すると死ぬ、なんていう話しのネタもあります。 「ドッペルゲンガードメイン」とは、有名なドメインに似た(そっくりの)ドメイン名です。amazon.co.jpではなくanazon.co.jp、gmail.comではなくgmai.comなど。これらのドメインを使って詐欺を図ったり情報を窃取するセキュリティ攻撃のことを差します。 ちなみに、ChatGPTは「ドッペルゲンガードメイン」を理解していませんw 「Doppelganger(ドッペルゲンガー)」とは、ドイツ語で「二重身」を意味する言葉であり、人が自分自身の幽霊的または超常現象的な姿を見る現象を指します。「Domain(ドメイン)」とは、領土または支配領域を意味します。 ドッペルゲンガードメインの概念は、幻想文学やSF作品などで使用されるフィクションの一つであり、実際の歴史的な出来事や現象には根ざしていません。ドッペルゲンガードメインの概念は、歴史を通じて様々な文化の文学や神話で探求された二重性や、重なり合う自己像の概念に遡ることができます。 近年では、ドッペルゲンガードメインは、ビデオゲーム、小説、テレビ番組など、様々な形式のポピュラーメディアで使用されています。これらの作品では、ドッペルゲンガードメインは、同じ能力やスキルを持った自分自身の複製を作成することができる能力として描かれることが多いです。 ドッペルゲンガードメインは、フィクションの概念であるにもかかわらず、自己のアイデンティティ、自己発見、神格化の結果などのテーマを探求するためのプロットデバイスとしてよく使用されます。この概念は、複雑なテーマやアイデアを探求するために作家やクリエイターに独自の方法を提供する、ファンタジーやSFジャンルの中で人気のあるトロープであると言えます。 ドッペルゲンガードメインは古典的な攻撃手法です。フィッシング詐欺の場合サイトを構築する必要はありますが、特別な技術やソフトウェアの脆弱性を必要としません。メールを利用してのドッペルゲンガードメインについては、類似したドメインを購入してメールサーバーを立てるだけです。しかし攻撃手法は巧妙化しており、最近はもはや目視では見分けがつかないドッペルゲンガードメインが使われています。 見分けが不可能な偽サイトがGoogle検索最上位に堂々と表示されてしまう、「i」をURLに含む全てのサイトが信用できなくなる極悪手法 Googleの検索結果をもう一度確認してみると、表示されているURLは本物と同一の「https://www.gimp.org/」に見えます。同一URLなら同じサイトにアクセスできるはずですが、上述の通り、最上部のリンクをクリックすると偽サイトにアクセスしてしまいます。この現象が発生する理由について、Redditでは「URLに含まれるアルファベットの『i(アイ)』に見える文字が、実はキリル文字の『і(イー)』なのではないか」と指摘されています ヒューマンエラーに属するドッペルゲンガードメインですが、ヒューマンエラーが理由ゆえに防ぐことは容易ではありません。「気をつける」ではなんの対策にもなりません。前職では「メールを送る時には必ず連絡帳に登録されているメールアドレスをコピペし、手入力しない」などのルールがありましたが、はじめて送る相手のメールアドレスは連絡帳には入っていないこともあるでしょう。楽でかつ確実性がある対策が求められます。 ドッペルゲンガードメインへのメール送信遮断について 法政大学ではよく使うドメインに類似したドメインをフィルタリングすることでメール誤送信を防ぐ施策を取っています。利用者の対策は軽いですが、一方で次から次へと生まれるドッペルゲンガードメインを逐一登録するのはたいへんそうです。GoogleやMicrosoftなどメール機能を提供している会社が悪質なドメインリストを日々収集し、フィルタリングしてくれるとありがたいのですが・・・。 メール誤送信のリスクと対策 -ドッペルゲンガー・ドメインを踏まえて-...

【ブックレビュー】コンテナ物語

今日の記事はセキュリティやコンピュータの話とは異なります。しかし我々ITエンジニアの仕事に必需品となっているDockerコンテナの元の名前となった「コンテナ」に関する話なのでまったくの無関係ではありません(笑) ビル・ゲイツを始め多くの著名人が絶賛しているこの本。コンテナというとITエンジニアの人はDockerをはじめとしたコンテナ技術を連想すると思いますが、この本はその用語の元ネタ、物理的なコンテナにスポットを当てています。港のフェリーに積まれ、JRの貨物列車で運ばれている金属製の箱です。このコンテナがどれだけ世界を変えたのか、という話です。「輸送がどう変わったのか」では終わらない本です、というかそれで終わったらこんなに高評価の本にはならないでしょう。 コンテナのやっていることは単純明快です。頑丈な金属製の箱の中に荷物を入れる、それだけです。この本を読む前にコンテナのメリットを考えれてると良いでしょう。 僕が思いついたのは、「外からの衝撃に強く荷物を壊さず運べる」「寸法が共通企画になれば輸送の際”X型コンテナを○○個”というやり取りで荷物量を共有できる」「荷物を紛失したり盗難したりすることを防げる」などを思いつきました。しかしこの本はその僕の考え「コンテナの物理的メリット」がコンテナの本質ではないとを冒頭からあっさり否定します。「コンテナの価値はそのモノ自体にあるのではなく、その使われ方にある」と書かれています。どういうことでしょう? まず驚かされたのは現代のコンテナ船はただの輸送船ではなく、トラックさえ通り抜けできる巨大な”工場”であり、その中には少数の乗組員とコンピュータが十万トンを超える製品をベルトコンベア式に荷物の上げ下ろしを行っているということ。波止場の荷物運びは映画の中の存在になっています。無人化、機械化、大量輸送、いずれもコスト削減に寄与します。かつて港湾でかかる費用(荷物の上げ下ろしの作業員の給料、船の滞在費用、保険料などなど・・・)は重たいコストでした。港での労働環境は過酷で排他的、労使に信頼関係はなく殺伐としており最適化には程遠い状態でした。輸送プロセスにおける港湾利用の最適化ーコスト削減、盗難破損対策、時間短縮、処理容量の増加・・・・これらの課題を解決するアイディアこそがコンテナ。 そのアイディアは船を知らない門外漢により提供されました。”トラック野郎”輸送界の風雲児マルコム・パーセル・マクリーン。コンテナという考えは(筆者いわく審議は疑わしいということですが)マクリーンの「荷物を積んだトレーラーそのものを船に載せて運んでしまえばよいのでは?」という考えが発端でした。この考えはコストを根底とするもので、輸送プロセスの改善はあとから付いてくるものでしたが、この考えは革命的でした。なにせ港の非効率な作業をまるごと捨て去ることができるのですから。トレーラーから不要な車輪を取っ払い、”箱”による輸送が始まります。しかし本書にあるように、単に荷物を箱に詰めて輸送するだけであればそれほどのインパクトはありません。コンテナのすごいところは最初にも書いたように、個人の働き方が、地域インフラが、国の社会制度が、そして世界経済が、となにもかもが劇的に変化したことにあります。 マクリーンは終始コンテナの中心で常に先進的な活動を行いますが、それは単なる海運業のコスト削減にとどまらず、地域経済、国際ルール、言ってしまえば人の生活そのものを変えました。著者の持つ豊富なデータと幅広い取材から、コンテナの普及がどれだけ世界に影響を与えたのかを広範囲にわたり紹介している良著です。 コンテナの強みを政府に決定的に認識させたのは(よくある話ですが)戦争でした。ベトナム戦争でアメリカ本土からベトナムに物資を送るに当たり、人とコンテナ双方を積み込む混載船ではロジスティックスが機能しなかったのです。コンテナ用に改修されたベトナムの港は効率化を進めコストを削減。軍に「コンテナは単なる輸送手段ではなく、コンテナリゼーションはシステムである」と認識させます。冒頭に書いた『コンテナの使われ方』こそが本質。これはマイクロサービス化という概念を持つDockerコンテナでも共通です。 僕が生まれたのは静岡県清水市(現静岡市清水区)。僕が生まれる前の清水は港町として大変栄えていました。港には船が来て、岸沿いには多くの工場が立ち並び、清水港線という鉄道も通っていました。港湾労働者は力に自信あり。統制するには相応の力が必要だったのでしょう、清水次郎長がやっていたことはまさにそういうことでした。しかしそれも、コンテナが普及した今では過去の話です。荷物の上げ下ろしはリモート拠点で作業員が遠隔操作しています。それすらAIに置き換わりそうな予感があります。

会社内でのセキュリティ教育ー見えないが見えてしまう編ー

僕の会社での肩書が「セキュリティエバンジェリスト」和訳すれば「セキュリティ伝道師」ということで、社内にセキュリティを浸透、啓発するのがミッションです。 業務で使用するアプリケーション、例えばChromeやFirefoxのようなブラウザ、AdobeのようなPDFソフトなどのバージョンアップ情報やEmotetが活動を活発化させた注意喚起などを会社のグループウェアで行っています。本当はこういう情報は僕が発信しなくても能動的に知っていてほしいのですが、誰もがコンピュータリテラシーを持っているわけではないのです。僕が営業リテラシーを持っていないようにw 従業員にセキュリティに関心を持ってもらうためにはどういう情報を発信すればよいか、は悩んでいます。セキュリティインシデントはかつてないほど身近なものなのです。エン・ジャパンやドコモの情報漏洩・・・けして他人事に思えません。しかしこのブログでも紹介しているセキュリティに関する本を読んでくれ、とも言えませんし。 そこで、従業員が日常の業務で当たり前のように行っている作業にセキュリティリスクが存在することが分かるような記事を作成して公開しました。テーマは「恐怖!見えないものが見えてしまう」。 Google・Microsoft・Adobeなどの「トリミングツール」で切り取られた画像は簡単に元のデータを復元できるという指摘 上記の記事を参考にして、閲覧権限のみを設定したGoogleドキュメント上に、以下の画像の右半分をトリミングして貼り付けました。 この画像は無料写真素材ページ”写真AC”から拝借しました この画像をGoogleドキュメントにコピペして、別のGoogleドキュメントに張り付け、「画像をリセット」を選択すると左側が見えるようになり、修羅場であることが明らかになります(笑) ちなみに、Microsoft Wordには貼り付けた時点で元の画像が暴かれますし、Googleドキュメントだけの問題ではなく、Wordでも同様他のWordにコピペして画像の「トリミング」を選択すると元の画像が復元できてしまいます。 ちなみにこの話はドキュメント作成アプリケーションだけに留まりませんでした。 Google Pixel、加工前のスクリーンショットが復元できてしまう不具合 加工前画像が復元できてしまう不具合、WindowsのSnipping Toolでも...