いかなるデータや情報処理も、ソフトウェアなしでは運用できない。ソフトウェア開発は、主にアルゴリズムのタスク固有の機能に焦点を当てている。しかし、プログラムコードの書き方が悪いと、誤ったアクセス制御、SQLインジェクション、不正なセッション管理と認証、クロスサイト・スクリプティングなど、セキュリティ上の問題が生じることが多いことは、今やよく知られている。
安全なコーディングの実践の重要性は、情報セキュリティ規格ISO/IEC 27002およびISO/IEC 27001:2022の更新で強調されている。新たな情報セキュリティ対策（管理）として、ソフトウェア開発における「セキュアコーディング」の原則が、ISO/IEC 27001の附属書Aの対策のカタログに加わりました。この対策が情報セキュリティにとってどのような意味を持つのか、また、この対策が今後の監査にどのような意味を持つのかについては、ブログ記事をご覧ください。
オペレーティング・システム・ソフトウェア、アプリケーション・ソフトウェア、または組み込みシステムのファームウェアは、あらゆるデジタル・インフラストラクチャの基本的な構成要素です。しかし、デジタル化プロジェクトの加速と納期のプレッシャーの増大により、情報セキュリティの重要な側面が軽視されがちです。ソフトウェアの開発要件は通常、機能中心で建設的な側面を重視するため、潜在的なセキュリティ脆弱性に対する破壊的な見方は、実際の開発目標とは正反対であることがほとんどである。
このような状況下では、開発チームはソフトウェアのコーディングを継続的に見直し、一貫して安全性を確保することが困難である。これは、非営利団体であるMITRE Corporationが毎年CVE（Common Vulnerabilities and Exposures）リストで公表している多くの脆弱性からも明らかである。有名なソフトウェア・メーカーでさえ、定期的なセキュリティ・パッチを提供していることは、市場に投入される前にセキュリティに関連するバグを特定することはおろか、バグを修正することがいかに困難な作業であるかを示している。
自分で開発したソフトウェアをコーディングするとき、プログラマーはオープンソースのライブラリやモジュールに頼りたがる。何度も車輪を再発明する必要がなければ、技術の向上、開発の迅速化、開発コストの削減、オープンソースコードによる透明性の向上、オープンな標準やインターフェイスによる相互運用性の向上といった恩恵を受けることができるからだ。
また、オープンソースのコードは、多くのユーザーによって検証され、オープンソースコミュニティの群知能が迅速かつ効率的なバグ修正を可能にするため、高度なセキュリティを提供するとよく言われる。
実際には、この信頼は差別化された重大な方法で評価されなければならない。最も深刻な例は、2021年11月に発見された、Javaアプリケーションで広く使われているロギング・ライブラリLog4Jのゼロデイ・セキュリティ脆弱性Log4Shellである。ドイツ連邦情報セキュリティ局（BSI）がLog4Shellに対して赤の警告レベルを出したことはご存知だろう。Apache Foundationを通じて確実に機能する準標準として配布されているLog4Jライブラリは、2013年以来、Amazon AWSのような有名なウェブサービスを含む多くのシステムでその地位を確立している。
これらのよく開発され、また保守されているライブラリの複雑さは、暗黙のうちに、インポートする開発者が自分の組み合わせた新しい開発ではしばしば気づかないが、攻撃者に悪用される可能性のある強力な機能性を提供している。
オープンソースコンポーネントのもう1つの不安要素は、いわゆるサプライチェーン攻撃、つまり、オープンソースコミュニティの一員を装い、コード開発を支援する悪意のあるアクターによる意図的な組み込み脆弱性である。このような脆弱性は、ハッカーにとって、川下の多数のユーザー組織を攻撃する極めて効率的な方法である。Sonatype社の調査によると、2020年と2021年を比較した場合、この攻撃ベクトルは650％増加すると診断されている。
ソフトウェア開発プロセスをタイムリーに保護するために、国際標準化機構（ISO - committee ISO/IEC JTC 1/SC 27）は、新しいISO/IEC 27002およびISO/IEC 27001:2022の附属書A規格に、新しい管理8.28として「安全なコーディング」を盛り込みました。セキュアコーディングの技術的対策の目的は、ソフトウェアの予防的保護である。
最小限のセキュリティレベルは、手続き規定に基づき、記述段階の早い段階で作成され、その結果、ソフトウェアの潜在的なセキュリティ脆弱性の数を最小化する。安全なコード生成のための規制の枠組みは、自社のプログラムコードと、サードパーティやオープンソースソースからのソフトウェアの両方に総合的に適用される。実装のための注目すべき原則は、「セキュリティー・バイ・デザイン（Security by Design）」と「最小特権（Least Privilege）」であり、これらはコーディングにおいても考慮されなければならない。
小節 8.28 では、いわゆるセキュアコーディングの原則を何度か取り上げています。セキュアコーディングのためのガイドとベストプラクティスを定期的に発行している数多くの組織や機関によって、これらのガイダンスが提供されています。例えば、OWASP Foundation のSecure Coding Practices、Software Engineering Institute (SEI)の Computer Emergency Response Team (CERT)の Secure Coding Standards、ドイツの BSI の Web アプリケーションのセキュリティ対策のカタログなどです。出典が異なるにもかかわらず、例えば、以下の点に関して、多くの類似点が見られます：
ISO/ISO 27002:2022規格では、管理8.28の推奨事項を「計画と事前コーディング」、「コーディング中」、「検証と保守」の3つのセクションに分け、その中心的な内容を以下に概説する。
現代の情報リスクに適応したISO/IEC 27001の新版が2022年10月25日に発行された。これは、規格のユーザーにとって何を意味するのでしょうか。無料のウェビナーでは、以下についてご紹介します。
新規のコード開発とコードの再利用の両方において、セキュアコーディングの原則を適用する必要がある。そのためには、組織特有の期待事項を評価し、認識された原則を事前に定義する必要がある。加えて、計画と事前コーディングのための推奨されるアクションは、既知の一般的かつ過去のコーディング慣行と、脆弱性につながる可能性のあるエラーを考慮に入れている。
統合開発環境（IDE）におけるルールベースなどの開発ツールの構成は、安全なコードの作成を強制すべきである。極めて重要なのは、開発者の資質と、安全なアーキテクチャとプログラミング標準に精通していることである。開発チームに情報セキュリティの専門家を含めることは言うまでもない。
コーディングプロセスでは、特定のユースケースとそのセキュリティニーズを考慮した上で、コーディングプラクティスと構造化プログラミング技法が主要な役割を果たす。例えば、ハードコードされたパスワードのような安全でない設計技法は、一貫して禁止されるべきである。コードは、セキュリティ関連のバグを排除するために、適切に文書化され、レ ビューされるべきである。コードのレビューは、静的アプリケーショ ン・セキュリティ・テスト（SAST：Static Application Security Testing）ま たはそれに類似した方法で、開発中と開発後の両方に実施する。静的テスト手法は、ライフサイクルの左側にシフトして、目に見えるコードのルール適合性を早期にテストすることで、シフトレフトアプローチ（「早期か つ頻繁にテストする」）を支援します。
これによって、汚染されたコード、ファイルや特定のオブジェクトクラスへの接続、あるいはサードパーティ製プログラムとの気づかれない相互作用のために悪用される可能性のあるアプリケーションレベルのギャップを、悪用可能な脆弱性として早期に特定することができる。ソフトウェアを運用する前に、コントロール8.28は攻撃対象の評価と最小特権原則の実施を要求する。最も一般的なプログラミングエラーの分析と、その修正に関する文書化を評価すること。
ソフトウェアが稼動した後でも、安全なコーディングの話題は関連し続ける。これには、コードの既知の脆弱性のチェックだけでなく、安全なアップデートも含まれる。さらに、必要な調整を迅速に行うことができるように、エラーや攻撃の疑いを文書化しなければならない。いずれにせよ、ソースコードへの不正アクセスは、適切なツールによって確実に防がなければならない。
検証・保守の分野では、小節8.28に、オープンソースソフトウェアのような外部ツールやライブラリの使用に関する明示的な指示が追加されている。これらのコード・コンポーネントは、インベントリで管理、更新、保守されるべきである。これは、例えば、ソフトウェア部品表（SBOM）を通じて行うことができる。SBOMは、ソフトウェアのパッケージとライブラリ、およびそれらの相互関係やサプライチェーン内の関係を、形式的かつ構造的に記録したもので、特に再利用コードやオープンソースコンポーネントを追跡するためのものである。SBOMは、ソフトウェアの保守性と標的型セキュリティ更新をサポートする。
ISO 27001に基づくISMS認証を取得するには、どのような努力が必要でしょうか。無料かつ義務なしで情報を入手してください。
ご相談をお待ちしております。
セキュアなコードは、潜在的な攻撃を阻止するための基本的な基盤です。新しいコントロール8.28は、この長年の洞察を考慮し、情報セキュリティにおけるセキュアコーディングの重要な役割をアップグレードしている。しかし、この対策は、多くの詳細な推奨事項から構成され、技術的に厳しいものであるため、その実施には比較的高いレベルの労力が必要となります。
私たちは、経験豊富な監査員の専門的な見地から、この措置の確実な実施をサポートします。ISO/IEC27001:2022規格に準拠した情報セキュリティおよび認証のテーマについて、35年以上にわたる監査および認証の専門知識を持つ当社が、お客様の理想的なコンタクトパートナーとして、喜んでお手伝いいたします。
移行期間により、企業は自社のISMSを新しい要求事項に適合させ、認証を取得するのに十分な時間があります。しかし、変更プロセス全体の期間と労力を過小評価してはなりません。安全策を講じたいのであれば、早め早めに対処し、必要であれば経験豊富な専門家に依頼すべきです。
35年以上の専門知識を持つ審査・認証のエキスパートとして、デルタ審査の一環として、貴社の現状評価を喜んでサポートいたします。経験豊富な審査員から、最も重要な変更点と貴社組織との関連性をご確認ください。また、改善の可能性を検討し、新しい認証書を受け取るまでサポートいたします。情報セキュリティにおける当社の能力をご活用ください！ご連絡をお待ちしております。
DQSの製品管理・認定部門で、情報セキュリティの専門家および審査員として勤務している。30年以上の経験を持ち、最初は原子力施設の放射線防護の専門家として、次にISMSの審査員および認証機関副マネージャーとして活躍しました。この職務において、情報セキュリティの専門知識（ISO/IEC 27001、ドイツエネルギー産業法（EnWG）11.1aに基づくITセキュリティカタログ）をドイツの認定機関DAkkSや多くの顧客監査で実証しました。
