露サイバー攻撃による米大統領選挙への介入 まとめ
事態の大きさの割に日本国内のこのニュースの取り上げ方がやや不満だったので。英語のWikipediaにはそれなりの文書量でまとめられている。
2016 United States election interferenceby Russia - Wikipedia
2016-11-08 2016年アメリカ合衆国大統領選挙選挙
2016-12-09 ワシントンポスト紙がロシアのサイバー攻撃による大統領選挙への介入について報道
Secret CIA assessment says Russia was trying to help Trump win White House - The Washington Post
2016-12-17 FBIがCIAの結論を支持
FBI in agreement with CIA that Russia aimed to help Trump win White House - The Washington Post
2016-12-29 ホワイトハウスがロシアへの報復措置を発表
ロシアの2つの情報機関と情報機関の幹部4人、それにサイバー攻撃を支援した3つの企業に対して制裁を科すと発表
FACT SHEET: Actions in Response to Russian Malicious Cyber Activity and Harassment | whitehouse.gov
Statement by the President on Actions in Response to Russian Malicious Cyber Activity and Harassment | whitehouse.gov
The Administration’s Response to Russia: What You Need to Know | whitehouse.gov
2016-12-30 クレムリンは米国の報復措置への対抗はしないことを発表
逆に米外交官の子らをクレムリンのヨールカ祭に招待
Statement by the President of Russia | President of Russia
We regard the recent unfriendly steps taken by the outgoing US administration as provocative and aimed at further weakening the Russia-US relationship. This runs contrary to the fundamental interests of both the Russian and American people. Considering the global security responsibilities of Russia and the United States, this is also damaging to international relations as a whole. As it proceeds from international practice, Russia has reasons to respond in kind. Although we have the right to retaliate, we will not resort to irresponsible ‘kitchen’ diplomacy but will plan our further steps to restore Russian-US relations based on the policies of the Trump Administration. The diplomats who are returning to Russia will spend the New Year’s holidays with their families and friends. We will not create any problems for US diplomats. We will not expel anyone. We will not prevent their families and children from using their traditional leisure sites during the New Year’s holidays. Moreover, I invite all children of US diplomats accredited in Russia to the New Year and Christmas children’s parties in the Kremlin. It is regrettable that the Obama Administration is ending its term in this manner. Nevertheless, I offer my New Year greetings to President Obama and his family. My season’s greetings also to President-elect Donald Trump and the American people. I wish all of you happiness and prosperity.
オリンピック・パラリンピックの競技会場都市のマスコット
県庁に行く機会があり、生協でキャラクターのピンバッチが販売されているのに気づいた。
(ピンバッチを胸につけて打合せに行く、というのは流石に毎回はできないが、)大会関連の施策を打つときに、資料作成でつかったらよろこばれるのではなかろうか?多くの団体は、商用利用でない限り許可は不要に見える。バリエーションも豊富で、さいたま市のキャラクターなんて資料に使ってくださいと訴えているかのごとくいろんな絵が用意されている。
東京都や神奈川県には、公式なキャラクターはないようだ。
サイバーセキュリティに関する政策提言あつめ
サイバーセキュリティの取組は、国の政策から始まっていることが多いようです。
これらをあらかじめ読んでおくことで、自組織に振ってくる取組について早めに察知することができるでしょう。
年月日 | 提言 |
---|---|
20171003 | 総務省サイバーセキュリティタスクフォースIoTセキュリティ総合対策 |
20170710 | セキュリティ産業のビジネス化研究会取りまとめ |
20170523 | 自由民主党政務調査会IT戦略特命委員会 データ立国による知識社会への革新にむけた提言 デジタル・ニッポン2017〜Nippon, the Data Nation〜迷わず前へ |
20170523 | 自由民主党 サイバーセキュリティ対策推進議員連盟 提言 |
20161110 | 未来投資会議(第2回)竹中議員提出資料 |
20161021 | 日経・CSISバーチャル・シンクタンク第3期サイバーセキュリティー研究チーム 潜伏型サイバー・テロに備えよ―「信頼のインターネット」構築に向けて― |
20160119 | 経団連 サイバーセキュリティ対策の強化に向けた第二次提言 |
20151208 | 自由民主党情報通信戦略調査会IT戦略特命委員会 サイバーセキュリティ関係予算確保に向けた決議 |
20150730 | 自由民主党 サイバーセキュリティ対策の強化に向けた緊急提言 |
20150522 | 総務省情報セキュリティアドバイザリーボード サイバーセキュリティ政策推進に関する提言 |
20150416 | 自由民主党政務調査会IT戦略特命委員会 今後のサイバーセキュリティ政策の在り方に関する提言 |
20150217 | 経団連 サイバーセキュリティ対策の強化に向けた提言 |
20140728 | IT利活用セキュリティ総合戦略推進部会 IT利活用セキュリティにおける総合的かつ戦略的な政策推進に係る提言 |
20140603 | 日経・CSISバーチャル・シンクタンクサイバーセキュリティー戦略タスクフォース 安全保障戦略としてのサイバーセキュリティティ強化―国民を守るために― |
201309 | ⾼⽥広章 松本勉 車載組込みシステムの情報セキュリティ強化に関する提言 |
20130405 | 総務省における情報セキュリティ政策の推進に関する提言 |
20120224 | 自由民主党 情報セキュリティに関する提言 |
20011120 | 「民主党 サイバーテロ対策への提言」中間報告 |
脆弱性管理業務の稼働時間算出のためのモデルシステム構成を提案する
脆弱性対応の稼働時間を数値化し、コストの具体値を算出したい。そこで、一定期間にモデルシステムに対して配信された脆弱性の件数をもとに、稼働時間を実測してみようと思う。本稿ではその準備として、システムを構成するソフトウェアとそのバージョンのモデルを提案する。
本命の実測結果は結果が出たときにまた別の記事にて。
条件
ソフトウェアとそのバージョン(2016年春季モデル)
共通
仮想化:VMware vSphere Hypervisor (ESXi) 6.0 リモート接続:OpenSSH 5.3 ファイルアップロード:Vsftpd 2.2.2 SSL/TLS:OpenSSL 1.0.1
Web/APサーバ A構成
OS:Red Hat Enterprise Linux 6.7 Webサーバ:Apache HTTP Server 2.2.15 Java:Openjdk 1.7.0 Webコンテナ:Apache Tomcat 7.0.68 Webアプリケーションフレームワーク:Apache Struts 2.3.20
Web/APサーバ B構成
OS:CentOS 6.7 Webサーバ:Apache HTTP Server 2.2.15 スクリプト言語:PHP 5.3.3 CMS:WordPress 最新 JavaScriptライブラリ:jQuery
DBサーバ
RDMS:MySQL 5.1.73
NTPサーバ
NTPサーバ:ntp 4.2.8
芸能ニュースがセキュリティインシデントに発展するパターン
ごくまれにですが、芸能ニュースがきっかけとなってセキュリティ的な問題点がクローズアップされる事例が起きます。
芸能ニュースは注目度がとても多いです。このため極めてプラス思考な表現をすると、セキュリティ上の問題点が人口に膾炙するのに効果があると思います。
まだまだわたしが把握する件数は少ないのですが、これからも&他にもありそうなので、まとめはじめます。
2003年 年金未納問題に伴う業務目的外の閲覧行為
納付率の大幅な低下を受けて、厚生労働省及び地方社会保険事務局に国民年金特別対策本部が設置された。収納対策として女優の江角マキコを起用し、テレビCMやポスターで「年金もらえないって言ったの誰?」と挑発的な宣伝文句で納付を呼びかける広告が話題になった。しかし翌年に当の江角本人自身が国民年金に未加入・未納だったことが発覚した。社会保険庁職員約300人が興味本位で年金の個人情報を閲覧し、更にマスコミへ年金未納情報をリークしていた職員もいたことが判明し、社会保険庁の杜撰な個人情報管理が明るみに出た。
2015年 関ジャニ∞大倉忠義さんと西島秀俊さんの情報漏洩でりそな銀行がお詫び
俳優の西島秀俊さんや関ジャニ∞の大倉忠義さんが来店した情報をりそな銀行の中目黒支店で働く母親から得て、それをTwitterに投稿。
6 月 8 日(月)、特定のお客さまが中目黒支店にご来店された情報が、Twitter 上に漏えいしていたことが判明いたしました。お客さま並びに関係者の皆さまには、多大なご迷惑とご心配をお掛けいたしましたことを、深くお詫び申し上げます。
2016年 ベッキー・ゲス極事件
1月7日発売の週刊文春において、ベッキーの不倫疑惑が掲載された。記事にはLINEの生々しいやり取りた流出。さらに1月21日発売の週刊文春に、ベッキーの謝罪会見前後のLINEの内容が掲載され、それらをどのように記者が入手したのかが問題となった。
ベッキー&川谷絵音不倫疑惑まとめ | はにはにわ。
ASCII.jp:ありがとう文春! ベッキー・ゲス極事例からLINEの安全を考える
2016年 山本耕史・堀北真希夫妻の個人情報を不動産会社勤務の女性がTweet
都内の不動産会社スタッフ女性が、「堀北真希と山本耕史夫婦接客した」「35万の物件紹介した」とTwitterで呟いた。宅建業法の守秘義務に違反している。
1.経 緯 本年 1 月 8 日(金)、対象会社の従業員(以下「当該従業員」といいます)が、著名な芸能人のお客様を賃貸物件にご案内後、自己の Twitter 上に、当該お客様のお名前と賃貸物件情報の一部を記載していたことが判明致しました。 2.対象会社の対応 当該従業員は、本人の Twitter アカウントを翌朝(1月9日)速やかに削除致しました。また、対象会社の代表者と当該従業員が、当日お会いできた当該お客様の窓口になっている関係者の方々に本事案につき謝罪を行ったとのことであります。
『IPアドレスは暗記してはいけない』その理由
IPv4アドレスは2進数だと32bit固定長の数値です。可読性を上げるため、例えば「198.51.100.240」のように、8bitごとに4個の10進数を"."で区切って表記します。このため、IPアドレスの表記に必要な数字の数は、最短で4個、最長で12個です。では平均的には何個になるでしょう?計算してみます。
1オクテット(8bit)の数字を10進数に直したときの桁数は、
- 1桁 : 1,2,3,4,5,6,7,8,9,0 ・・・10パターン
- 2桁 : 10〜99 ・・・90パターン
- 3桁 : 100〜255 ・・・156パターン
となりますので、平均で2.5703125桁となります。4オクテット分なので、4倍すると10.28125。おおよそ数字10個分だと思ってよいでしょう。具体的には次の表のようになります。さらにIPアドレスには、Mrtianアドレスといって、送信元IPアドレスにはなりにくいアドレス帯があります。それを除外した場合についても併記します。
単純計算 | Martianアドレスを除外した場合 | |
---|---|---|
数字4個 | 10,000個 | 9,000個 |
数字5個 | 360,000個 | 332,000個 |
数字6個 | 5,484,000個 | 5,134,180個 |
数字7個 | 46,008,000個 | 43,250,220個 |
数字8個 | 231,843,600個 | 216,087,398個 |
数字9個 | 717,724,800個 | 654,117,020個 |
数字10個 | 1,334,586,240個 | 1,173,176,898個 |
数字11個 | 1,366,709,760個 | 1,143,922,884個 |
数字12個 | 592,240,896個 | 466,229,088個 |
合計 | 44,157,632,512個 | 37,860,674,744個 |
平均 | 数字10.28125個分 | 数字10.22637個分 |
人が短期記憶できる数字は、最大7±2個であると指摘されています。ずいぶん昔の文献です。早くからこの分野が研究されていたということだと思います。
Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 81-97
この研究を参考にして、技術的な分野では、安全マージンをとって5桁までの数字しか暗記しないルールにするとよいでしょう。IPv4アドレスは、平均で数字10個分となります。暗記をしてみたくなる長さと言えますが、人のワーキングメモリを充分に超える長さです。IPアドレスは暗記しようとせず、必ずメモをとるか、もしくは情報源からそのままコピー・アンド・ペーストしましょう。
なおIPv6アドレスは128bit固定長なので、16進数表記をしたとしても暗記はほぼ困難。あんまりこういうことを考えなくてもいいでしょう。
続きを読むサイバー攻撃の『送信元IPアドレス』がわかったらする10のこと
インシデントレスポンス、とくにトリアージのフェーズにおいて、IPアドレスの付随情報を調べることは重要で、かつ頻度もたいへん多いです。再びするときに困らないように、やるべきリストを考察します。
aguseのようなWebサービスなら、複数の調査が一括でできるのでよくつかいます。ただし、Webサービスを使うということは、検索した履歴がWebサービス側に残ってしまうので注意してください。
1. もう一度、そのアドレスが間違っていないかどうか確認する
IPアドレスを間違える行為は"あるある"です。
IPアドレスの暗記は厳禁です。誤ったときに手戻りが発生しますし、社内外に伝達した後だととり返しがつきません。IPアドレスについて調べるときは、それが正しいものか必ず複数回確認してください。もしくはなるべく情報源をそのまま"コピー・アンド・ペースト"するべきです。
2. Whois検索
- 国
- AS
- 管理者の組織や連絡先
などが分かります。
サービスの利用者がいないと想定される国や地域であれば、ファイアウォールで通信を遮断する判断根拠となります。また、管理者の組織情報から、実は関連会社からの社内アクセスだったことが分かるケースもあります。
4. Google検索
検索エンジンでの調査は、技術力がある人ほど忘れがちです。しかし王道中の王道です。過去に同様のアクセスを受けた事例があるかどうかをしらべます。
例えばIDSやIPSがトラヒックから攻撃を検知した場合でも、攻撃ではなくセキュリティベンダによる脆弱性スキャンだったというケースがあります。こういった場合は、幹部クラスへのエスカレーションは不要としてよいでしょう。この例のように、検索結果次第ではインシデントを鎮火することができます。
以上の4つは必須です。急いでいても最優先で調査をするべきです。
5. Black list検索
Spamhausなどが有名です。SBLは信頼でき、かつ更新がとても早いです。ただしSpamhaus DBLのような信頼度の低いリストもあるため、すべてのブラックリストを無条件で信頼するべきではありません。
6. GeoIP
MaxMind社のサービスが有名です。より詳細な所在の情報がわかります。
7. ping(疎通確認、応答時間)、traceroute
tracerouteによりどのようなISPを経由してアクセスが来たのかを推定できます。
pingやtracerouteはインシデントハンドリングにおいて必須ではありません。グリーンタグをつけるために、最後の判断材料として念のためするぐらいの扱いです。ICMPのecho replyを拒否する設定をしている場合もありますので、あまり信用できません。また、パケットが攻撃者に到達してしまうと、それを探知されるリスクがあります。
8. 情報源のプロトコル、レイヤ、ヘッダフィールドを確認する
IPアドレスは、OSIの7階層モデルにおけるネットワーク層で定義されています。しかしながら、例えばHTTPやSIPのように、ネットワーク層よりも上位層において利用されることもしばしばです(layering violationを参照)。IPアドレスを入手したときに、それがどのプロトコル、もしくはどのレイヤから得られたのかを確認することで、思わぬ落とし穴が目の前にあったとしても、それを回避できるかもしれません。
またプロキシやNATを経由する場合は、IPヘッダ上のIPアドレスが置換されてしまいます。x-forwarded-forヘッダフィールドなどの情報源となるヘッダフィールドの存在を知っておくとよいでしょう。
9. 名前ベースバーチャルホスト
1台のサーバで複数のドメインを運用することで、サーバの台数を減らしたり、貴重なIPv4アドレスを節約したりすることを名前ベースバーチャルホストと言います。また似たような事例として、CDN(Content Delivery Network)やクラウド型WAFなどのサービスでは、複数のサービスが同じIPアドレスを共有したり、アドレスが変わったりということが日常的に発生します。
サイバー攻撃の送信元IPアドレスがサーバであることはめったにありませんが、サーバが乗っ取られている可能性などを一応は考慮にいれるべきです。またダークネットの観測情報などを見る機会では、必須の知識となります。「Reverse IP Lookup」で検索してサービスを利用すると、同じIPアドレスを利用しているドメインを検索できます。日本語サイトが良ければこちらです。
10. Maritianアドレス&Martianパケット
悪意のある通信では、送信元IPアドレスがそもそも詐称されているおそれがあります。仮にそうでなくても、IPアドレスを見た瞬間にそれがRFCで定義された特殊なアドレス帯なのかに気づけるのがプロフェッショナルです。代表的なアドレス帯は覚えておくか、それとも調べる方法を確保しておきましょう。