組織と業務のセキュリティ

優れたセキュリティ対策の基礎は組織から始まります。

セキュリティ / プライバシー チームの設置

セキュリティとプライバシーの専任チームを設置し、この組織のリーダーを決めます。

  • セキュリティ チームを構築する
    • 少なくとも従業員 1 名がセキュリティ、プライバシー、インシデント対応に責任を持つようにします。
    • チームのミッションとスコープを設定します。
    • 次の職務について組織図に加え職務明細を作成します。セキュリティ マネージャー、セキュリティ エンジニア、インシデント マネージャー
    • この職務に就く従業員を雇用するか、外部に委託します。
  • セキュリティ開発ライフサイクル(SDL)を定義する。SDL には次の領域が含まれます。
    • サービスのセキュリティ要件。
    • リスク分析と脅威のモデル化。
    • アプリとコードの静的解析および動的解析
    • サービスの最終的なセキュリティ レビュー プロセス。
    • インシデント対応。
  • 組織のリスクを評価する。リスク評価を行い、リスクを除去または軽減する計画を立てます。

検証プロセスの構築

既存の内部ビルドの検証プロセスと承認プロセスのギャップを評価します。

  • 有害な可能性があるアプリ(PHA)をビルドに導入するおそれのあるギャップが既存のビルド検証プロセスにないか確認します。
  • AOSP に対する社内向けパッチであったとしてもコードのレビューと承認プロセスが必要です。
  • 次の領域にコントロールを実装して、ビルドの整合性を改善してください。
    • 変更のトラッキング。ソフトウェア エンジニアのトラッキング、変更ログの保持。
    • リスクの評価。アプリで使用される権限の評価、コードの変更に対する手動での確認の要求。
    • モニタリング。特権コードへの変更の審査。

ソースコードの変更のトラッキング

ソースコードやサードパーティ アプリ、バイナリ、SDK への意図しない変更を監視します。

  • パートナーシップの評価。次の手順に沿って、技術パートナーとの提携のリスクを評価します。
    • 特定のサプライヤーとの提携についてリスクを評価するための基準を作成します。
    • サプライヤーにインシデントの解決方法と、セキュリティとプライバシーの管理方法を尋ねるフォームを作成します。
    • 定期監査でサプライヤーの申し立てを確認します。
  • 変更のトラッキング。どの企業や従業員がソースコードを変更しているのか記録し、定期的な監査を行うことで、適切な変更のみが行われるようにします。
  • レコードの保存。どの企業がサードパーティのバイナリをビルドに追加したのか記録し、そのアプリが実行する機能と収集するデータを文書化します。
  • 計画の更新。サプライヤーがサービスの全期間にわたってソフトウェア アップデートを提供することが要件となるようにします。想定外の脆弱性によって、ベンダーの対応が必要な場合があります。

ソースコードの整合性と系統の検証

オリジナル デバイス メーカー(ODM)、無線アップデート(OTA)、携帯通信会社が提供するソースコードを確認して検証します。

  • 署名証明書を管理する
    • ハードウェア セキュリティ モジュール(HSM)または安全なクラウド サービスに鍵を保存します。共有はしないでください。
    • 署名証明書へのアクセスが管理され監査されるようします。
    • すべてのコード署名はビルドシステム内で行う必要があります。
    • 鍵を紛失した場合は取り消します。
    • おすすめの方法を使用して鍵を生成します。
  • 新しいコードを分析する。新たに追加されたコードをセキュリティ コード分析ツールでテストし、新たな脆弱性が導入されていないか確認します。 また、全体的な機能を分析して、新しい脆弱性の発生を検出します。
  • 公開前にレビューする。ソースコードとサードパーティ アプリのセキュリティ上の脆弱性がないか製品化前に確認します。次に例を示します。
    • アプリに安全な通信の使用を要件とする。
    • 最小権限の原則に従い、アプリの動作に必要な最小限の権限を付与する。
    • データが安全なチャネルに保存され、転送されるようにする。
    • サービスの依存関係を最新の状態に保つ。
    • セキュリティ パッチを SDK に適用し、ソース ライブラリを開く。

インシデント対応

Android は、問題発見には強力なセキュリティ コミュニティの力が役立つと考えています。デバイス固有のセキュリティに関する問題について、外部からの連絡手段を設定して公開する必要があります。

  • 連絡先を定める。security@your-company.com のようなメールアドレスか、お客様のサービスに関連する潜在的なセキュリティ上の問題を報告するための明確な手順が記載されたウェブサイト(例はこちら)を作成します。
  • 脆弱性報奨金プログラム(VRP)を確立する。脆弱性に関する有益な情報に対して報奨金を提供することにより、サービスに影響を及ぼすセキュリティ脆弱性レポートを送信してもらえるよう外部のセキュリティ研究者に働きかけることができます()。重大度のきわめて高い脆弱性については 5,000 ドル、重大度の高い脆弱性については 2,500 ドルなど、業界競争上の強みを持つ報奨金を研究者に提供することをおすすめします。
  • 変更点を上流に提供する。Android プラットフォームや複数のデバイス メーカー製のデバイスに影響するセキュリティ上の問題に気付いた場合は、セキュリティ バグレポートを使用して Android セキュリティ チームにお問い合わせください。
  • 適切なセキュリティ対策を推進する。お客様のデバイスにサービス、コンポーネント、コードを提供するハードウェア ベンダーやソフトウェア ベンダーのセキュリティ対策を事前に評価します。ベンダーが責任を持って適切なセキュリティ状況を維持するようにします。