リスク分析とリスク対応をしよう

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。

情報システムは「モノ」(物と人)、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。

当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない!といった場合も多いので仕方ない側面もあります。

しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。

※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

“リスク分析とリスク対応をしよう” の続きを読む
Facebook Comments

究極のセキュリティ要求事項とは?

前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。

  • Confidentiality – 機密性
  • Integrity – 完全性
  • Availability – 可用性
  • Reliability – 信頼性
  • Authenticity – 真正性
  • Non-repudiation – 否認防止 (Accountability – 責任追跡性)

これらが基礎的な情報セキュリティの要求事項になります。以上です。

※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335(古い情報セキュリティ標準)で定義していた要素に戻った形になりました。

これで終わってしまうと何の事なのか?究極の要求事項とは何なのか?となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。

“究極のセキュリティ要求事項とは?” の続きを読む
Facebook Comments

無視されているリスク分析

炎上プロジェクトの主な原因の1つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。

これと同じことが情報セキュリティ対策でも起きています。

致命的な脆弱性が残っているシステムの主たる原因の1つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。

漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。

  • ◯◯対策として△△を実施する

といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。

システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。

特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。

続きを読む
Facebook Comments

Railsのリモートコード実行脆弱性、今昔

去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。

ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。

“Railsのリモートコード実行脆弱性、今昔” の続きを読む
Facebook Comments

PHP用のCookieセッションセーブハンドラー

JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは

  • サーバー側のリソース(DBやファイルなど)を使わないので簡単にスケールする

ことにあります。

しかし、Cookieの保存は大きく分けて3つの問題があります。

  1. ネットワークが不安定だとデータが失われる場合がある(ネットワーク接続の問題)
  2. ロックがないのでデータが失われる場合がある(サーバー側の問題)
  3. 更新のタイミングによりデータが失われる場合がある(クライアント側の問題)

※ この問題はこのCookieを利用したセーブハンドラの問題ではなく、クッキー等のクライアント側にセッションデータを持たせるセッション管理の仕組み全般に存在します。

このハンドラーはデータ改ざんを検出するようになっており、Cookieの問題により改ざん攻撃と誤検出する可能性があります。

1、2は一般に広く認知されている問題でしょう。この場合はほぼ攻撃と誤検出されないと思われます。攻撃ではないのに攻撃と誤検出するのはほぼ3のケースだと考えられます。壊れ方によっては3ケースでも攻撃とは検出せず、仕様として単純にクッキーをリセットする場合もあります。タイミングによるデータ損失が100%攻撃と誤検出されるのではありません。

調べたのはしばらく前になりますが、タイミングによって失われるケースも完全に無視してよい程度ではありませんでした。これはブラウザのクッキー保存の実装コードの問題と考えられます。初期のバージョンはこの問題に対する緩和対策をしたコードにしていました。今は対タンパー性を上げる為にほぼ完全にバリデーションするコードになっています。(詳しくはコメント欄を参照)

どちらも一長一短で何とも言えないです。更新タイミングによるデータ損失が、どのブラウザで起きるのか、どのような使い方をすると起きるのか、どの程度あるのか、分らないので攻撃と誤検出するケースがある場合には教えていただけると助かります。※

※ 現コードはHMACで使用するクッキーをバリデーションしているので、更新タイミングによるデータ損失があると攻撃と誤検出します。きっちり正しく動作するコード ≠ きっちり厳格にバリデーションするコード、となる数少ないタイプのコードになります。ブラウザがRDBMSのトランザクションのように保存すれば済む話ですが。

“PHP用のCookieセッションセーブハンドラー” の続きを読む
Facebook Comments

データ検証をしない仕様には「脆弱性名」を付けた方が良いのでは? – 未検証入力

危険な脆弱性であっても名前を付けないとなかなか認知してもらえない、といったことがよくあります。「データ検証をしないアプリ仕様」は危険で脆弱な仕様ですが、基本的な対策を実装しない危険性はあまり認知されてないと思います。例えば、とんでもないGDPR制裁金を支払うといったリスクが高くなります。

名前が必要なのかも知れません。

実は新しく考えなくても既にOWASPが名前を付けています。

  • Unvalidated Input (未検証入力)

OWASP TOP 10 A1:2004 Unvalidated Inputとして第一番目の脆弱性として挙げています。

2007年版から消えていますが、これはセキュアコーディングとの兼ね合いで省略したのだと思われます。「2007年版から消えているので脆弱性ではなくなったのだ」とする自分勝手な解釈の解説を目にしたことがありますが、その2007年版には「リストから消したが変わらず重要な対策で、本年度版の脆弱性対策の手法としても記載」とする解説が書かれています。

標準的なセキュリティ対策の概念では「入力データ検証は非常に重要な脆弱性対策」です。

“データ検証をしない仕様には「脆弱性名」を付けた方が良いのでは? – 未検証入力” の続きを読む
Facebook Comments

ITセキュリティ対策の構造化

ITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか?

システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。

何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セキュリティ対策」に終始しています。

“ITセキュリティ対策の構造化” の続きを読む

Facebook Comments

入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0

基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。

Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義すれば、アプリケーション内で繰り返し同じ入力仕様をバリデーションできるように作られています。

Validate for PHPのスクリプト版をPre Alphaとしてリリースします。このブログのGitHubリポジトリのリンクは0.7.0ブランチに向いています。開発版はmasterブランチを参照してください。

“入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0” の続きを読む
Facebook Comments

それは”ただのバグ”なのか?それとも?

ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK!でしょうか?

ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。

“それは”ただのバグ”なのか?それとも?” の続きを読む
Facebook Comments

PHP 5.6.38他で修正された任意コンテンツ送信脆弱性について

PHP 5.6.38/7.0.32/7.1.22/7.2.10でApache2handler SAPIのセキュリティバグが修正されました。

13 Sep 2018
Apache2:

Fixed bug #76582 (XSS due to the header Transfer-Encoding: chunked).

http://php.net/ChangeLog-5.php#5.6.38

攻撃者が送った出鱈目な攻撃用データがPHPプログラムに関係なくブラウザに出力されてしまう問題が修正されました。

この脆弱性の影響が正しく伝わっていないようなので、簡単に紹介します。

“PHP 5.6.38他で修正された任意コンテンツ送信脆弱性について” の続きを読む
Facebook Comments

なぜWebセキュリティはここまでダメなのか?

インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。

この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。(もしくは気付いていても公開していない)

侵入されたことを検知/対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか?を考えます。

※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。

“なぜWebセキュリティはここまでダメなのか?” の続きを読む
Facebook Comments

データフロー分析とセキュリティ

データフロー分析とはコールフローグラフ(CFG)を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的(=プログラムを動作させず)にプログラム実行時のデータフローを分析し、問題を発見する手法です。

コールフローグラフ

データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料(PDF)が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。

“データフロー分析とセキュリティ” の続きを読む
Facebook Comments

ゼロトラストとフェイルファースト

今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念/原則を挙げるでしょうか?

私なら

  • ゼロトラスト
  • フェイルファースト

を挙げます。

極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。

もう一つ追加するなら

  • 多層防御(縦深防御)

を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。

これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念/原則と言えるかも知れません。

“ゼロトラストとフェイルファースト” の続きを読む
Facebook Comments

PHPのPharを使ったコード実行

phar(PHPプログラムを1つのアーカイブファイルにまとめて利用するファイル形式)のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。

pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。

BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。

“PHPのPharを使ったコード実行” の続きを読む
Facebook Comments

プライバシーの8原則

日本はOECD加盟国としてOECDプライバシー8原則を尊重する国です。OECDプライバシー8原則とは1980年にOECD(経済協力開発機構)で、個人情報保護の基本となる原則として定められました。

1980年頃には企業のオンライン化と顧客情報の集積が進むに伴い、個人のプライバシー情報を無制限に企業が利用することへの懸念が高まっていました。先進国間でプライバシーの概念が異なると困ります。先進国の間で同じ概念に基づくプライバシー保護を実現するためにプライバシー勧告が行われました。

“プライバシーの8原則” の続きを読む

Facebook Comments

セキュアコーディングの構造/原理/原則

セキュアコーディング/セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。

基本原理/基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。

IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。

“セキュアコーディングの構造/原理/原則” の続きを読む
Facebook Comments

日本政府「夏時間」に続き「夏温度」を導入

酷暑対策として「夏時間」の導入を決定した日本政府は新たな酷暑対策として「夏温度」の導入を検討することを発表した。夏時間(サマータイム)と同じく夏季の3ヶ月間は夏温度として20℃低い温度の使用を義務付け2020年から導入する。

政府関係者は「”夏時間”を導入するなら、同じ酷暑対策として”夏温度”を導入するのが道理だ。粛々と進める」とした。夏温度を推進する与党議員は「心頭を滅却すれば火もまた涼し、”夏温度”を導入すれば45℃の酷暑であっても25℃と快適温度となり、気持ちだけでも涼しくなる」と夏時間導入の意義を語った。

この方針に関して医療関係者は「人は気持ち次第で厳しい環境に対する耐性を向上させることが可能な場合もある。一定の効果があるのではないか?」「精神論かも知れないが、真面目な日本人なので気分を変えるだけで本当に良い効果が得られる可能性がある」とコメントした。

政府は気象庁のシステムに”夏温度のデータ”をそのまま保存することを要求することも分かった。”夏温度”期間中は政府および外郭機関は全ての温度データを”夏温度”で提供し、法律で”夏温度”利用を義務化する。

気象庁からの温度データは”夏温度”のまま提供されることになる。気象庁からのデータに依存する気象情報提供会社は「”夏温度”の利用が義務化されると気象データ管理システムの温度データが出鱈目になる」、ITシステムの専門家もシステム改修なしでは、気象関連システムに重大な問題を起こすとして強い懸念を示しました。

夏温度の利用を徹底するため、政府は夏温度期間中は全ての”温度”データを夏温度で保存することを義務化するとしている。

官房長官は”夏時間”の導入でさえオリンピックまでに完了できる。”夏温度”の影響範囲は限定されているとし、気象関連システム改修に関わらず”夏温度”の導入を進めるとした。

(もちろんフィクションです)
“日本政府「夏時間」に続き「夏温度」を導入” の続きを読む
Facebook Comments

日本政府が「夏重さ」の導入を決定

2018年8月14日、日本政府は東京オリンピックに合わせて夏季の期間に限り、1kgを1200gとする「夏重さ」の導入の検討に入ると発表した。

官房長官は「夏重さの導入により夏季の過剰なダイエットを防止できる効果が期待できる。国民の健康のために確実に導入したい。」と”夏重さ”導入にかける意気込みを語った。

特に若年層では夏季の過剰なダイエットが恒常的に行われており、成長期に於けるダイエットが問題化していた。夏季に限り1kgを1200gをすることにより50kgの体重は約41.7kgとなり、多くの若年層が理想の体重を見掛け上達成でき、過剰なダイエットを防止する効果が期待できるとしている。

”夏重さ”導入を巡ってはその実効性が疑問視されていた。政府は”夏重さ”の表記/導入を法律で義務付け、違反した場合には懲罰的罰金を課すことを検討している。”夏重さ”で表記していない製品1つあたり1万円程度の罰金が有力視されている。この罰金制度が実現した場合、1万個の製品を”夏重さ”に非対応で出荷した場合、1億円の罰金が課されることになる。

突然の罰金付き”夏重さ”導入に対し産業界からは「夏の間だけ重さの基準が変わるのは困る。夏重さ基準の導入には製品のラベル変更からITシステムの更新など負担が大きい。夏重さが終了後の製品ラベルなどはどうするのか?」「現状のシステムだと取引の際のkgが表記の重さが”夏重さ”なのか”冬重さ”なのか区別できなくなる」と困惑の声があがっている。

夏重さ導入を主導した”夏重さ導入を実現する会”会長は重さ基準の変更による影響に対し「コンピュータなどの重さ設定の変更は、律儀で真面目な国民ならば十分乗り切れるはず」「重さ感覚の違いの問題は、むしろ個人の心構えにより、多くは解消されるはず」とした。

(フィクションです)

サマータイムならぬサマーウェイトだったら?というフィクションです。

時期によって「重さ」の基準が変わると困ります。「時間」の基準が変わるサマータイムは夏時間/冬時間への「切りかえ時」のみの問題に見えますが、コンピューターにとっては「重さ」基準の切り換えが行われた場合と同じような変更が必要になります。

“日本政府が「夏重さ」の導入を決定” の続きを読む
Facebook Comments