実は知られていない?リスク対策の原則?

ISO 31000(リスクマネジメント標準規格)はa)からk)まで、11のリスク管理の原則を定めています。

ITエンジニアであればISO 27000(情報セキュリティマネジメント標準規格)を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎/基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。

情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。

リスク対策の原則が知られていない?ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。

続きを読む

H29年度 岡山大学ビジネスマインドセミナー ~ 知られざる情報セキュリティの危機的状況とその対策 ~

H29年度 岡山大学ビジネスマインドセミナー 「経営者/マネージャーが知るべきセキュリティ」

ここ5年ほど(?)行っている岡山大学ビジネスマインドセミナーの講師を本年も担当しています。今年は内容を大幅に更新しています。

席数は十分にあるはずなのでconnpassでも登録できるようにしました。今週末(11月11日土曜)13:00~です。お気軽に受講ください!

セミナー内容の一部紹介

本年度のセミナー内容を少しだけ紹介します。

  • 「セキュリティ設計」を考えてみたい方
  • 現状で「安心している」方
  • 現状で「安心できない」方
  • ITシステムを提供している方
  • ITシステムを利用している方
  • エンジニア/プログラマ/マネージャーの方

お待ちしています!

私のブログを読んでいる方は技術者が多いと思うので、少し技術よりの部分を紹介します。セミナーはプログラミング知識なしで理解できる内容になっています。

一枚一枚のスライドに紹介・説明すべき内容が多すぎて書ききれません。詳しくは受講をお願いします!

ソフトウェアセキュリティ対策の不思議 – 設計なしのセキュリティ対策

セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。

これは一般開発者の問題というより、セキュリティ専門家やセキュリティに詳しい開発者の問題でしょう。セキュリティ問題は十分に複雑な問題であることに異論はないと思います。複雑な問題を解くにはアーキテクチャー(構造化)と適切な設計が重要です。設計どころかアーキテクチャーさえないのは明らかに問題でしょう。設計となると細かな仕様が必要となります。ここではアーキテクチャーだけでも十分なのでこれだけを考慮します。

重要な事なので最初に書いておきます。セキュリティアーキテクチャー作る、は信頼境界線を書くことです。信頼境界の中に入れたモノ(入力やその他のモノ)であっても、普通は”何をしても安全なモノ”ではありません。安全性の為に更に詳細な入力検証が必要だったり、特定の権限を持つモノだけ許可したりするモノ、条件付きで信頼境界の中に入れるモノが普通にあります。また、信頼境界から出る時(出力)のセキュリティ対策は入力対策とは独立した対策です。これはよくある誤解なので注意しましょう。

信頼境界は”防衛線”です。”防衛線”での防御はITセキュリティ対策に限らず、全てのセキュリティ対策共通した防御策です。”防衛線”の”中に在るモノ”は”信頼できるモノ”であることを可能な限り保証します。”防衛線”を越えて”入るモノ”と”出るモノ”は可能な限り安全性を保証します。これが全てのセキュリティ対策共通の基本です。

 

続きを読む

ソフトウェアセキュリティのアンチパターン

アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。

このエントリは不定期にメンテナンスするつもりです。

続きを読む

なぜセキュアなシステムが作れないのか?

なぜセキュアなシステムが作れないのか?この問いは

なぜバグフリーのシステムが作れないのか?1

と同類の問いです。一定規模を超えると完全にバグ/問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ/問題がないシステムは簡単には作れません。しかし、バグ/問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。

このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。

ポイントは

  • 構造化が大事
  • 基礎が大事
  • 目的が大事

です。

続きを読む

PHP用入力バリデーションモジュール – validate

ブログで紹介するのを忘れていました。PHP用の入力バリデーションモジュール validateを作りました。

https://github.com/yohgaki/validate-php

PHP開発MLでの議論用に作ったので、作りかけと言える状態ですが、一応動作し使えます。

関数名はvalidate()の方が良いのでは?という意見があったので、名前は変更する予定です。valid()にしていた理由は”validate”だとあまりに一般的過ぎて、同じ名前の関数を定義しているユーザーがいるだろう、と予想したからです。自分のアプリやライブラリには名前空間を使うべきなので、モジュール関数はvalidate()にします。

いろいろ意見があったのですが、やはり入力処理における入力バリデーションとロジック処理の混同がありました。

入力処理における「形式的バリデーション」とロジック処理における「論理的/仕様的バリデーション」は別処理とした方が、構造的に優れています。この理由はまたの機会に書きます。

 

Python 2.7.14から学ぶセキュリティの基本

Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。

Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。

続きを読む