2021/01/31

英国 国防省がAWSに言及しつつ、「パブリッククラウド」のメリットを説くブログを公表しました(転載)~個人的にIaaSの安全性の高さは問題ないと思うが、たまに起きる大規模障害(可用性の低下)が心配~


英国 国防省がAWSに言及しつつ、「パブリッククラウド」のメリットを説くブログを公表しました

英国の国防省(Ministry of Defence)より、「More secure in the public cloud(パブリッククラウドで、よりセキュアになる)」と題した公式ブログが公開されました。ブログ中、AWSにも具体的な言及があり、クラウド、特に「パブリッククラウド」と明示したかたちで、そのメリットが説かれています。

英国国防省の発表したブログ

(それでは以下、英文にて発表されたブログ”More secure in the public cloud“の全文を、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐(公共調達渉外担当)の小木郁夫の試訳にてお届けします:)

英国 国防デジタルサービス (Defence Digital Service* ; DDS) の責任者[Head of the DDS]である Rich Crowther *氏は、──国防省の所管する防衛分野であっても──、「OFFICIAL」に分類されたワークロードの安全性の確保に関しては、オンプレミスよりもパブリッククラウドの方がより適切に実施できると考えている理由について、次のように説明しています(訳注:過去にはより複雑な階梯構造を持っていた英国政府のdata classification は、OFFICIAL / SECRET / TOP SECRETの3階層に整理されています。また、文中の「*」の印は、訳出を担当した小木の判断でハイパーリンクを貼った箇所となります。印が無い箇所のハイパーリンクは、原文のリンクを踏襲しています。)

 英国 国防省では、「OFFICIAL」に分類された情報の取り扱いについて、パブリッククラウドの積極的な活用を開始しています。英国政府のデータ・クラシフィケーション・ポリシーで規定されているように 、この「OFFICIAL」という分類レベルには、高度な脅威プロファイルには該当しない日常的な業務およびサービスが含まれます。しかし直感的に、「他の組織や個人と共有するクラウドサービスが、軍事基地にあるデータセンターのそれと同等に安全だとは考えられない」と思う方もいることでしょう。 数年前に私自身(=Rich Crowther 氏)も、「OFFICIAL」レベルのワークロードをホストする上で”クラウドはオンプレミスのデータセンターと「まったく同等に」安全性を確保できる”と述べたことがありますが、今日であれば私は次のように言うでしょう: ほとんどの状況でクラウドはオンプレミスと比較してより高い安全性を確保できる、と。訳注:太字強調は原文を反映したもの)

 以下は、私がそう信じる 3 つの主な理由です。

#1: セキュリティパッチをより早く適用できる

 率直に言って、公的機関または民間企業であるかにかかわらず、多くの法人組織が技術的なインフラストラクチャを最新の状態に維持するために苦労しています。自社・自組織による運用であっても、サプライヤへのアウトソーシングであっても、オンプレミスのインフラストラクチャを最新の状態に維持することはとても困難です。オンプレミス環境で単一のウェブサイトを基盤とする技術構成を例として考えてみましょう:  これほどシンプルな例であっても、低レイヤーのハードウェア、オペレーティングシステム、ウェブサーバーソフトウェア、そしてウェブアプリケーションなどを動作させるハードウェア、ファームウェア、基本入出力システム (BIOS = Basic Input / Output System) が含まれます。システムの稼働開始時にこれらのレイヤーすべてに漏れなくパッチを適用したとしても、継続してパッチが適用され続けるということはその後、あるうるのでしょうか?  ハードウェア用の新しいバージョンの BIOS やファームウェアのリリースに、注意し続けることができるのでしょうか?  おそらく読者の皆さんは注意しておられるでしょうが、私の経験では、大半の人はリリースに気付くことすらありません。

 では、パッチの適用は、そもそもなぜ重要なのでしょうか?  セキュリティについて断定口調で話すのは気が進みませんが、これは例外としましょう: パッチの適用が遅れた場合、そのシステムは安全ではありません。 退屈しているいたずら好きなティーンエイジャーから特定の国家まで、すべての「脅威をもたらす輩」、つまりハッカーは、パッチが適用されていないシステムを攻撃する能力を持っています。オペレーティングシステム内のコンポーネント用に新しくリリースされたセキュリティパッチがリバースエンジニアリングされ、脆弱性が特定され、これを攻撃する手段が開発されるまでに、わずか数日しかかからないこともあります。こうした攻撃手段は、「脅威をもたらす輩」によって秘匿され続けることもあれば、逆に、時には世界中で人気のあるハッキングツールに追加され、ご丁寧にもその攻撃手法がYouTube のチュートリアルで説明されてしまうこともあります。パッチを適用するまでの時間が数日程度である組織なら、多くの場合、問題はないでしょう。ところが、パッチを適用するまでに数週間または数か月かかる組織は、おそらく無防備すぎるでしょう。

事例: ”投機的実行” (別名 ”Spectre[=幽霊]”)

 オンプレミス環境でのパッチ適用の速度と、主要なパブリッククラウドベンダーが 2018 年初頭の投機的実行=Spectre*(以下「スペクター」)の脆弱性に対応した速度を比較してみましょう(訳注:マイクロプロセッサに存在するハードウェアレベルの脆弱性であり、正当な権限のないプロセスが保護されたメモリの領域にアクセスすることが可能になる。 命名は、投機的実行 (speculative execution) に由来しており、修復が困難なことから、相当のあいだ幽霊のように我々に取り憑くだろうと説明されている – Wikipediaより)。スペクターは、プロセッサのハードウェアレベルに存在するまったく新しいクラスの脆弱性という点で、注目に値しました。この脆弱性は 2018 年 1 月 3 日に公開されました。一部の主要なクラウドプロバイダーは事前に[顧客に対してその脅威を]通知していましたが、おそらく期待されたよりも少なかったでしょう。ここ国防省では、世界のほとんどの地域と同様に、このニュースが報じられたときに初めてこれらの脆弱性について知りました。

比較のため、アマゾン ウェブ サービス (AWS) *の対応を見てみましょう。同社はおそらくこの脆弱性への対処に関してかなり迅速なスタートを切っており、脆弱性が公開されたその日に Amazon Linux 用の更新された仮想マシンイメージを利用可能にしました*。つまり、お客様が認識していれば、すぐに仮想マシン (AWS 用語*の「EC2 インスタンス*) を更新できたのです。翌日までに、パッチを自分で適用したかどうかに関係なく、すべてのお客様に対して、すべての EC2 インスタンスで脆弱性がグローバルに悪用されないように対応が終えられました。AWS の主力のひとつ、サーバーレスコンピューティング機能*である AWS Lambda* についても同じことが言えます。機能が安全な環境で実行されていることを確認するために、[顧客側では追加で]何もする必要はありませんでした。翌日、すべてのデータベースインスタンス*にもパッチが適用されました。このような基盤環境レベルの変更を高い信頼性で素早くロールアウトするには、[過去それらに要していた時間と比較し]  開発・テスト・監視がどれだけ必要であったかを考えると、これは驚くべき速さです。その後の数か月間、チップメーカーが、コンピューター上 (BIOS の下であっても) で実行される最低レベルのソフトウェアに適用するべきマイクロコードの更新を公開したため、さらにパッチを適用する必要があり生じました。AWS*または同水準の[パブリッククラウドに基づく]サービスを使用していた場合、これらはすべて、何も対処する必要はなく処理されました。

 私の経験では、英国では、ハイパースケールのクラウドプロバイダー*と同じくらい迅速にセキュリティパッチを適用できるレベルのエンジニアリング規模と専門知識を備えている組織は、ほとんどありません。ところが、スタックのすべてのレベルで迅速にパッチを適用しないと、システムは攻撃されやすくなるのです。

このことから何が分かるでしょうか?  クラウドサービスでは、仮想マシンだけに限定せず、より抽象度の高い「関数(Functions)」や「コンテナ」)を利用することをお勧めします。これは、システムへに対するパッチ適用を早め、攻撃に対する脆弱性が存在する時間を短縮することを意味します。

#2: 大規模なセキュリティコントロールのデプロイが容易である

 私(=Head of the DDSである Rich Crowther 氏)がパブリッククラウドのセキュリティを支持する 2 つ目の理由は、巨大な施設全体に対してもセキュリティ・コントロールを瞬時にデプロイするのが簡単であるからです。システムのすべてのエンドポイントにネットワーク監視タップをすぐに設ける必要がありますか?── 大丈夫です。インターネットに公開されているすべてのサーバーが、コンソールへのアクセスを世界中に公開していないことを確認する必要がありますか? ──とても簡単です。管理者のすべてのアクセスを変更できないログに記録し、無期限で保存する必要がありますか?── 了解しました。・・・こうした作業はすべてオンプレミス環境でも実行できますが、数時間、数日、いや数週間以上かかることもあります。これに対して、瞬時にクラウドで達成するのはとても簡単なことです。

 ただし、注意してください: セキュリティコントロールを大規模にデプロイできることの反面として、間違いも非常に迅速に拡散されてしまうことになります。 したがって、テンプレート*や構成コードを十分に確認することが重要です。そして、「職務の分離(separation of duties)*が組み込まれた優れた設計のワークフローを実装することにより、以下の3つめのメリットが享受可能になります:

#3: より簡単にすべてを承認し、「職務の分離」を実装できる

主要なクラウドサービスでは ID管理 と認可(authorisation)*に重点が置かれていることは、そこにインフラストラクチャをデプロイしようと試みた人なら誰でも知っています。ほとんどすべてのアクションを承認し、行われた承認決定の監査証跡を保持することが可能です。承認の決定ロジックでは、ユーザーが誰であるか、どこから接続しているかだけでなく、アクセスしようとしているリソースにメタデータを介して特定の属性が関連付けられているかどうかなど、さまざまなパラメータを組み込むことができます。──お分かりいただけたでしょうか。誰が何にアクセスできるか、そもそもアクセスしようと試みたのかを、細かくコントロールできるのです。

ただし、こうした基礎レベルの承認管理は当然のことと考えています。アーキテクチャによるコントロールがはるかに多くのことを達成可能にしたことが、クラウドが承認管理に関してより根本的な進歩を遂げるのに役立ちました。まず、必要になる直前にだけアクセスが許可される、いわば「ジャストインタイム」管理のような仕組みがあり、 Microsoftのような会社はAzureで easy な set upを可能にします。加えて、微妙な違いではありながら同様に重要なのは、壊滅的な侵害を引き起こすに足る、複数のユーザーアカウントのコントロール侵害が可能なシステムを、これまでよりも簡単に設計できてしまうということ──です。こうした事態を未然に防ぐための「職務の分離」によるコントロールは、旧来型のオンプレミス環境であったとしても技術的には実現可能でしたが、セットアップが難しく、運用には多大な費用がかかりました。現在は、パブリッククラウドを使用して、特権アクセスを取得したり、リスクを伴う操作を実行したりする場合には複数の人が連携しなければならないシステムを簡単に構築できます。これは大きな前進であり、防衛分野においてもこの種のコントロールをより広く活用できることを意味します。

「But what about…?(でも、こんな場合には?)

読者のなかには、こう思う方もいるかもしれません──「防衛やその他の公共部門の組織なら実施できるだろうが、営利団体/民間企業ではとても実施できない”特別なコントロール”があるという傾向を、あなたは無視しているんじゃないか」──と。たしかに、たとえば明白な例として、高度な物理的セキュリティや人的セキュリティの身元調査を、防衛部門では実施することもあります。でも、誤解しないでください。これらは、軍事作戦を実行するために利用される高度に機密性の高い情報を扱うシステムなど、一部のシステムを保護するうえで非常に重要なコントロールなのです。とはいえ、ハイパースケールのクラウドプロバイダーが物理的および人的セキュリティにこれまで投入してきたオペレーションのレベルを、過小評価しないでください。たとえば、(ハイパースケール・クラウドプロバイダー各社の)規模が大きいゆえに実装可能となる「職務の分離」によるコントロールにおいては、多くの場合、壊れたディスクを交換するためにデータセンターにアクセスできるスタッフは、特定の顧客からのデータが含まれているディスクを特定できるスタッフとは、異なる人物であることを意味します。これは、オンプレミスで運用されるほとんどの「OFFICIAL」に分類されるワークロードでは、決して実現できない強力なコントロールのひとつです。

ただし、より機密性の高い (通常はSECRETおよびTOP SECRETに分類される) 情報を扱うシステムの周囲には、非常に厳格な人員および物理的コントロールを必要とするシステムが必ず存在しますAWS訳注:SECRET / TOP SECRETは、前掲の英国政府のデータ・クラシフィケーション・ポリシー*で規定されている3類型のうち、残りの2類型です)。こうしたシステムでは、防御態勢の一部として適切にパッチが適用されていることが重要であり、パッチを適用する作業を組織自身で、または緊密に連携する業界パートナーと共に行う必要があります。ただし、「OFFICIAL」分類相当のワークロードに対してはパブリッククラウドサービスをさらに活用し、つまりはクラウドプロバイダー[の提供する個々のサービス]に従来は手間がかかっていた作業のほとんどを任せることで、より高度な機密を扱うシステムへのパッチ適用の速度を上げるためのエンジニアリング的取り組みに、さらに戦略資源を[国防省は]集中することができます。

 

防衛分野へのパブリッククラウド適用

国防省のデジタルやテクノロジーの分野において、Defence Digital*の 「MODCloud*」 チームの同僚は、誰でも簡単に利用できる主要なハイパースケールのクラウドサービスのいくつかを提供しています。MODCloud チームは、さまざまな「ガードレール」と「テンプレート」を提供して、すべてのアカウントで一貫したセキュリティコントロールを確実に実施できるようにしています。(英国 国防省の)私のチームはこうしたサービスを使用してさまざまなデータセットを正常に処理し、上記の[ブログで紹介してきた]すべての手法も使用しています。高レベルの抽象化サービスを使用して、パッチ適用が主にクラウドプロバイダーによって行われるようにし、すべてのインフラストラクチャをコードからデプロイし、主要な設計要件として「職務の分離」を実現するようにシステムを設計しています。これらはすべて、Cyber Defence & Riskチームに所属する仲間や MODCloud チームとの緊密な連携で行っています。私たちは全員が一緒に学び、継続的に改善を行っています。

この投稿が、国防省の他のチームが「OFFICIAL」に分類されるワークロード (”SENSITIVE caveat*“という取り扱い条件が付された情報も含めて) に MODCloud を通じて提供されるパブリッククラウドサービスを採用することを促進し、”機密扱いの情報を取り扱うシステムの改善” 及び “セキュリティ保護”に対して、集団安全保障業務とエンジニアリングのリソースをさらに集中させていく目標達成に役立つことを願っています。

最後に、このブログの締め括りとして、NCSC (英国 The National Cyber Security Centre*)は優れたクラウドサービスのセキュリティ上の利点に関する詳細なホワイトペーパーを公開しています。このホワイトペーパーでは、さらに必要な場合に、クラウドがセキュリティを向上させる可能性についてさらに多くの議論を示しています。

2021/01/30

セキュリティ担当者はつらいよ 組織間で発生するギャップにどう立ち向かうか(転載)

cover_news015.jpg


 本連載は、組織のセキュリティ体制を整えてきた筆者の経験から「セキュリティにおいて大切なもの」「セキュリティで起きがちな課題」「安全な組織とは」などをさまざまな切り口で考察するものだ。

 しばらく間が空いてしまったため、前回のおさらいから始めよう。前回の最後でサイバー攻撃に対応する関係者は、組織階層により目的や考え方、求められるミッションが異なるため、折り合いをつけることが困難な場合があるという話をした。

 こうした立場による認識相違は組織階層に限った話ではない。第2回は、セキュリティシステムを利用するユーザー側とサービスを提供するベンダーの開発部門、さらにベンダーの運用部門の立場から、サイバー攻撃を防いだ後に発生する可能性がある「認識相違」について説明する。分かりやすくするため事例は「あえて極端な例」を挙げていることに留意してほしい。

想定通りにインシデントを未然に防いでいるのに…… なぜ「立場による認識相違」が発生するのか


 多層防御やゼロトラストモデルなど被害を予防するセキュリティ対策によって、想定通りにサイバー攻撃を防御をしても、システム担当部門やCSIRT担当者にとって頭を抱えるケースがある。

 今回の例は、Webサイトに悪意のあるファイルアップロード攻撃が実行されて、それをセキュリティシステムがブロックしたケースを想定する。Webサイトは、簡略化しているが「分散型サービス妨害(DDoS)攻撃」「ファイアウォール(FW)やIPS(不正侵入防止システム)、Web Application Firewall(WAF)」「サーバ自身のマルウェア対策」などの多層防御を実装しているものとする。サイバー攻撃に対する階層ごとの挙動は以下だ。

  1. DDoS対策:しきい値の超過などの異常がなく通過
  2. FWなどの対策:通常アクセスとみなされ通過
  3. マルウェア対策:不審なファイルのため駆除
 今回のようなWebサイトにサイバー攻撃を受けた場合、マルウェア駆除検知がトリガーとなり、Webサイトの運用部門から開発部門のシステム担当に連絡が入る。システム担当は「サイバー攻撃を本当に防御できたかどうか」「他のシステムに攻撃を受けてないか」などの調査と並行し、自社の上席やユーザーである顧客にサイバー攻撃を受けた旨や対応方法について報告する、という流れが一般的だ。

 現場のシステム担当からすれば、Webサイトのセキュリティ対策は想定通りに動いたため「大きな問題は発生しなかった」と考えるだろう。一方でサービス提供ベンダーの経営層やユーザーはどのように考えるだろうか。極端だがそれぞれの立場におけるサイバー攻撃の対処への反応を下図にまとめた。


 現場のシステム担当者は、運用ルールに従ってユーザーに連絡しても「(想定通り機能したのであれば)夜中に電話をするな!」と怒られて、自社の経営層からは、リリース以前に報告していた通りの対策であるにもかかわらず「(多層防御のうち何枚かは破られているため)新たな対策を追加せよ!」や「攻撃を受けること自体を防げ!」など厳しい注文を受けることもあるだろう。そしてそのしわ寄せは、末端に位置するシステム運用部門に集まることも多い。読者の中には、立場にもよるが同様の経験をしている人も少なからず存在するのではないだろうか。

考え方は立場や企業に応じて異なる 分かり合えないならせめて


 先に挙げた例での立場による見解の違いは、費用や契約の問題から生じることが多い。根本的な問題のため、関係者全員が納得するのは難しいかもしれない。

 システム担当者は、自社の経営層の意見については経営としての高度な視点と真摯(しんし)に受け止めて、この事態を糧に運用部門と協力して運用の実態を踏まえた上で適正コストを見積もるなどいい意味での「鈍感さ」を持つべきだろう。

 ユーザーに対しては次なる対策を提案する契機と捉え、今回のサイバー攻撃が不成立であっても今後は成立する可能性があるとして、インシデントの発生を想定したアドバイスを提言してもよい。プロとしてふるまい、ユーザーのさらなる信頼を勝ち取るように努めるべきだろう。



2021/01/29

2020年下半期に公開されたセキュリティ関連文書まとめ(転載)



2020年下半期に公開されたセキュリティ関連文書まとめ

政府機関

高度情報通信ネットワーク社会推進戦略本部(IT総合戦略本部)

文書タイトル公開日
デジタル・ガバメント実行計画2020/12/25

セキュリティ関連団体

JNSA

文書タイトル公開日
電子署名Q&A2020/09/16
中小企業において目指すSecurity By Design2020/11/05

 


「情報セキュリティ10大脅威 2021」を決定(転載)


「情報セキュリティ10大脅威 2021」を決定:

IPAは情報セキュリティ対策の普及を目的として2006年から、前年に発生した情報セキュリティ事故や攻撃の状況等から脅威を選出し、上位10位を公表しています。本日公表した「情報セキュリティ10大脅威2021」は、IPAが2020年に発生した脅威候補を選定し、情報セキュリティ分野の研究者、企業の実務担当者など約160名のメンバーで構成する「10大脅威選考会」の投票を経て決定したものです。

個人の順位では、昨年に引き続き、「スマホ決済の不正利用」が1位となりました。スマホ決済サービスを悪用して他人の銀行口座から残高をチャージ(他人の口座からの金銭窃取)する事案などが引き続き発生しています。スマホ決済サービスの利用者は、二要素認証を利用するなどの不正ログイン対策の実施や、被害を受けた際に早期に気付くことができるように、スマホ決済サービスの利用状況を確認することが重要です。また、スマホ決済サービスの利用者以外でも、スマホ決済サービスと連携可能な銀行口座を持つ人は被害に遭う場合もあるため、口座からの出金履歴を適宜確認するといった心構えが重要です。

組織の順位では、「ランサムウェアによる被害」が1位となりました。昨年8月にIPAは、ランサムウェアを用いた新たな攻撃の手口として「人手によるランサムウェア攻撃」と「二重の脅迫」について注意喚起を行いました。従来はウイルスメールをばらまくなどの方法で広く無差別に攻撃が行われていましたが、新たな攻撃者は、明確に標的を企業・組織に定めています。標的型攻撃と同様の手法で企業・組織のネットワークに侵入したり、データを暗号化するだけでなく窃取して公開すると脅したりして、身代金を支払わざるを得ないような状況を作り出します。昨年は国内企業への攻撃も報道され、大きな話題となりました。新たなランサムウェア攻撃は、標的型攻撃と同等の技術が駆使されるため、例えば、ウイルス対策、不正アクセス対策、脆弱性対策など、基本的な対策を、確実かつ多層的に適用することが重要です。

また、「テレワーク等のニューノーマルな働き方を狙った攻撃」が初登場で3位となりました。昨年は新型コロナウイルス感染症の世界的な蔓延に伴い、感染症対策の一環として政府機関からテレワークが推奨されました。テレワークへの移行に伴い、自宅などからVPN経由で社内システムにアクセスしたり、Web会議サービスを利用したりする機会が増えました。また、私物PCや自宅ネットワークの利用や、初めて使うソフトウェアの導入など、以前までは緊急用として使っていた仕組みを恒常的に使う必要性がでてきました。こうした業務環境の急激な変化を狙った攻撃が懸念されています。基本的な対策のほか、テレワークの規定や運用ルールの整備、セキュリティ教育の実施などが重要です。

2021/01/28

【2021年1月】株主優待戦略を考える(権利付き最終日:2021年1月27日 )


2020年1月の株主優待戦略を考える。

自分にとってはJALマイルの獲得が行動の源泉となっているため、プレミアム優待倶楽部の中から対象を絞り込んでいくこととなる。

優待取りで株式を取得して損失を出してしまっては元も子もないので、まずは下記のポイントで絞り込みを実施

①プレミアム優待倶楽部の9月権利確定企業の一覧を確認
 ⇒継続保有条件ありやポイント付与終了の企業は脱落

②証券会社のWebサイトにアクセスし、空売りが可能かを確認
 ⇒空売りできない銘柄は脱落

株主優待情報サイトにアクセスし、最も効率の良い投資対象を選定

上記の絞り込みの結果、なんと今回は条件を満たす企業がなかった。

それで終わりにするのは少しもったいないので、前回12月の優待取りの際の改善を検討してみる。

両建てで優待取りを行う場合、理屈上はプラスマイナスゼロとなるが、実際は取引手数料だったり貸株料だったりで細かいマイナスになっている。

なので、これらも含めて株主優待を取りつつも多少なりとも利益もとれるような両建てを検討してみたい。

何もネタがないと議論のしようもないため、1月に優待取りが可能で、且つ両建ても可能な鳥貴族(3193)をベースにいろいろ試行錯誤を重ねたいと思う。

1年前の振り返りとなるが、2020年1月の優待取りについては権利落ち日が1/29であった。

となると、前日の2020/1/28の株価で判断することとなるので、当時の情報を集めてみる。

【2020/1/28 鳥貴族(3193)
始値:2551
高値:2595
安値:2549
終値:2588

日足ATR:62
30分足ATR:13

※いずれのATRもローソク足20本分としている

基本的に優待取りなので、必ず約定させる必要が出てくる。

しかし成行だと始値で約定してしまい、指値だと刺さらないリスクが出てくる。

そこで、「不成」という、指値で刺さらない場合は前場の終値で成り行き注文に変更するという注文方法を取ってみる。

この方法でポイントとなるのが30分足のATRと踏んでいる。

仕掛けだが、前日終値と30分足のATRを使い、下記のように試算してみる。

【2020/1/29 鳥貴族(3193)仕掛け案
ロング:2575円以下で約定(終値2588-13(30分ATR))
ショート:2601円以上で約定
(終値2588+13(30分ATR))
※約定できない場合は前場終値で成行注文

さて、結果はどうであっただろうか?

Trading Viewの30分足でシミュレーションしてみる。。。。

【2020/1/29 鳥貴族(3193)結果
ロング:2575円 ※指値で刺さる
ショート:2496円 ※指値刺さらず、前場終値の成行注文で約定

ちなみに、1/29の結果は下記である。

【2020/1/29 鳥貴族(3193)
始値:2581
高値:2588
安値:2476
終値:2476

前場終値:2496
30分足ATR:18

つまり、持っているポジションは下記の状況となる

ロング:2575円(▲99)
ショート:2496円(20) 

で、手仕舞いに向けてどう考えるか。

ルールを仮で作ってみる。

【仮ルール】
・目標価格を約定金額±1ATRで設定
・すでに2ATR以上利益が出ている場合は成行

で、このルールに乗っ取って、手仕舞案を考える

【2020/1/30 鳥貴族(3193)手仕舞案
ロング:2593円以上で約定(約定価格2575+18(30分ATR))
ショート:2478円以下で約定
(終値2496-18(30分ATR))
※約定できない場合は前場終値で成行注文

改めてTrading Viewの30分足でシミュレーションしてみる。。。。

【2020/1/30 鳥貴族(3193)結果
ロング:2593円(18) ※指値で刺さる
ショート:2478円(18) ※指値刺さる

ロングとショートでそれぞれ100株ずつ仕掛けた場合、1800*2で3600円程度の利益が生まれる。

ほんまかいなって気がしなくもないが、2020年の結果を踏まえるとこういう結果となる。

実はロスカットラインも設定してシミュレーションしてみたのだが、今回の場合はロスカットラインを設定することでかえって損失が大きくなってしまった。

ロスカットラインの設定をしないと小次郎講師に怒られそうだが、今回の場合前場で手仕舞ってしまうため、ある意味価格ではなく時間によるロスカットラインを引いているとも言えなくもない。

しばらくトライアンドエラーで両建ての塩梅を探ってみることとする。

【1/26】
ついに明日は権利落ち日。

下記で仕掛けをしてみる。結果はまた明日。。。


【1/28】
手仕舞完了。

結果は散々たるものだった。

まず、下記が結果、12月同様、3万円近くも損失を出してしまった。


・反省点①:
成り行き注文はアブナイ

鳥貴族(3193)の前日終値が1505円、約定価格1482円で23円の含み益があったため、成行で約定注文を出した。

ところが、翌日窓が開いて、始値が1475円となり、成行注文をしたがために7円のマイナスとなってしまった。
↑鳥貴族(3193)の30分足

[教訓]前日終値ベースで含み益が出ていても、成行注文で利益確定を図るのは危険


・反省点②:ロスカットラインは設定すべきか

チャートを見れば一目瞭然なのだが、チャートは完全に右肩上がりである。

この状況でトレンドと逆方向に仕掛けてロスカットラインを設定しなかったのはやはりリスクが高かった(それでも不成注文で多少ヘッジできたが‥‥)

ロスカットラインは利確チャンスを削ぐリスクがあるため、すごく悩ましい。。。。

ロスカットラインは引き続き検討するにしても、成行注文で利確を図る行為はやめよう。。。
Posted in  on 1月 28, 2021 by B-SON |  

日産北米法人のアプリなどのソースコードが流出 / Nissan Source Code Compromised Online Due to Exposed Git Server(転載)~クラウドサービスの利用において、アクセス権設定は肝中の肝であることを改めて認識させられる~


公開されたGitサーバーにより、日産ソースコードがオンラインで侵害されました:
 

日産自動車のソースコードがオンライン上で漏洩したのは、同社がデフォルトのアクセス資格情報で保護されたGitサーバーを公開したままにしていたためだ。このリークは、スイスに拠点を置くソフトウェアエンジニアのティリー・コトマン氏がZDNetとのインタビューで明らかにしたもので、彼女は未知のソースからリークを発見し、同社のデータを分析したという。

ソースコードリポジトリには、「日産のモバイルアプリのソースコード、日産ASIST診断ツールのコンポーネント、ディーラーのビジネスシステムとディーラーポータル、同社の社内コアモバイルライブラリ、車両物流ポータル、市場調査ツール、データ、顧客獲得とリテンションツール、車両接続サービス、複数のバックエンドと社内ツールに関する重要な情報」が含まれていたという。

データが暴露され、トレントリンクやハッキングプラットフォームを介してテレグラム上で共有され始めた後、同社は昨日、Gitサーバーをシャットダウンするという予防措置を取った。メルセデス・ベンツも2020年5月、スイスのサイバーセキュリティ専門家が、同社がGitLabサーバーを誤って設定し、複数のメルセデス・ベンツのアプリやツールのソースコードを流出させていたことを発見した際に、データ流出の被害に遭っていた。

日産の広報担当者は事件を認め、さらに「日産は、会社の専有ソースコードへの不適切なアクセスについて、直ちに調査を実施しました。我々はこの件を重く受け止め、今回のセキュリティインシデントで消費者、販売店、従業員の個人データにアクセスできなかったことを確信しています」と述べています。影響を受けたシステムは安全に保護されており、公開されたソースコードに含まれる情報が消費者や車両を危険にさらすことはないと確信しています」。

攻撃者はGitLab上の同社の公開リポジトリに手を出すことができたが、そこにはトヨタ、サンテック、ペプシ、モトローラ、メディアテック、シエラネバダコーポレーション、米空軍研究所などの大手企業の機密情報を含むフォルダが含まれているが、幸いにもすべてのフォルダには攻撃者を安全な資産に誘導するような機密情報は含まれていないという。

2021/01/27

IPA、セキュリティ等について充実を図った「情報システム・モデル取引・契約書」 第二版を公開(転載)

000087499.png

セキュリティ等について充実を図った「情報システム・モデル取引・契約書」 第二版を公開:

背景

デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタルトランスフォーメーション(DX)」が注目を集めています。経済産業省が2018年9月に公開した「DXレポート」は、DXを円滑に進めるには、ユーザ企業、ITベンダが双方の間で新たな関係を構築していく必要があると提言しています。そのために、DXの進展によるユーザ企業とITベンダのそれぞれの役割の変化等を踏まえたモデル契約の見直しの必要性が指摘されました。モデル契約は、情報システム開発における各局面の取引構造を透明化するためのツールであり、その普及により、ITベンダの産業構造転換、情報システムの信頼性向上、ユーザ・ベンダ一体となった生産性向上の促進が期待されます。

こうした状況を踏まえ、IPAでは、経済産業省が2007年に公開した「情報システム・モデル取引・契約書」、およびIPAが2011年に公開した「非ウォーターフォール型開発用モデル契約書」についての見直しの検討を2019年5月から2020年12月にかけて行いました。この検討では、全体を取りまとめる「モデル取引・契約書見直し検討部会」を設置し、民法改正に対応した「情報システム・モデル取引・契約書」の見直しについては、同部会の下で、ユーザ企業、ITベンダおよび法律専門家から成る「民法改正対応モデル契約見直し検討WG」において検討しました。

同WGでは、2019年度検討の成果として、2020年4月に施行された改正民法に直接関係する論点を見直した 「情報システム・モデル取引・契約書」の民法改正を踏まえた見直し整理反映版 (以下、「民法改正整理反映版」)を、2019年12月に公開しました。その後、民法改正に直接かかわらないものの、2007年のモデル契約の公表以降の情勢変化に応じて見直した方がよいと考えられる論点(後述)について検討しました。なお、論点の一つであるセキュリティに関連する検討については、セキュリティ専門家の意見を求めるため、2019年7月から同WGの配下に「セキュリティ検討PT」を設置して検討しました。

概要

IPAはこれまでの検討を取りまとめ、「民法改正整理反映版」に民法改正に直接かかわらない論点の見直しを加えた「情報システム・モデル取引・契約書」第二版(以下、「第二版」)を、2020年12月22日に公開しました。また、「第二版」から参照されるセキュリティ基準等公表情報の一例として「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」と「セキュリティ仕様策定プロセス」(以下、「セキュリティ仕様関連文書」)を同時に公開しました。

「第二版」は、ユーザ企業、ITベンダ、関連業界団体、および法律専門家の参画を得て議論を重ね、中立的な立場でユーザ企業・ITベンダいずれかにメリットが偏らない契約書作成を目指しているところが特長です。後述のように、民法改正に直接かかわらない論点について、現行のモデル契約条項と解説の修正版、および見直しについての解説を整理しています。

「セキュリティ仕様関連文書」は、セキュリティ専門家、一般社団法人コンピュータソフトウェア協会(CSAJ) Software ISAC等のセキュリティ関連団体の参画を得て議論を重ね、また広く意見募集も行って 、「第二版」から参照されるセキュリティ基準等公表情報の一例として、Windows Active Directory環境用の文書が作成されました。

IPAはユーザ企業・ITベンダ双方が「第二版」を参照することで、契約のタイミングで双方がシステムの仕様やプロジェクト管理方法、検収方法等について、共通理解のもと対話を深め、よりよい関係のもとITシステム開発が行われることを期待しています。

見直しのポイント

  • 民法改正に直接かかわらない5つの論点

論点概要見直しの対象
見直しの観点・内容
(1) セキュリティ近年重要性を増しているセキュリティに関して、システム開発の段階においてユーザとベンダがリスクやそれに対応するためのコストについての共通理解をした上で、適切な責任分界点を設定するためのプロセス及び契約条項上の手当をモデル契約で提案できないか。条項
解説
関連文書
ユーザとベンダとは、それぞれの立場に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより、システムに実装する「セキュリティ仕様」を決めることが必要である。その観点から以下の見直しを行った。
  • 条項の見直し(定義条項、責任者条項、セキュリティ条項)
  • セキュリティに関するプロセスに関する解説の加筆
  • セキュリティ検討PTによる「セキュリティ仕様関連文書」の策定
(2) プロジェクトマネジメント義務及び協力義務近年特に問題となっている、ベンダのプロジェクトマネジメント義務及びユーザの協力義務について、モデル契約上の手当てによって、紛争の予防に資することはできないか。また、それぞれの義務について裁判例を踏まえて一定の整理ができないか。条項
解説
裁判例で示されたプロジェクトマネジメントや協力義務は、それぞれ個別事案における判断であり、汎用性の高いモデル契約の中にこれらの義務を規定することは難しいことから、条項の形で追記することは見送り、以下のような見直しを行った。
  • 新たな裁判例を当該事案に関連する箇所における紹介
  • ユーザ及びベンダの役割分担・プロジェクトマネジメントに関する記述の見直し
  • マルチベンダ形式における用語法の修正
  • ベンダの中止提言を踏まえた解約権のオプション条項としての追加
(3)契約における「重大な過失」の明確化従前のモデル契約においては、「重大な過失」の有無が損害賠償の責任制限条項の適用の分水嶺となっており、また、昨年12月に公表した民法改正に対応した見直しによって、ソフトウェア開発業務等の請負型の業務における契約不適合責任においても、「重大な過失」の有無が客観的起算点による期間制限の適用の分水嶺となった。この「重大な過失」について、ベンダ側の予測可能性の担保の観点からより明確化することはできないか。解説
契約条項として重過失については特段の定義をすることはせず、重過失概念に関する一般的な理解とシステム開発に関する裁判例のうち重過失についての判例を逐条解説に追記することで、重過失を考える上での手がかりを提供する。
(4)システム開発における複数契約の関係多段階契約においては、しばしば下流工程でトラブルが生じた際にユーザが上流工程まで遡って解除に基づく代金返還請求をしたり、損害賠償責任を追及するという紛争が頻発しているが、そのような紛争の予防・解決のためにモデル契約上何らかの手当ができないか。解説
複数の個別契約がどのような処理になるのかは、個別契約の関係や問題となった債務不履行次第であることから、契約条項として手当するのではなく、裁判例を整理して得られた共通理解を解除条項の逐条解説に追記し、利用者の理解に資する。
(5)再構築対応現行のモデル契約はスクラッチ型の新規開発を念頭においたものであるが、デジタルトランスフォーメーションの実行に向けた既存システムの再構築をも念頭に置いたものになるような見直しが必要ではないか。解説
要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要があるが、現行システム調査には、専門的な技術も必要で、コストと時間を要する。現在動作している通りのシステムを再構築するだけ(現行踏襲)と考えるユーザにはこの意識が薄い。ITシステム部門向けには再構築に関するガイドブック類が公表されているものの、業務マネジメント層や契約に関わる部署に向けたものは少なく、モデル取引・契約書の中で注意喚起する。

  • セキュリティ仕様書の作成プロセス

「第二版」では、セキュリティ仕様書の作成プロセスを明確化し、その内容を解説に記載するとともに、そのプロセスを前提とする契約書の条項を整理しました。

セキュリティに関しては、公的機関や業界団体、セキュリティ関連企業等が提供する、脅威分析を行い攻撃への影響と対策(緩和策)等を検討するための参照情報(ここでは「セキュリティ基準等公表情報」と総称)を使用して、ユーザとベンダが以下のような協力をすることにより、セキュリティ仕様書を作成します。

  • 必要な情報を相互に出し合う。
  • セキュリティ基準等公表情報を参照し、セキュリティの脅威を把握する。
  • 開発対象のシステムについて考慮しつつ、脅威の影響についてリスク評価を行う。
  • 対策の実装有無を決定・合意し、その結果をセキュリティ仕様書に反映する。

対策を実装しない場合にも、その旨を記録することが重要です。そのため、システム開発の各段階において、ユーザおよびベンダのそれぞれが提供すべき情報や検討すべき事項は何か、各段階の成果物は何か、どの段階でセキュリティ仕様を確定するのか等について整理します。

このようなプロセスにおいて参照するセキュリティ基準等公表情報の一例として、今回、「情報システム開発契約のセキュリティ仕様作成のためのガイドライン ~Windows Active Directory編~」を作成しました。また、対応するプロセスについて、「セキュリティ仕様策定プロセス~「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応~」に整理しました。

  • システム再構築における企画プロセス

長年運用・保守を続けてきたシステムを再構築する場合、現行システムに関する業務知識(ドキュメントと有識者)が失われていることが多く見られます。そのため、現行システムの状態を正しく認識した上で再構築の方針を決め、実行計画を立てることが肝要です。システム再構築におけるこのような課題と、特に企画段階のプロセスについて、「第二版」では次のような解説を追加しました。

再構築の流れとしては、まず、企画段階・システム化の方向性フェーズにおいて、再構築の目的・要求事項や現行システムの状況から最適な再構築手法を選択しリスクを洗い出します。次に、企画段階・システム化計画フェーズにおいて、選択した手法とそのリスクをもとにリスクの予防策を検討します。

ユーザは、必要に応じて、ベンダとの間で、これらの支援業務(後のシステム開発契約の範囲外)を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになります。

このようなシステム開発プロセスにおける再構築特有の検討の位置づけは、下図の通りとなります。


  • 追補版について

今回、追補版については、時間の関係で、第一版の見直し内容がそのまま妥当する範囲で見直しを行うにとどめております。追補版については、必要に応じて セキュリティ関連のみならず、主に利用者として想定される中小企業にとってより適切なモデル取引・契約書の在り方を含め,現状の取引状況等に関する関係者の意見を踏まえた検討が期待されます。

バックアップ


2021/01/26

さらばSolaris~2035年頃に歴史の幕を閉じるか!?~


SolarisというUNIXオペレーティングシステムがある。

20年位前までは企業のシステムの多くでSolarisが稼働しており、自分が最初に入った会社でも大量のSolarisが稼働していた。

今はOracleという阿漕な会社のものとなっているが、もともとはサン・マイクロシステムズという会社が開発し販売していた。

今はIntel製CPUがメジャーだが、Solarisは当時SPARCプロセッサで稼働しており、どうしても手元に環境が欲しくてSPARCプロセッサ搭載のデスクトップマシンを個人で持っていた時期もある。

そんでもって、Solarisのベンダー資格なんかもいくつか取得していたりした。

その後、Intel CPUで稼働するx86版Solarisがリリースされ、その辺のPCでもSolarisを入れることができるようになった。

当時Linuxはオープンソースでサポートがないことから、エンタープライズシステムには不向きとされ、Windowsはシステムそのものの安定性が全くなく(当時は1か月も連続稼働させるとフリーズする程度の酷さだった)、システムの安定性が高くてしっかりとメーカーサポートが受けられるSolarisは今後もエンタープライズシステムの中核であり続けると思っていた。

ところが、結果は想像と大きく異なり、Linuxはエンタープライズ用途に耐えられるようなサポートサービスが充実し始め、Windowsもバージョンアップのたびにシステムの可用性や堅牢性が向上し、しかもどちらも安価ときたもので、Solarisのシェアがどんどん縮小していった。

挙句の果てにオラクル社にサン・マイクロシステムズ社が買収され、雲行きがさらに怪しくなる。

実はここ5~6年くらい、Solarisに関わることがなかったのだが、先日ふとSolarisをリプレースするという案件に出くわし、久しぶりに現状を調べてみた。

そうすると、いろいろ残念な情報が出てきた。

まず、Solaris開発の大半の社員は2017年9月に解雇されているらしい。

そして、Solarisは11が最後のバージョンとなるらしい。

下記がSolarisのEOSLの表だが、Solaris11が最終バージョンとなると、EOSLは2035年となり、この辺でSolarisの歴史に幕を閉じることとなる。


自分は結構Solarisに入れあげていた半面、オラクル買収後は完全に熱が冷めるとともに、特定のプロダクトに対する熱い思い入れは持たないようにすることにしている。

Posted in  on 1月 26, 2021 by B-SON |  

2021/01/25

IPA、国内・欧米・中国のIT関連制度政策動向レポートを公開(転載)


国内・欧米・中国のIT関連制度政策動向レポートの公開:

国内・欧米・中国のIT関連制度政策動向レポート

IPAはAI白書、情報セキュリティ白書等にて、それぞれに関係するIT関連技術の最新動向や、各国政府による研究開発の促進策、社会実装のための制度改革及び社会への実装の推進政策を紹介しています。

IT関連技術は、社会への実装という観点からは様々な分野に適用されており、関連する各国の制度政策状況についても個別分野だけでなく、全体を俯瞰した動きにも注目する必要が出てきています。各国の技術政策に関しては、大きな目標を立てた上で、個別の技術分野の制度に割り付けている例も多くみられるため、各国の技術政策を俯瞰的に把握した上で、各分野の動向の把握していくことは、それぞれの分野にとっても有用であると思われます。

そこで、IPAは、国内外のIT関連先進技術の研究開発の推進、社会実装に係る制度、政策動向の調査を行い、動向を取りまとめました。その内容を速やかに提供するため、このたび調査レポートとして公開します。


2021/01/24

2021年版 私のセキュリティ情報収集法を整理してみた(転載)


 私のセキュリティ情報収集法を整理してみた(2021年版)

新年あけましておめでとうございます。毎年年頭に更新している「私の情報収集法」を今年も公開します。何かの参考になれば幸いです。

インプットで参照している情報源(海外)

海外からの攻撃が主流となる中、海外情報をいち早く把握する事の重要性が増している気がしますので、今年は海外情報源から書きたいと思います。

昨年の記事では多くの海外サイトを紹介しましたが、試行錯誤の結果、まとめサイトでもある「morningstar SECURITY」や「DataBreaches.net」を押さえておけば、主要サイトが概ねカバーされると分かったので、今年は数を絞っています。

サイトキタきつね寸評

 

f:id:foxcafelate:20201231110613p:plain

morningstar SECURITY

去年と変わりませんが、情報の更新頻度、そして関連ソースの網羅性という意味では、英語系のセキュリティニュースとしては最良の情報ソースの1つかと思います。私は「Daily Security News」と「Security Blogs」を主にチェックしていますが、人によって興味が違うかと思いますので、「Malware/APT」「Exploits」「Vulnerabilities」といったカテゴリー別の記事をチェックする使い方も出来るかと思います。

※私はChromeGoogle翻訳(プラグインがあります)でニュースタイトルをチェックする使い方をしていますが、短時間でタイトルを把握するのに非常に便利です

 

f:id:foxcafelate:20201231111528p:plain

Infosecurity Magazine

こちらも去年記事で掲載しているのですが、このサイトを2番目としました。基本署名記事で記事の質は高く引用先ソースもきちんと書かれている事が多いので、興味があるニュースを深堀りする際に重宝します。

ここでの記事は日本ではあまり取り上げられていないニュースが多く、世界的なセキュリティ業界の動きを知るべき、セキュリティコンサル(本業)にも役立っている良質な情報ソースです。

※日曜や長期休暇中には一切情報発信がされないホワイトな(?)サイトです。

 

f:id:foxcafelate:20201231112251p:plain

security affairs

Security Affairs/Cybaze Spa創業者、ENISA CTIグループ、Cyber Defense Magazine誌の編集長等、数々の顔を持つPierluigiPaganini氏のサイト、あるいはTwitter@securityaffairs)はウォッチしておいて良いソースかと思います。

security affairsブログは、「Read, think, share... Security is everyone's responsibility」(読んで、考えて、共有する・・・セキュリティは全ての人の責任)というコンセプトで良質なニュースを提供し続けていますので、毎日記事を読む事で”考える癖”が身に付いた気がします。

※個人の感想です

 

f:id:foxcafelate:20201231113927p:plain

DataBreaches.net

実は・・・上記3サイトの閲覧で手一杯になっていて、最近はこちらのサイトをそんなに巡回してませんが、以前はこちらのサイトからの情報を元にしていくつも当ブログ記事を書いてました。

上記3サイトが最新ニュースを元にしているのに対して、こちらのサイトのまとめ方はインシデント(データ漏えい発生)ベースなので、見落としていたインシデントを知る切っ掛けになる事もあるサイトです。

ハッキング、マルウェア、データリーク、ヘルスケアといったカテゴライズもされているので、興味ある分野の情報を拾うのにも適しているかと思います。

 

f:id:foxcafelate:20201231115020p:plain

FBI(Cyber Crime)

f:id:foxcafelate:20201231115523p:plain

CISA(Alearts and TIPS)

国の支援を受けたAPT攻撃等が増えている事もあり、最近巡回する様になったのが、FBIとCISAのサイトです。

ここにアラート(警戒)情報が掲載された場合、全世界的に攻撃を受ける(日本企業や組織も同じ脆弱性を突かれる)可能性があるケースも増えてきているので、アラートが出てないか確認する事もソース確認という意味では重要になってきました。

※基本的に米国内向けの情報ですが、リリースのタイトルだけでもチェックしておくべきサイトかと思います。

※まとめサイトである「morningstar SECURITY」や「DataBreaches.net」をウォッチしない場合、良質な記事が多い「Security Boulevard」や「Bleeping Computer」、「ThreatPost」辺りも巡回先に入れると良いかと思います。

上記の情報サイト以外に、フォローしておくべきブロガー(インフルエンサー)として以下の方々も個人的には外せません。

サイトキタきつね寸評

 

f:id:foxcafelate:20201231145359p:plain

Krebs on Security

去年も挙げましたが、11周年を迎えたKrebs on Securityは、定期的にウォッチしているサイトの筆頭です。Krebs氏は元ワシントンポストの記者で、2016年には当時世界最大級のDDoS攻撃(最大665Gbps)をこのブログが受けた(アカマイがギブアップした)事でも有名です。

こちらのサイトには多くのセキュリティ関係者が集まる事で知られており、Krebs氏の鋭い洞察記事もさる事ながら、大きな事件記事のコメント欄を読むと勉強になり、視野が広がるかと思います。

※上記morning star SECURITYで更新対象となっていますので、このサイトを単独でウォッチする必要はありません

※当ブログ名の「Fox on security」はKrebs氏のこのサイトにあやかってつけています。

Spam Nation: The Inside Story of Organized Cybercrime-from Global Epidemic to Your Front Door

 

f:id:foxcafelate:20210101062439p:plain

Graham Cluley

英国を代表するセキュリティブロガーで、2009年/2010年にComputerWeekly誌によってITブログアワード(ユーザーオブザイヤー)で表彰されています。英語系のサイトでは色々な所で署名記事を見かけますし、講演活動にも積極的で、Twitter等を含め発信力がありますのでウォッチしておくべき1人だと思います。

Twitterアカウント(@gcluley)をフォローして、Graham氏の発信情報をチェックするのも良いかと思います。

twitter.com

 

f:id:foxcafelate:20210101063639p:plain

Troy Hunt

マイクロソフトのオーストラリア地区ディレクターが本職ですが、本職以上に、自身のID(メールアドレス)やパスワードが漏えいしてないかチェックできる、Have I Been Pwned」(HIBP)を運営している事で有名です。HIBPに登録されたIDは既に100億件を超えており、ここを見ると誰もがデータ漏えい事件の「被害者」である事がよく分かります。

無害化された漏えいパスワード辞書も公開してますので、会員サイト等の管理者の方は、侵害されたパスワード辞書(パスワード登録時の比較用)として利用/参考にされるのも良いかと思いおます。

Hunt氏のブログ(Twitter)で、HIBPに新しいDBが登録されたコメントが出た場合、どこかで侵害事件が発生した(往々にしてニュースになってない)事を表しますので、インシデントを追いかけられている方はウォッチしておくべき情報源の1つかと思います。

f:id:foxcafelate:20210103054106p:plain

※上の画面だと、右下(Recently added breaches)が直近追加のDB(=インシデント)となります。

 

f:id:foxcafelate:20210101065047p:plain
Schneier on Security

ブルーシュ・シュナイアーは暗号やセキュリティで著名な研究者です。著書も多数ありますが、特に、「セキュリティはなぜやぶられたのか」は古い本ですが、日本語にも訳されているので、セキュリティ関係の方に是非読んでもらいたい本の1つです。

ブログでの発信は、他のセキュリティ関係のソースと取り上げるニュースが被る事が多いので、必ずしもフォローが必要とは思いませんが、どうしてそのニュースを取り上げたのか、彼はどう考えているのか、そうした視点で記事を読むと新しい気づきがあるかも知れません。

※上記morning star SECURITYで更新対象となっていますので、このサイトを単独でウォッチする必要はありません

セキュリティはなぜやぶられたのか

セキュリティはなぜやぶられたのか

 
※海外情報源として英語(日本語)ソースだけで良いのか・・・と言うと、私はできていませんが、今後はダメになってくると思います。国家の支援するAPT攻撃(例えばSlarWinds事件)を考えると、攻撃をかけてくる国(母国語)の情報ソースを把握する、あるいは英語ソースと比較して差分を見ないと、その背景が見えてこなくなる気がします。

インプットで参照している情報源(国内)

国内のセキュリティ関係の情報は、コロナ禍前までは通勤途中の効率性を考えてRSS+スマホで収集していたのですが、テレワークが主となり、PCでのチェック(主に朝)が多くなり、スマホをあまり使わなくなりました。

PCでも巡回するサイトは去年と大きくは変わらないのですが、網羅性(大きな記事の見落とし)を重視してサイトを巡回しています。

サイトキタきつね寸評

 

f:id:foxcafelate:20201231104651p:plain

Izumino.jp セキュリティ・トレンド

こちらも去年までと変わりません。セキュリティ関係者の方であればまずココを抑える方は多いのではないでしょうか。私も更新頻度や幅広いソース先からの情報網羅性を考え、ここを第1の国内情報源にしています。

更新頻度が高く、大きなインシデントが発生した際は「他の情報が押し流される」事も多々ありますので、時間が無い方や、情報収集に慣れてない方はタイトルを流し見する癖をつける事をお勧めします。

 

f:id:foxcafelate:20201231104732p:plain

Security Next

情報更新頻度もさる事ながら、そして小さなインシデントやセキュリティ関係の調査結果もよく掲載されているので、「新着記事」は定期的な巡回先となっています。

セキュリティ関係の全般的なニュースだけではなく、脆弱性製品・サービス等のカテゴライズもされているので、自分の興味が強い所を巡回先にすると効率的な情報収集が実現できるかと思います。

※”誤送信しました”や、”USBメモリ落としました”クラスの発表まで丹念に拾っているのはこのサイト位かと思います。

 

f:id:foxcafelate:20201231105306p:plain

piyokango氏のTwitter

Piyologも大きなインシデントが発生した際に、状況確認するのに重宝する情報ソースですが、piyokango氏の真骨頂はやはりTwitterでの情報発信かと思います。

多忙そうな時期は情報発信がやや低調に見える事もありますが、インシデント公式発表は他の方に比べて発信が速い事が多く、セキュリティ関係の方であれば、抑えておくべき情報ソースの1つと言えます。

各種セミナー以外にも、Podcastで辻さん、根岸さんらと配信している#セキュリティのアレや、日経XTECHで連載しているpiyokangoの週刊システムトラブル等も勉強になる事が多いです。

 

f:id:foxcafelate:20201231105421p:plain

日経クロステック(xTECH)

大きな国内インシデントが発生した際の解説記事が参考になる事が多いのがこちらです。2020年はPulse Secure VPN脆弱性や、ドコモ口座など社会的に影響が大きな報道記事がいくつもあり、取材情報を元にした署名記事(事件分析)は読んでいて勉強になりました。

 

f:id:foxcafelate:20201231105506p:plain

UCカード(重要なお知らせ)

私はカード情報のセキュリティ(PCI DSS)が専門分野の1つであり、この分野のインシデントを長年追いかけているので、大手カード会社の中でもセゾン系のカード情報漏えいに関するリリースは情報発信が早く、網羅率も高いので極力毎日見る様にしています。

 

f:id:foxcafelate:20201231105948p:plain

 ScanNetSecurity

網羅性という意味ではこちらも外せないかも知れません。カード情報関係のインシデントも良く出ているので、チェック漏れが無いかをたまにチェックしています。また、事件のリリース魚拓も掲載されているので、過去のインシデントを調査する際などにも重宝しています。

※上記の情報ソースで国内セキュリティ関係(全般)の主要記事は網羅されると思いますが、新聞各社の最新記事の情報を見落とす事もあるので、最近は意識して日経新聞、朝日新聞、毎日新聞のWebサイトを流し見(※スクープ記事が無いか)する様にしています。

インプットに使っているツール

2020年はRSS ReaderやGoogleアラート等をご紹介していましたが、テレワークが主となり、PCの前で作業する事が多くなったので、スマホでの情報収集が、休憩時間や偶にある外出時間程度と、その比率が以前より大幅に下がりました。その中で現在使っているツールは以下の通りです。

サイトキタきつね寸評

 

f:id:foxcafelate:20181231104540j:plain

Yahoo!ニュース

 (iOS)

Yahoo!ニュースのテーマ設定でRSS的にニュースを拾っています。多いなニュースで、コメント欄が解放されている時は、客観性をつけるために、なるべくオーサーや読者コメントを流し見する様にしています。

※コロナ禍で生の情報(人との会話)が希薄になり、真偽の分からない情報に流されやすくなってきている気がしており、自分の意見(コア)を持った上で、多くの意見に触れる事の重要性が増している気がしています。

尚、現在フォロー中のテーマは以下の通りです。

f:id:foxcafelate:20210103052057p:plain

 

f:id:foxcafelate:20181231104955j:plain

Twitter

Twitterは情報が早い(鮮度が良い)ので、多くの方にとっての情報収集は、「良質な情報発信をする方」をフォロー出来ていれば十分かと思います。

※ご参考になるかは分かりませんが(キタきつねのTwitterフォロワー

※私の場合、Twitterスマホなので、テレワーク(PC)メインになっている中では、あまり効果的に情報収集に使えていない気がしますが、特に海外インフルエンサーの投稿は(日本でまだ情報が来てない事も多いので)意図的に読む様にしています。

 

 f:id:foxcafelate:20181231104813j:plain

TweetDeck 

上記でTwitterをあまり活用できていないと書いているので、矛盾があるのですが、以前名和さんに教えて頂いたツールで、リアルタイムに情報を拾うのに、大画面+TweetDeck(キーワード登録は非常に有効です。

※例えばDDoSをキーワード登録し、頻繁にTabが更新される=何か大きな事件があった兆候を掴むといった使い方も(フォロワー次第ですが)出来る様です。

※TweetDeck流し見専用にサブモニターが(もう1台)欲しくなります

f:id:foxcafelate:20210103052912p:plain


調査によく使っている便利ツール

最後は、私が昨年よくお世話になった便利なツール類です。

サイトキタきつね寸評

  

f:id:foxcafelate:20210101082635p:plain
Wayback Machine

サイト情報を過去に遡るという事を(無料で)実現できます。

この巨大な魚拓サイトは、インシデント調査、あるいは事件リリース等を追いかける際に非常に重宝していて、このサイトが無いとカード情報漏えい系のインシデント分析は出来ないといっても過言ではありません。

 f:id:foxcafelate:20210101082603p:plain
SHODAN

 

諸々の脆弱性を検索するこうしたサービス、あるいは同等機能を持つサービスをハッカー側は常時探しており、そこで見つけた脆弱性を攻撃してくる傾向が強くなってきています。だからこそ、ホワイト(防衛)側も、こうしたツールを有効に使って自社/自組織の脆弱性を”定期的に”チェックする事が重要かと思います。

 

f:id:foxcafelate:20210101082530p:plain

DeepL

海外サイトからの情報収集を行う上で、Google翻訳は無償である事を含めて素晴らしいものがありますが、翻訳の精度(※以前に比べて格段に上がっています)という点では、アレ・・・と思う事も多々あります。

尚、DeepL有償版ではなく、多少制約はありますが無償版だけでも海外ニュースソースからの情報を翻訳するのは十分かと思います。

私は本業で海外と方とやり取りをする事がありますが、海外業務を担当する日本人の多くがDeepLを使っている印象があります。(他社の方と話すと、このツールを使っている方が結構多いです)Google翻訳の方がまだまだ便利な部分も多いのですが、ここぞという部分の翻訳にDeepLを使う事で、より読みやすい日本語文書になりますのでオススメです。

※少し英語に自信が無い方は、海外出張(あるいは海外ゲストの簡単な通訳)程度でしたらPOCKETTALKも最近は精度が上がっていますので、こうしたツールでも十分かと思います。

【公式ストア限定】 POCKETALK ( ポケトーク ) S Plus グローバル通信(2年)付き ホワイト PTSPGW [ 翻訳機 ]+ 端末保証 

 

f:id:foxcafelate:20210101082759p:plain
ウェブ魚拓

WaybackMachineが勝手に録画してくれる全録機だとすれば、ウェブ魚拓は手動録画(魚拓)として使えるサイトです。Piyokango氏がよく使っている(いた)ので私も真似をして使う様になりました。

インシデント、特にECサイトからのカード情報漏えい事件では公式発表(事件を受けてのリリース)がいつの間にか「消されている」事があります。

※企業の情報開示姿勢としてはどうかと思いますが、ビジネスへの影響を考えると仕方が無い事かと思います。

こうしたサイトを後から調査する事もあるので、当ブログの記事では、インシデントの公式発表魚拓をなるべく取っておく様に(最近は)しています。

 

f:id:foxcafelate:20210101083604p:plain
ATT&CK

色々とインシデントを追いかける中、まだまだ出来てない部分が多いのですが、ATT&CKをもっと深く理解する事=基本に立ち返る事の重要性を改めて感じています。

 

f:id:foxcafelate:20210101084305p:plain
Qualys SSL Server Test

日本ではこうしたツールを事前の合意なしにかける事がアレ内緒で調査する時もありま・・・ですが、海外ではホワイトハッカーもよくこうしたツールを使っている様です。

残念ながら、(このサイトで検出される通信に関する)セキュリティ対策が酷い所は、まだまだ日本の企業/組織でも多いので、Web脆弱性診断を定期的に行ってない所は、最低限こうしたツールを利用して自社の脆弱性を確認する事が重要かと思います。

※違う見方をすればお金をかけなくてもある程度の事はこうしたツールを使えば確認できるという事でもあるのですが、なかなか日本では利用されてない(様に思える)のが残念な所です。

 

f:id:foxcafelate:20210101082910p:plain
No more ransom Project(日本語)

 

2020年はランサム(2重脅迫)の年といっても過言では無い程に、ランサム被害が多発しました。

カスペルスキーが4年前に発足させたNo more ransom projectでは一部ランサムにはなりますが、解除方法なども開示しており、ランサム関連の情報として、まず抑えておくべき情報がここにあります。

※ランサム被害を受けた企業は、短時間に身代金(ランサム)を請求される事が多く、パニックになる訳ですが、こうしたサイトでまずは何をすべきなのかを一度落ち着いてみてから次の行動を起こす事が重要であり、押さえておくべきサイトの1つと言えます。

偉大な先人達へ敬意を表して・・・

当ブログでは、この記事を書くのも今年で4回目になります。「情報収集法」という考え方は、私のオリジナル記事という訳ではなく、日本のセキュリティ業界をリードしていると言っても過言では無い、根岸さんとPiyokangoさんが以前に書いている記事に触発されて書き始めたものです。

セキュリティ業界という訳ではありませんが、喜多さんの下記の本は、私のバイブル的な存在です。万人にお勧めできる情報収集法/情報整理法ではありませんが、(セキュリティの世界で)プロの方やプロを目指される方には、その価値が分かるのではないかと思います。