ツイートをRSSで取得する方法（転載）【nitter】

 【2020年】Twitterアカウント不要！ツイートをRSSで取得する方法

Twitterのタイムラインって情報がどんどん流れていってしまいますよね。

隙間時間にチェックしても追いきれません。

でも見逃したくない情報もあります。

そこで、ツイートをRSSで取得できるサービスを利用してRSSリーダーであとから読めるようにする方法をご紹介します。

Nitter

オープンソースのNitter。

NitterはRSS化がメインではなく、高機能な検索機能で細かくツイートを絞り込めるのが特徴です。

細かく絞り込んだ条件でRSS化できるので必要な情報だけを効率よく取得することが可能です。

ユーザーを指定してツイートを取得

1Nitterのサイトを開きます。

Nitter
https://nitter.net/

2[ Enter username… ] と表示された検索窓にTwitterのユーザー名を入力して [  ] をタップ。

3検索結果にユーザが出てくるのでユーザー名をタップ。

4本家Twitterと同じようなタイムラインが表示されます。

5RSS化したい状態に設定します。

表示されているタイムラインがRSS化されるので、必要に応じて設定しましょう。

メニュー	内容
Tweets & Replies	ツイートとリプライを表示
Media	画像と動画の含まれたツイートのみ表示
Search	絞り込みなど詳細な検索ができる

 Search

一番右の [ Search ] をタップすると検索窓が表示されます。

その右にある [  ] をタップすると詳細な検索メニューが出てきます。

Searchのメニュー	内容
Filter	Filterの中からチェックを入れたものだけを表示。 [ Retweet ] にチェックを入れると、指定したユーザーのリツイートのみが表示される。
Exclude	Excludeの中からチェックを入れたものは除外して表示。 [ Retweet ] にチェックを入れると、指定したユーザーのリツイートは表示されない。
Time range	日付を指定して表示。 この条件を指定するとRSS化したときに新しいツイートが取得できないのでご注意を。
Near	指定した場所から投稿されたツイートだけ表示。

条件を指定したあと [  ] をタップすると検索結果が表示されます。

6RSS化したい内容がタイムラインに表示されていることを確認して、上部のRSSアイコンをタップ。

7ブラウザのアドレス欄にRSSフィードが表示されるのでコピーする。

8コピーしたRSSフィードをRSSリーダーに登録する。

指定したキーワードの含まれるツイートを取得

1Nitterのサイトを開きます。

Nitter
https://nitter.net/

2[ Enter username… ] と表示された検索窓にキーワードを入力して [  ] をタップ。

検索コマンドも使えますので工夫してノイズが入らないようにすると情報収集が捗りますね。

コマンド	内容
lang:ja	日本語のツイートのみ
-〇〇	○○が含まれないツイート

などなど、色々試してみてください。

3検索結果にキーワードが含まれるユーザが出てくるので [ Tweets ] をタップ。

4キーワードが含まれるツイートが表示されます。

5RSS化したい状態に設定します。

表示されているツイートがRSS化されるので、必要に応じて設定しましょう。

 Search

一番右の [ Search ] をタップすると検索窓が表示されます。

その右にある [  ] をタップすると詳細な検索メニューが出てきます。

Searchのメニュー	内容
Filter	Filterの中からチェックを入れたものだけを表示。 [ Retweet ] にチェックを入れると、指定したキーワードのリツイートのみが表示される。
Exclude	Excludeの中からチェックを入れたものは除外して表示。 [ Retweet ] にチェックを入れると、指定したキーワードのリツイートは表示されない。
Time range	日付を指定して表示。 この条件を指定するとRSS化したときに新しいツイートが取得できないのでご注意を。
Near	指定した場所から投稿されたツイートだけ表示。

条件を指定したあと [  ] をタップすると検索結果が表示されます。

6RSS化したい内容がタイムラインに表示されていることを確認して、上部のRSSアイコンをタップ。

7ブラウザのアドレス欄にRSSフィードが表示されるのでコピーする。

8コピーしたRSSフィードをRSSリーダーに登録する。

セキュリティ情報の集め方（転載）～RSS を配信していないサイトの対策(Feed43)～

セキュリティ情報の集め方　～しなもんの場合～

ぜひウォッチしたいと思う有用な web サイトのすべてがRSSを配信しているわけではありません。

ブックマークしておいて定期的に見るというのも手ですが、できれば他のサイトと同様にRSSリーダーで管理したいものです。

そんな方には "Feed43" をお試しになることをお勧めします。必ずうまくいくわけではありませんが、これで綺麗にRSSを生成できる場合も多いです。

feed43.com

ちょっと長くなりますが便利な方法なのでこの場でご紹介します。

ここでは有用でありながらRSSを設定していないサイトの例としてセキュリティニュースサイト "Security Next" を例に説明します。

私が知る限りTwitterアカウントも持っておらず、追いかけるのに工夫が必要なニュースサイトです。

1. どのページのフィードを取るか決めます。記事一覧、新着情報一覧などが掲載されているページが適しています。

　今回は「ニュース関連記事の一覧」で生成することにします。

　新着記事のタイトルとその URL の取得を目指します。 

2. Feed43 にアクセスし、"Create your first RSS feed" ボタンをクリックします。 

"Create your first RSS feed" ボタンをクリック

3. "Address" に Security Next の URL、”Encoding” に "utf-8" (大文字でも可) と入力し、"Reload" ボタンを押します。

　なお Encoding は他のサイトでは異なるものが使われている可能性があります。そのページのソースを見て、meta 要素を確認するのが確実です。 

こんな感じで設定されています。細部はサイトにより異なります。 

4. 正しく指定できていれば "Page Source:" にそのページのソースコードが現れます。

　文字化けしている場合は Encoding を正しく設定できていません。

 

5. 取得したいのは新着記事のタイトルと URL です。

　これらを含む部分をソースコードから見つけ出します。

　"Page Source:" を見てもよいのですが、画面が小さくて探しにくいので、ブラウザの機能で元のページのソースを表示して探すといいです。

　最新記事のタイトルなどで検索すると簡単です。 

Security Next のニュース関連記事の一覧の場合、上の画像に示すのがその部分になります。

フォーマットは一緒で、「日付」「URL」「タイトル」だけが異なる繰り返しであることがわかります。 

6. ここが一番難しい部分です。

　5. で特定した繰り返し部分を 1つ取り出して、

　・フォーマット以外の可変部分 (タイトルなど) を"{%}" で置き換える

　・ソース中に改行がある場合は、その箇所に "{*}" を追加する

　の 2つのルールに従い編集して "Item (repeatable) Search Pattern:" に入力します。

　場合によっては当該部分がかなり長いこともあるので、別にテキストエディタなどを用意して編集はそちらで行うと楽です。 

今回は改行がなかったので、「日付」「URL」「タイトル」を {%} に置き換えただけで済みました。 

この状態で "Extract" ボタンを押します。 

7. 6. での設定がうまくいっていると "Clipped Data:" に "{%1} = ** {%2} = **...” という繰り返しが表示されます。

　6. で置き換えた {%} が順番に {%1}、{%2}、……になります。

　うまく抽出できていない場合は 6. に戻って試行錯誤することになります。ページの構造上どうやってもうまくいかないこともありますが…… 

うまく抽出できた

8. Feed Title などを適宜編集します。

　特にこだわりがなければそのままでもいいでしょう。 

9. 取得するフィードの 1件 1件ごとのタイトルと URL を設定します。

　今回は、"Item Title Template:" は個別記事のタイトルにあたる "{%3}"、"Item Link Template:" は個別記事の URL にあたる "{%2}" にそれぞれ設定しました。

　Item Title に日付と記事タイトルを組み合わせて "{%1}{%3}" と設定する、といったこともできます。 

10. "Preview" ボタンを押します。

　うまく各記事のタイトルと URL が取得できて一覧になっていれば成功です。

 

11. "Feed URL" が完成したRSSフィードの URLです。 

完成！

これをコピーして自分が使っているRSSリーダーに設定します。 

無事購読できました。

【バックアップ】

セキュリティ情報の収集方法について

「イチモツを返して欲しければ…」スマート貞操帯アプリをハッキングし身代金を要求する事件が発生！（転載） ～IoT機器の恐ろしさを実感！？～

「イチモツを返して欲しければ…」スマート貞操帯アプリをハッキングし身代金を要求する事件が発生！ (2021年1月16日) - エキサイトニュース:

昨年10月、アメリカのセキュリティ会社「Pen test partners」が、IoT機器の貞操帯「Cellmate」の脆弱性を指摘したことで話題になった。

この貞操帯は、スマートフォンアプリとBluetoothで接続し、遠隔でロックできるという仕組みとなっている。しかし、アプリのAPIに欠陥があるために、悪意あるハッカーによって強制的にロックされ、自力で取れなくなってしまうというリスクがあるという。

だが、開発会社である「Qiui」はこの問い合わせに対し応答せず、沈黙を貫いていたという。

そんな中、ついにこのスマート貞操帯の被害者がでてきてしまった。

today in Internet of Things: a Smart Chastity cage was hacked and its users were held for ransom. We have the messages:

"Your Cock Is Mine Now"https://t.co/riMzXo87kT

 

— Jason Koebler (@jason_koebler) January 11, 2021

被害を受けたのは、アメリカ在住の匿名の男性。米メディア「Vice.com」の記事においては、ロバートさんという仮名で呼ばれ、オンラインでインタビューを受けていた。

ロバートさんはその日、自身のスマートフォンに「デバイスのロックを解除して欲しければ0.02ビットコイン（約77万円）を支払え」と要求するメッセージを受け取ったという。

幸いにもその時には装着しておらず難を逃れたが、貞操帯は確かにロックされており、Bluetoothで再接続して取り外すこともできなくなってしまっていたという。

また別の被害者も、「所有しているユーザーが変えられており、自由に貞操帯を制御することが全くできなくなった」とのこと。この方もまた当時つけていなかったというが、ハッカーから「お前のイチモツは俺のモノだ」という同様のメッセージを受け取っていた。

この被害が明るみになると、開発会社「Qiui」は「Pen test partners」に対し、アプリの最新バージョンでは修正されていることを述べているという。

アプリの監査を行ったセキュリティ研究者、アレックス・ローマス氏は、「ほとんどの企業と製品は、存続している間なんらかの脆弱性を抱えることとなる。この機器ほど酷いものではないものの、何かしらはある。」とコメントしている。

IoT機器は非常に便利だが、使用する人は、何らかの脆弱性の存在を心の隅にとどめておいてほしいものだ。

血圧計を買ってみる

先日、別件で尿検査をしたら、尿糖(2+)が検出されてしまった。

昨年の人間ドッグでは何もなかった（厳密にはぎりぎりセーフ）のに、急に心配になって色々調べてみたところ、血糖値には空腹時血糖値と食後血糖値があるらしい。

人間ドッグでの結果は空腹時血糖値の結果で、問題の尿検査は食後血糖値である。

空腹時血糖値では異常がなくても食後血糖値に異常がある人を隠れ糖尿病とかいうらしい。

病は気からというが、ショックのあまり、体調が急激に悪化していく気がしたので、さっそく病院に行くことにした。

 食後血糖値が怪しいことはわかっていたので、病院でも食後2時間のタイミングでの採決と採尿を行った。

結果、血糖値自体はそこまで悪いわけではないが、糖尿病の基準値として使っているHbA1cという値が要注意のレベルに達しているとのことだった。

また、昨年の人間ドッグの結果も併せて提出して相談した結果、どうも数年前から発生している高脂血症（悪玉コレステロールの高さ）が原因のようで、高血圧、尿酸値、糖尿の値が悪化しているとのことだった。

この日時点では糖尿病と判定されることはなかったが、要経過観察となり、３か月後に改めて採決と採尿を取ることにした。

また、先生から毎日血圧を測るように言われ、血圧計を買ってみることにした。

「高血圧管理手帳」なるものをもらったが、紙ベースのものはどうもやる気がしない。

そこで、スマホと連携して計測したら自動で記録を取ってくれる血圧計を買ってみることにした。

３か月後の検診に向けて食事のコントロールを強化せねば・・・。

【1月の検査結果と是正が必要な項目】

・MCH(赤血球1個当たりの、平均ヘモグロビン量)：32.3pg（基準28～32）

・MCHC(赤血球1個当たりの、平均ヘモグロビン濃度)：36.0g/dL（基準31～35）

・ALT(肝臓に問題があると、血液中に流れる量が増える)：57U/I（基準4～44）

・尿酸：7.7mg/dl（基準4～7）

・総コレステロール：242mg/dl（基準150～219）

・中性脂肪：228mg/dl（基準50～149）

・LDLコレステロール：142mg/dl（基準70～139）

・グルコース(血糖値)：111mg/dl（基準70～110）

・尿ブドウ糖訂正：+（基準-～+-）

2月2日は「情報セキュリティ」の日。その理由は、、、

作者も知らぬ間に凶暴化…35年前のコンピュータウイルス「Brain」とは？（ブルーバックス編集部）:

今日2月2日は、内閣サイバーセキュリティセンターによって「情報セキュリティの日」に指定されています。平成18年2月2日に「第１次情報セキュリティ基本計画」が決定されたことにちなんで制定されたもので、国民の情報セキュリティ意識を高めることを目的しています。

サイバー攻撃の歴史は古く、インターネットが普及していない1986年には、すでに最初期のコンピュータウイルスが開発されていました。パキスタンでコンピュータ販売会社を営んでいたアルヴィ兄弟が、横行するソフトウェアの違法コピーに業を煮やし、「Brain」と呼ばれるコンピュータウイルスを創り出したのです。

この「Brain」はフロッピーディスク（懐かしい響きですね）の内部に仕込まれ、ソフトウェアが違法コピーされると初めて起動します。当初は「このウイルスに用心、ワクチン接種のためにご連絡を…」というメッセージとアルヴィ兄弟の経営する会社「Brain Computer Services」の連絡先を画面に表示するだけだったのが、“いつのまにか”ディスクを読み取り不能にする能力が備わっていた（誰かにの手によってプログラムが書き換えられていた）と言います。

Brainの出現から30年以上がたった現在、IT産業は信じられないようなスピードで進化を遂げ、もはやインターネットや各種のサービス・データベースなしには、現代社会は成り立ちません。

その一方で、サイバー攻撃はより大規模に、より巧妙な手口で行われるようになってきました。たとえば、政府は来年9月に、行政のIT化を推進する「デジタル庁」を設立しますが、この行政機関は日本国民に割り当てられるマイナンバーを一元管理する予定となっています。もしもデジタル庁がサイバー攻撃の被害にあうことがあれば、その損害は甚大なものになるはずです。

デジタルの利便性を享受するためには、サイバーセキュリティの研究・開発は欠かすことのできないものなのです。

北陸先端科学技術大学院大学、VirusTotalの使い方を誤って個人情報ファイル流出（転載）

マルウェア検査サイトを通じた個人情報ファイルの外部流出、そのまさかの原因が話題に【やじうまWatch】:

　　マルウェア検査サイト「VirusTotal」を通じたファイル流出が、一部で話題になっている。

　「VirusTotal」はGoogleが運営するマルウェア検査サイトで、ウェブサイトやファイルを指定するとマルウェアが含まれないか検査して教えてくれるのだが、今回話題になっているのは同サイトが提供している別の機能。それはユーザーから提供されたデータを会員企業や研究者の間で検体として共有する機能で、これらを知らずに手持ちのファイルを検査目的でアップすると、意図せず外部に漏れてしまう危険があるのだ。誤ったファイルをアップロードした時のための削除申請フォームが用意されていることから分かるように、あくまでも仕様であって不具合ではないのだが、ブラウザ拡張機能を使うとネットからダウンロードしたファイルを自動的にVirusTotalに送信する設定も可能とのことで、先月末に北陸先端科学技術大学院大学で発生した個人情報の流出は、同サイトまたはそれに類する検査サイトがきっかけだったと見られている。無料で使える検査サイトとして広く知られるVirusTotalだが、こうした機能があることは知っておいたほうがよさそうだ。

• VirusTotal
  https://www.virustotal.com/
• I accidentally uploaded a file with confidential or sensitive information to VirusTotal, can you please delete it?（VirusTotal）
  https://support.virustotal.com/hc/en-us/articles/115002093689-I-accidentally-uploaded-a-file-with-confidential-or-sensitive-information-to-VirusTotal-can-you-please-delete-it-
• [怪談]VirusTotal沼のお話（対策含）｜__aloha__（note）
  https://note.com/hiro_shi_note/n/n3be8960784b6
• 外部サイトへの本学構成員に関する個人情報の流出について（JAIST 北陸先端科学技術大学院大学）
  https://www.jaist.ac.jp/whatsnew/info/2021/01/29-2.html
• バックアップ

ハッキングフォーラムを運営するとはどういうことか。RaidForumsオーナーOmnipotentとの会話 / What It’s Like to Run a Hacking Forum: A Conversation With RaidForums Owner Omnipotent（転載）

What It’s Like to Run a Hacking Forum: A Conversation With RaidForums Owner Omnipotent: 

編集部注：過去5年間、RaidForumsは、常に注目を集めるデータベースの流出源であることで名を馳せてきました。

ハッキング愛好家のコミュニティ（このサイトには公式に50万人以上のメンバーがおり、1日に約2万人のアクティブユーザーがいる）では、サイバー攻撃に使えるツールを宣伝したり、漏洩した組織へのアクセスを売ったり、漏洩したデータベースをサイトに流したり、政治やスポーツの試合を含む一般的なニュースについてチャットをしたりしています。

RaidForumsは2015年にOmnipotentというユーザーによって開始され、現在もサイトを運営しています。彼のTwitterアカウントとフォーラムへの何千もの投稿にもかかわらず、Omnipotentは控えめな姿勢を保っています。RaidForums上では、彼はイギリスのロンドンに住んでいることを明かし、興味のあることを "ゲーム、学習 "と記載していますが、私生活についてはあまり語らないようにしています。

Omnipotentは、Recorded Futureの専門家である脅威インテリジェンスアナリストのDmitry Smilyanets氏と、RaidForumsを始めた理由と、それを運営することがどのようなものなのかについて話しました。以下のインタビューは、長さとわかりやすさのために軽く編集されています。

Dmitry Smilyanets：どのようにしてフォーラムを作成しようと決めたのですか？最初の目標はお金を稼ぐことでしたか？

Omnipotent：ウェブサイトを作った当初の目的は、"Twitch raiders "のための安定したプラットフォームを提供することでした。2015年には他にも多くのフォーラムやウェブサイトがありましたが、DDoS攻撃で常にダウンしていたため、所有者はウェブサイトを維持するための経験が不足していました[編集部注：DDoS（分散型サービス拒否）攻撃は、ウェブサイトにジャンクなトラフィックを氾濫させ、アクセス不能にします]。そこで私は、この特定のコミュニティのために安定したウェブサイトを作るために、私の親愛なる友人が "Celaeon "という名前でYouTubeの大規模なフォロワーを持つ "Twitchレイド "の大物だったので、私はわざわざこの特定のコミュニティのためにウェブサイトを作りました。このアイデアは、最初は私たちにお金を払うという選択肢がなかったので、お金を稼ぐことはありませんでした。最終的には、サーバー費用などの維持費を支援するための寄付の受け入れを開始し、ウェブサイトが今日のようなものに進化したように、私たちは他の多くのウェブサイトのようなランクを提供していますが、それでも私たちははるかに安く、サブスクリプションを必要としたことはありませんでした-すべてのものは生涯です。

DS：デフォルトのアニメの女の子アバターとGODのユーザーステータスを思いついたのは誰ですか？

Omni：コミュニティのメンバーからは、特別な名前や特典をつけてお互いに「見せびらかす」ために、より高いランクを要求されていましたが、これらが実際に追加された主な理由は、新しいユーザーにフォーラムへのアクセスを得るための別の方法を提供するためでした。現在、新しいアカウントでは、スタッフメンバーでない限り、システムを介してユーザーにメッセージを送ることさえできません。これは、ボットアカウントが広告などでユーザーの受信トレイに殺到するように設定されていたため、大量のスパムが発生していたためです。メッセージを送信したり、より多くの投稿ができるように、手動で無料でアカウントを作成することもできますし、比較的少額の寄付をすることで、アカウントのロックを解除することもできます。

マスコットの質問に関連して、これはユーザーの投稿に過ぎません。コミュニティは大きく、多くの人がロゴやアイデアを投稿してくれます。

DS: あなたのロールモデルは誰ですか？エロン・ムスクについてどう思いますか？

Omni：私にはお手本がないのかな？誰かの足跡を辿ろうとしているわけではありません。私はTwitterでこの人をフォローしているので、あなたがエロン・ムスクについて私にこの質問をしたと仮定しています。私は彼の会社の株を持っていて、彼の会社のアイテムを所有しているので、それは私ができることは何でも知っていることが私の個人的な利益になっているからです。

DS: RaidForumsは現在、多種多様なオンライン活動を行う最大級のコミュニティとして位置づけられています。法的な部分やルールも非常にしっかりしています。しかし、盗まれた個人情報をメンバーが取引できる「リークマーケット」も見逃せませんね。このようなコンテンツをホストすることは、法的な範囲内であると考えていいのでしょうか。

Omni：あなたは "Leaks Market "サブフォーラムについて言及していますが、そこは明らかに個人情報を取引するために使用されているようですが、それを取り締まるのは私の立場ではありません。私たちの規約と私の個人的な意見に従って、私はこのセクションで人々が販売したり、販売しなかったりするものに対して個人的に責任を負うべきではありません。また、彼らが合法的または違法にデータを取得しているかどうかも個人的に知ることはできません。

結局のところ、PIIの販売はFacebookのようなビジネスでは当たり前のことであり、これらのユーザーがやっていることは、この特定の面では[Facebook]のような大企業がやっていることと何ら変わりはないと私は考えています。私はこのサブフォーラムをあまりフォローしていませんが、先ほども言ったように、個人的には全く監視していません。私の考えでは、これらの記事は根拠のない記事であり、人々は何でも好きなように宣伝することができ、その多くは、私たちの詐欺レポートを見ればわかるように、完全に虚偽であり、人々を騙そうとしているだけです。したがって、私が "ランダム "な記事の束をホストしていることは、少しも違法ではないはずです。しかし、もし我々が当局から報告を受けた場合、例えば、我々がホストしているサンプルを含む記事に関しては、それらのサンプルは、それらの特定の法律を遵守するために、我々のウェブサイトから移動されます。しかし、記事自体は言論の自由や報道の自由によって保護されているので、それを何と呼ぼうと、記事自体は残ります。

DS: あなたはRaidForumsでLedgerのデータベースが流出したことを喜んでいると言っていましたが、あなたの立場を説明できますか？

Omni：これまで、Ledger事件という不幸な出来事について、私の立場を説明してきました。しかし、現実の世界では、これらの事件は毎日のように起こっており、人々はダークウェブや私のウェブサイトのような他の手段を使って、このデータをお互いの間で取引しようとしていますが、これは違法です。私は個人的には、これらの「ハッカー」が行うような数十万ドルでデータを売ろうとすることは信じていません。私は個人的には、このデータを公開し、本質的には誰でも自分がどのように影響を受けたかを見ることができるようにし、メールを変更したり、パスワードを変更したり、将来の予防策を講じることで自分自身を守ることができると信じています。データベース」セクションはそのために作られたもので、コミュニティに、そしてひいては一般の人々に、あなたが持っているすべてのデータを無料で共有します。このコミュニティが数ヶ月間「ハッカー」の間でバックグラウンドで起こっていたことをLedgerとそのユーザーに警告することができたのを見て、私は嬉しくなりました。

DS: この1年で、RaidForumsはネットワークへの初期アクセスを売り始めた巧妙なハッカーを集めました。そのアクセスがランサムウェアの関連会社によって購入され、フォーラムに不要な注目を集めることを恐れていませんか？

Omni：現在の私のウェブサイトの個人的な目標は、データを自由にすること、つまり、このデータを違法に売買している人々からお金を奪うことです。そのため、私たちが自分たちに注目を集めることは、この目標をさらに高めることになります。私たちのことを知っている人が多ければ多いほど、より多くのデータが公開され、一般の人が自分たちを守ることができるようになるからです。前に述べたように、私自身がこれらの主張を確認することができず、販売されているデータが合法的に入手されたものなのか違法に入手されたものなのか、あるいはそれが全く実在するものなのかどうかもわからないので、ユーザーの販売を取り締まるつもりはありません。結論から言うと、私はこの注目を恐れていません。

DS：私はRaidForumsでいくつかのドッキング事件を観察しました。ロシア語圏のサイバー犯罪者のアンダーグラウンドでは、これは通常ルール違反です。フォーラムのメンバーがお互いに罵り合うとき、あなたはどう思いますか？

Omni：私は正直にあまり考えていません、すべての意図と目的のために、私たちはウェブサイト自体でdoxingを許可していません。しかし、私たちは、人々がdoxingから人々を停止することはできません-したがって、私たちは、あなたが被害者の情報をオフサイトPastebinのようなサービスへのハイパーリンクを投稿することが許可されているサブフォーラムを持っています。正直に言うと、私は、公安のためだけでなく、これらの犯罪者の逮捕に連邦協会を支援するために、小児性愛者や悪意のある "ハッカー "のようないくつかの人々は、公安のためだけでなく、彼らの情報がリークされるに値するのです。一方で、恐喝などの目的でDoxをする悪意のある人もいますが、これは素晴らしいことではありませんが、私たちが何をしようと必ず起こることです。しかし、私はできることをしています。例えば、ユーザーをDoxされないようにするために様々なルールがありますが、実際には犯罪者を追放するのが精一杯で、それは何かと言えば火を噴くだけです。

DS: レイドフォーラムの将来をどのように考えていますか？2021年に向けて何か特別なイベントを計画していますか？

Omni：個人的には、物事が実際に計画通りに進むことはないので、物事を計画するのは好きではありません。明日、ウェブサイトに何が起こるかは誰にもわからない。何があっても、私やこのウェブサイトに関係なく、コミュニティは生き続けることを知っています。2021年には、セキュリティと機能のアップデートをリリースできることを期待していますが、特別なことは何もありません。

DS: 法執行機関がフォーラムを監視していることは、あなたにとってどのくらい大きな問題なのでしょうか? 法執行機関が監視しているアカウントの割合はどのくらいだと思いますか?

Omni：まあ、私はフォーラムが監視されていると仮定していますが、その後、この日と時代に再び誰もが監視されています。それは、このサイズの任意のウェブサイトは、複数の連邦政府と非連邦政府のエンティティによって監視される可能性が非常に高いです。結論から言うと、私は法を守る市民であるために最善を尽くしているので、私はそれに悩まされていません。

DS: レイドフォーラム運営の収入に対して税金を払っているとおっしゃっていましたが、これは本当でしょうか？これは本当ですか？2020年にはどれくらいの収入があったのでしょうか？

Omni：私はこれを読んでいる人はこの返信を期待していると思いますが、私は私の個人的な財政についての情報を共有するのは気が引けます。このウェブサイトは登録されたビジネスではなく、どのような支払いも寄付とみなされますが、以前のコメントを参照して、私は常に法を守る市民であろうとしているので、法的に支払わなければならない税金はすべて支払っています。しかし、例えば、私の住んでいる国では、暗号通貨は何の税金も払っていないので、私もこのような形で作られた収益には税金を払っていません。

DS: 秘密を教えてください。あなたの日々はどのようなもので、週に何時間くらいRaidForumsの運営に費やしていますか？

Omni：最近は誰もが何かしらのロックダウンを受けているので、私の生活が人口の90％に似ていても不思議ではありません。私は自分の住んでいる場所から出ることはほとんどないので、家に閉じこもって、オンラインで友達と話したり、コミュニティにサポートを提供したりすることが私の一日の基本です。これは非常に単純なことですが、パンデミックの今日、一般の人々の安全を守るために、私たちにできることはすべてです。ですから、私のウェブサイトにどれくらいの時間を費やしているかと言われれば、起きてから寝るまでの時間になります。

英国 国防省が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の３階層に整理されています。また、文中の「*」の印は、訳出を担当した小木の判断でハイパーリンクを貼った箇所となります。印が無い箇所のハイパーリンクは、原文のリンクを踏襲しています。）。

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

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

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

　率直に言って、公的機関または民間企業であるかにかかわらず、多くの法人組織が技術的なインフラストラクチャを最新の状態に維持するために苦労しています。自社・自組織による運用であっても、サプライヤへのアウトソーシングであっても、オンプレミスのインフラストラクチャを最新の状態に維持することはとても困難です。オンプレミス環境で単一のウェブサイトを基盤とする技術構成を例として考えてみましょう: 　これほどシンプルな例であっても、低レイヤーのハードウェア、オペレーティングシステム、ウェブサーバーソフトウェア、そしてウェブアプリケーションなどを動作させるハードウェア、ファームウェア、基本入出力システム (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）」や「コンテナ」)を利用することをお勧めします。これは、システムへに対するパッチ適用を早め、攻撃に対する脆弱性が存在する時間を短縮することを意味します。

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

1. DDoS対策：しきい値の超過などの異常がなく通過
2. FWなどの対策：通常アクセスとみなされ通過
3. マルウェア対策：不審なファイルのため駆除

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

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

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

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

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

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

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

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

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

政府機関

総務省

文書タイトル	公開日
IoT・5Gセキュリティ総合対策2020	2020/07/17
医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン	2020/08/21
DX時代における企業のプライバシーガバナンスガイドブックver1.0	2020/08/28
中小企業等担当者向けテレワークセキュリティの手引き（チェックリスト）（初版）	2020/09/11
テレワークセキュリティに係る実態調査（１次実態調査）報告書	2020/10
スマートシティセキュリティガイドライン（第1.0版）	2020/10

経済産業省

文書タイトル	公開日
昨今の産業を巡るサイバーセキュリティに係る状況の認識と今後の取組の方向性について	2020/06/12
IoTセキュリティ・セーフティ・フレームワーク（IoT-SSF）	2020/11/05

高度情報通信ネットワーク社会推進戦略本部（ＩＴ総合戦略本部）

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

警察庁

文書タイトル	公開日
令和２年度上半期におけるサイバー空間をめぐる脅威の情勢等について【令和２年10月１日】	2020/10/01

CRYPTREC

文書タイトル	公開日
「TLS暗号設定ガイドライン」第3.0版	2020/07/07
「暗号鍵管理システム設計指針 (基本編)」第1版	2020/07/07
量子コンピュータが共通鍵暗号の安全性に及ぼす影響の調査及び評価	2020/07/08
XTSモードの実装性能調査	2020/07/08
CRYPTREC Report 2019 暗号技術評価委員会報告	2020/08/24
CRYPTREC Report 2019 暗号技術活用委員会報告	2020/08/24

セキュリティ関連団体

IPA

文書タイトル	公開日
データサイエンティストのためのスキルチェックリスト/タスクリスト概説	2020/07/07
TLS暗号設定ガイドライン	2020/07/07
中小規模製造業の製造分野におけるデジタルトランスフォーメーション（DX）のための事例調査報告書	2020/07/20
情報セキュリティ白書2020	2020/08/24
ネット接続製品の安全な選定・利用ガイド -詳細版-	2020/08/27
脆弱性対処に向けた製品開発者向けガイド	2020/08/27
アプリケーションコンテナセキュリティガイド（NIST SP800-190の日本語訳）	2020/09/04
「制御システム関連のサイバーインシデント事例」シリーズ - 2018年 半導体製造企業のランサムウェアによる操業停止	2020/09/08
2020年 医療関連企業のランサムウェアによる業務停止	2020/09/08
ソフトウェア開発分析データ集2020	2020/09/30
ITSS+「セキュリティ領域」改訂版	2020/10/02
IoTセキュリティ教材（利用には申請が必要）	2020/11/18
ゼロトラスト・アーキテクチャ（NIST SP800-207の日本語訳）	2020/12/18
「情報システム・モデル取引・契約書」第二版	2020/12/22
中小規模製造業者の製造分野におけるデジタルトランスフォーメーション（DX）推進のためのガイド	2020/12/23

日本クラウドセキュリティアライアンス（CSAジャパン）

文書タイトル	公開日
SDPによる真のゼロトラスト実装	2020/07/20
安全なマイクロサービスアーキテクチャ実装のためのベストプラクティス	2020/11/17
クラウドコンピューティングの重大脅威: 11の悪質な脅威 ディープダイブ	2020/11/25

重要生活機器連携セキュリティ協議会

IoT分野共通セキュリティ要件ガイドライン2019年度版～11要件における解説編	2020/08/11
IoT分野共通セキュリティ要件ガイドライン2021年版_ver1.0	2020/11/24
2020年セキュリティ十大ニュース	2020/12/25

JNSA

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

その他

文書タイトル	公開日	公開組織
マネージドセキュリティサービス(MSS)選定ガイドライン Ver.2.0	2020/07/13	ISOG-J
Log Analysis Training	2020/07/28	JPCERT/CC
インターネットサービス利用者に対する 「認証方法」に関するアンケート調査結果報告書	2020/09/09	フィッシング対策協議会