「セキュア・バイ・デザイン」はまずは1章を読んだ…#drc40

デッドライン読書会の第39回〜41回にかけてセキュア・バイ・デザインを読みすすめています。本当は今週末で3分の2に到達する予定でしたが、引き続き公私ともに忙しくなかなか本を読めない日々を送っています💦と言っても成果ゼロは悲しいので、気合で1章は読みました!そして1章が首肯する内容だったので、記録に残します。

セキュア・バイ・デザイン
セキュア・バイ・デザイン

セキュリティにおける心配事の分類は:CIA-T

CIAだけじゃなくてTもあったんですね。C=Confidentiality:機密性、I=Integrity:完全性、A=Availability:可用性、T=Traceability;追跡可能性。

ソフトウェア・セキュリティにおける従来のアプローチ

従来のアプローチでは、

開発者はXSS(Cross-Site Scripting)攻撃のような脆弱性についての知識を持っていなければならず、低レイヤーのプロトコルにおける脆弱性に注意を払い、「OWASP Top10」について熟知することが求められます。そして、テストをする際は、侵入テストに関する基本的なテクニックを習得していなくてはならず、ビジネス・ドメインのエキスパートはソフトウェア・セキュリティに関する議論や決定を行えることが求められます。

P.13 1.3 セキュリティにおける従来のアプローチとその欠点

これ、ものすごくよく分かる話なんだけど…。私もやや詳しい方だとは思いますが、それでも次々に現れる攻撃や、脆弱性、基準や改定されるルールについて準拠し続けるっていうのはとても大変です。これに対処する一つの案を本書が提示してくれるんですかねぇ。

ただ懸念としては本書を通して、ソフトウェアを設計面からセキュリティを強固にできるようになったとしても、それを外部から評価してもらうっていう役割分担は残るんではないかなぁ。そうなると、セキュリティに関する外部の関心事項を押さえ続けるのは引き続き重要な取り組みとして残りますかね。

多層セキュリティ(security in depth)

XMLパーサーへの攻撃(Billion Laughs攻撃)を想定した場合、次のような多層セキュリティで備えることができる。

  1. OWASPが推奨するXMLパーサーの設定
  2. 字句的内容(lexical content)の確認を行う
  3. XMLパーサーのプロセスに対して処理上の制約を加える

従来は1に目が行きがちだったが、セキュア・バイ・デザインの考え方に基づいて2(と3も?)における強固な作りを作ろうという話らしい。

次回は…?

次回は41回ですね。今度こそ少し落ち着くと思うので、巻き返しをがんばります!

コメント

タイトルとURLをコピーしました