インフィニティソリューションズ株式会社ブログ

IEEEが指摘するソフトウェア設計上のセキュリティホールとその対策

ソフトウェアのバグについては常に注目されるものの、設計の段階でセキュリティについて意識していないケースが多々見られる。IEEE Center for Secure Designではソフトウェア設計上のセキュリティホールとその対策を10種類あげている。SD TImesの記事より。
1.Incorrect Trust Assumptions
認可、アクセスコントロール、セキュリティポリシー強化、個人情報をクライアントソフトウェア側に持たせないこと。ハッカーが見つけてしまうため。
2. Broken Authentication Mechanisms
当然ながらセキュアのソフトウェアの大きな目標の1つは、認証せずにデータアクセスされることがないようにすることだ。そのためには、複数の要素の使用、認証継続期間の限定と偽造不可化、システムへの保存をすること。
3. Neglecting to authorize after authentication
ユーザIDだけで、アクションをとっていいかどうかを決定づけることはできない。
初期認証後でも、認可を明示的なチェックとして行うこと。
4. Lack of strict separation between data and control instructions
データとコントロールを単一エンティティ、特に文字列に混合することは、インジェクション脆弱性につながる。
5. Not explicitly validating all data
ソフトウェアは多くの場合データに何らかの想定をしているが、設計者がそのような想定をしていることを確認していないと、脆弱性につながる。

Image courtesy of nipitphand at FreeDigitalPhotos.net

6. Misuse of cryptography
独自の暗号化アルゴリズム、ライブラリ・アルゴリズムの誤用、キー管理の不備、実際にはランダムではないランダム、暗号化に重きをおかない、アルゴリズムの採用を阻害するなど。
7. Failure to identify sensitive data and how they should be handled
データを正しく取り扱うには、設計者はデータの分類を特定し、すべての要因を設計に考慮に入れること。
8. Failure to consider the user
ソフトウェアシステムは人間が様々な形で操作するものであるため、あらゆるステークホルダーを常に顧慮に入れること。
9. Failing to anticipate how integrating external components can open a vulnerability
設計者とセキュリティアーキテクトは、外部コンポーネントがシステムに及ぼす影響に配慮する時間を確保すること。
10. Brittleness in the face of future changes
将来の変更も考慮した設計としておくこと。特にセキュリティアップデートおよびセキュリティプロパティの変更。