党Aの安全保障体制の構築過程に関する考察

ブロガーはグラフィティセキュリティ部門の初期メンバーの1人であり、セキュリティ担当者ではありませんが、グラフィティセキュリティシステムの構築プロセスに最初から参加し、立ち会うことができて幸運です。この記事は、A党のセキュリティシステムの構築プロセスについてのブロガーの考えであり、3つの部分に分かれています。

1.安全システム構築v1.0 —クイックガバナンス
2.安全システム構築v2.0 —体系的な構築
3.安全システム構築v3.0 —完全に完璧な
添付:安全システム管理

同時に、パーティーAのセキュリティシステムの構築のために、2つの添付された実践ブログの投稿も書きました:
パーティーAの基本的なセキュリティ運用プラットフォームの構築プラクティス
SDLセキュリティとエンタープライズオフィスのセキュリティランディングプラクティス

1.セキュリティシステム構築v1.0—クイックガバナンス

多くのインターネット企業のビジネス開発は通常、セキュリティチームの構築に先行します。ビジネスが一定の規模に達し、セキュリティインシデントが発生した場合にのみ、セキュリティへの投資が検討されますが、現時点では、企業の情報セキュリティ環境の状態が非常に悪い場合、セキュリティはビジネスです会社の基本的な特性は、ビジネスの急速な発展に大きく遅れをとっています。

この時点で発生する可能性のあるセキュリティの問題は、企業のイントラネットに多くの脆弱なパスワードとパッチが適用されていないシステムが表示されること、オンラインサービスに多くの一般的なセキュリティの脆弱性があること、従業員のセキュリティに対する意識が低いこと、深刻なデータ漏洩などです...

現在企業が直面しているセキュリティリスクについては、簡単で低コストの明らかな効果から始めて、消火活動の迅速な解決策が必要です。

1.1安全担当者を選ぶ

通常、セキュリティチームは初期の1〜3人で構成されているため、セキュリティ担当者の幅広い知識が非常に重要です。担当者は、安全技術と安全操作、ならびに安全管理と安全コンプライアンスに精通している必要があります。セキュリティ担当者は、セキュリティチームがセキュリティの研究開発(オープンソースの二次開発に基づく)、侵入テスト、セキュリティ強化、緊急対応、セキュリティ監査、セキュリティトレーニング、セキュリティコンプライアンス、セキュリティ管理、セキュリティ運用などの作業を実行するように指導する必要があります。

1.2主要なセキュリティリスクの特定

迅速なガバナンスフェーズの主な目標は、リソースの20%を使用してセキュリティリスクの80%を解決することです。そのため、最初のステップは、メインのセキュリティリスクを特定することです。インターネット企業の特徴は、ビジネステクノロジーが主にWebおよびモバイルアプリケーションAPP(デスクトップソフトウェア、クラウドサービス、IoTハードウェアなども含む)であり、ビジネスの反復が速く、スタッフの変更が大きく、会社の管理が緩いことです。インターネット企業のセキュリティリスクのほとんどはオンラインビジネスに起因しており、いつでもリスクに直面しています。

1、在线业务

含むオンラインビジネスのリスクweb安全风险业务自身的安全风险移动应用安全风险

2、企业内部

セキュリティなど、企業内からリスク员工的安全风险口令的安全风险钓鱼攻击和社会工程学的安全风险安全合规风险これらのセキュリティリスクに加えて、ビジネスにおけるDDoS、ルーター、プリンター、パーソナルコンピューター、BYODデバイス(独自のデバイスを持ち込む)などのパッチされていないデバイスやツールなど、他の多くのセキュリティリスクがあります。

1.3迅速な削減を実施する

両手とハードハンドの原則、一方で安全技術と安全操作、他方で安全管理と安全コンプライアンス。安全性の問題をすばやく減らすための2つの方向からなるアプローチ。

解决web安全风险可采取的处理方式按优先级排序依次为:

1.サイト全体でWebshel​​lバックドアをクリアし、オープンソースWAFを購入または使用して、一般的なWebセキュリティの問題をすばやく解決します
。2。動的アプリケーションセキュリティテスト、静的アプリケーションセキュリティテスト、およびインタラクティブアプリケーションセキュリティテスト製品を使用して、Webサービスのブラックボックススキャンおよびホワイトボックススキャンを実行します。主要なオンライン脆弱性を解決するためのスキャンおよび手動侵入テスト;
3. Prevoty、OpenRASPなどのRASP(ランタイムアプリケーションセルフプロテクション)を展開する場合、Webの自己免疫保護には自己保護製品を使用する必要があります。;
4.セキュリティコードフィルタリングライブラリを提供するまた、コードのセキュリティ品質を向上させるためのセキュリティコーディングトレーニングなど。

解决来自业务的安全风险可采取的处理方式按优先级排序依次为:

1.最初に、ビジネス特性に基づいて適切なサードパーティのリスクコントロールセキュリティ製品を選択します
。2。担当者が配置された後、アクセス層(クエリエンジン、ルールエンジン、モデルエンジン)、処理層、およびデータ層から独自の製品を構築できます。セキュリティリスク管理プラットフォーム。

解决移动应用安全风险可采取的处理方式按优先级排序依次为:

1.ビジネスソリューション(無料/有料)を使用して、一般的なセキュリティ問題を解決するためにAPPの脆弱性スキャンとセキュリティ強化を実行します
。2。モバイルアプリケーションのセキュリティ技術に精通したセキュリティチームのメンバーが、モバイルアプリケーションの詳細な手動セキュリティテストを実施し
ます。3。提供します基本的なモバイルセキュリティコンポーネントとセキュリティコーディングのトレーニング、セキュリティコーディングの仕様。

解决来自员工的安全风险可采取的处理方式按优先级排序依次为:

; 1、EDRセキュリティ製品の導入は、本番環境でのデータベース管理システムの監査データベース・アクセスの使用を遠隔監査管理のための要塞を使用して統合管理、統一することができます
雇用前に主要な従業員の背景を募集したときに2、安全教育を調査は、情報セキュリティ担当者は、行動や検査のコードを開発するために、従業員が去るとき、彼らの安全指示を通知し、セキュリティ監査の必要性;
3、検疫制御ネットワークを確立するために、企業のビジネスチームの焦点は、インターネットにアクセスするためにプロキシサーバーを統一し、HTTPSを含めるようにしてくださいネットワークトラフィックを含めて監査できます;
4、Splunk製品のUEBAモジュールなど、機械学習ベースのユーザー異常行動発見システムの確立。

解决口令安全风险可采取的处理方式按优先级排序依次为:

1.脆弱なパスワードスキャナー(Hydra / Medusa)を使用して、会社の従業員アカウントとイントラネット(SSH、MySQL、RDP、Webバックグラウンドなど)のパスワードに関連するすべてのシステムサービスを検出し、脆弱なパスワードの潜在的な危険をすばやく解決するためにパスワードを変更するように命令します
。 OpenLDAPに基づく統合シングルサインオンシステムを構築し、動的パスワード2要素認証またはTOTPスキームに基づくRSAキーを使用します。Wi-Fiテクノロジーを使用する場合、Radiusプロトコルを介して2要素認証を実現できます。3.
より厳格なFidoベースの認証を確立します。U2F認証プロトコルエンティティセキュリティキーログインシステムおよびBeyondCorpアカウントセキュリティシステム。

解决来自钓鱼攻击和社会工程学的安全风险可采取的处理方式按优先级排序依次为:

1.従業員に関連するセキュリティ意識向上トレーニングを実施し、関連するドリルテストを随時整理してトレーニング効果を検証し、物理的なセキュリティ管理とオフィス構内の制御を強化し、サードパーティの通信ソフトウェアの使用を回避してワーキンググループを確立します
。2、フィッシング攻撃を強化し、ソーシャルエンジニアリングを使用します。攻撃の技術的な監視(端末のセキュリティ監視など)を実行します。リスクの高いファイルを表示する場合は、サンドボックステクノロジを使用してアクセスを分離できます。Webを閲覧するリスクの高い操作には、リモートの安全な閲覧製品を使用できます
。3。BYODデバイスのセキュリティ管理を強化します。 。

解决安全合规认证可采取的处理方式按优先级排序依次为:

1.公式のセキュリティコンプライアンスドキュメントを読んで、セキュリティコンプライアンスの要件を理解します
。2。セキュリティコンプライアンスに必要なドキュメントをリストし、セキュリティコンプライアンスドキュメントを書きます。3。
企業がすでに満たしていて、まだ満たしていない要件を特定します実装計画の策定に失敗しました;
4.内部規制に対する外部規制、検査に対する内部規制、修正のための検査、評価原則への修正、上陸を促進するため;
5.コンプライアンス認証に合格し、コンプライアンス証明書を取得します。

2.セキュリティシステム構築v2.0-体系的な構築

消防ラピッドガバナンスの第1段階の後、企業の隠れた危険のほとんどは基本的に排除されたので、第2段階では、企業のセキュリティ構造を体系的に改善し、「システムのセキュリティ」のセキュリティ概念を実装できます。

2.1 ISMSに基づく安全管理システムの確立

ISMSは、特にISO 27001〜ISO 27013の一連の規格で構成されており、その中でISO 27001は業界で最もよく知られています。ISO 27001は主に情報セキュリティ管理システムの要件を規定しています。これは主に、一般的に認証に使用されるいくつかの概念の紹介と概要です。ISO 27002は、ISO 27001に対応する詳細なプラクティスです。この規格は、14のフィールドと113の管理対策をカバーしています。

ISMSは、大規模で包括的なガイダンス要件フレームワークを提供します。これは、インターネットエンタープライズセキュリティチームに役立ちます。

1.不十分なセキュリティカバレッジによって引き起こされる死角を回避するための包括的なセキュリティビューを提供する
2.セキュリティ戦略の実装を容易にするために経営幹部に説明責任のある情報セキュリティ実装基盤を提供する
3. ISO 27001認証を取得すると、改善できる会社の人気と信頼により、顧客は会社に自信を持っています。

ISMSはPDCAサイクルの原則に基づいています。

P即Plan(计划)リスク管理と情報セキュリティの改善に関連するポリシー、ISMSの目的、プロセス、手順を策定し、組織のグローバルなポリシーと目的と一致する結果を提供し
D即Do(实施)ます。ISMSポリシーを実装および使用して、プロセスと手順を制御し
C即Check(检查)ます。検査プロセスの間、プロセスはそれに応じて評価され、プロセスのパフォーマンスはポリシー、目標、および適切な場合は実際の経験に従って測定され、結果はレビューのために経営陣に報告されます。
A即Act(行动)ISMSの内部監査の結果や経営レビューなどの情報をもとに、上記体制の継続的な改善を図るため、是正・予防の対策を講じています。

安全管理体制については具体可以依照ISO 27001的14个控制领域开展、ISMSにチェックフォームを提供することで、対応するモジュールを1つずつ記入し、相互に確認を行うことで、ほぼ完了した段階で安全管理体制が構築されます。

安全管理は複雑ですが、変更は不可分であり、コンプライアンス要件と規則や規制を完全に理解し、会社の実装のリスクと欠点を発見し、最終的にリスクの修正と解決を完了する必要があります。

2.2 BSIMMに基づいてセキュリティエンジニアリングを構築する機能

1. BSIMMの概要

BSIMMは、ソフトウェアが安全かどうかを測定する尺度です。BSIMM標準を使用して、独自のセキュリティ開発と構築を実装できます。BSIMMは、3つの主要な部分で構成されています。

1.ソフトウェアセキュリティフレームワーク(SSF):BSIMMをサポートするインフラストラクチャは、4つの領域に分割された12の実用的なモジュールで構成されます;
2.ソフトウェアセキュリティグループ(SSG):ソフトウェアセキュリティの実装と促進を担当する内部ワーキンググループ;
3。ソフトウェアセキュリティ計画(SSI):組織全体をカバーするプロジェクトで、ソフトウェアセキュリティ活動を調整、導入、評価、管理、および進化させます。

ソフトウェアセキュリティフレームワークの4つの領域にある12の実用的なモジュール:

ガバナンス 知性 SSDLの連絡先 配置する
戦略と指標(SM) 攻撃モデル(TM) アーキテクチャ分析(AA) 侵入テスト(PT)
コンプライアンスとポリシー(CP) セキュリティ機能と設計(SFD) コード監査(CR) ソフトウェア環境(SE)
トレーニング(T) 規格と要件(SR) 安全試験(ST) 構成およびセキュリティ脆弱性管理(CMVM)

治理:ソフトウェアセキュリティプログラムの組織、管理、評価を支援するために使用されるプラクティス、および人材育成も、ガバナンス分野の中核的なプラクティスです。
情报:将来のセキュリティガイダンスと脅威のモデリングは、ソフトウェアセキュリティアクティビティを実行するために企業の企業知識を収集するために使用される手法です。
SSDL触点:特定のソフトウェア開発作業とプロセスに関連するプラクティスを分析して保護します。
部署:従来のネットワークセキュリティおよびソフトウェアメンテナンス組織を扱う慣行では、ソフトウェアの構成、メンテナンス、およびその他の環境問題がソフトウェアセキュリティに直接影響します。

2.安全工学の能力開発における一般的な問題の解決策

質問1:オンラインサービスの時間は厳しくプレッシャーが高く、セキュリティの脆弱性を修正するのに時間がかかりすぎるため、オンラインサービスの進行状況に影響します

安全作業が開発のボトルネックになるのを避けるために、安全テスト技術は、可能な限り既存のシステムと統合する必要があります。たとえば、SpotBugsプラグインがIDEに直接統合されている場合、開発者はコンパイル時に脆弱性コードを変更するように求められる可能性があります。サードパーティコンポーネントの脆弱性を管理する場合、BlackDuckとMavenリポジトリを組み合わせることができます。ビジネス担当者は介入なしにJavaライブラリを解決できます。セキュリティの問題。コードをGitLabに送信するときに、Gitrobを追加して、キー、パスワード、その他の機密情報の漏えいの問題を自動的にスキャンします。CIプラットフォーム(Jenkinsなど)にFacebook Inferを統合して、スキャンのクラスターを形成し、コードの脆弱性を自動的に検出してPythonスクリプトを記述します。脆弱性情報をJIRAに送信し、R&D担当者に修正してバグ修正の進捗状況を追跡するよう通知します。

質問2:セキュリティ違反に関する誤認が多すぎる

自動安全テストシステムを最初に起動したときに、誤警報の問題が発生する可能性があります。このような問題に対しては、誤検知フィードバック機能を設計し、安全技術サポートを提供する専任の安全チームを編成し、検出ルールの継続的な最適化に参加させることができます。数回繰り返した後、誤検知の問題は基本的に解決できます。

質問3:会社には従業員の仕事の定量的な指標がなく、一部のR&Dチームメンバーは責任感が不十分であり、バグ修正に関心がないため、多くの隠れたセキュリティリスクが残っています

脆弱性の修復に関連するプロセスシステムを確立し、コード品質をKPIにリンクし、脆弱性のレベルに応じてプロセスシステムの違反によりセキュリティリスクを隠している従業員を罰します。プロジェクトの品質レポートを定期的に送信する品質保証チームと組み合わせて、セキュリティの脆弱性データが最終的にコード品質管理プラットフォームに集約されます。バグ修正をKPIインジケーターに入れて、セキュリティの脆弱性を修正する開発者の熱意を促進します。

質問4:セキュリティソリューションと要件は、しばしばビジネス開発を妨げます

セキュリティ計画と要件を設計するとき、セキュリティチームはセキュリティチームが時間と労力を節約して責任を引き受けることから始めるべきではありません。これはビジネス開発を妨げ、効率を低下させます。一連のセキュリティスキームと要件は、ビジネス開発が削減された場合でも削減されなかった場合でも安全を確保できなければならず、そのようなスキームと要件のみがビジネスチームと開発および保守チームによって歓迎されます。

3.ユニバーサルセキュリティテクノロジーアーキテクチャを構築する

ネットワーク層:
NTAネットワークトラフィック分析では、AOLオープンソースMolochなどがredborderあり、詐欺防御では、Thinkst OpenCanaryおよびCanarytokens

ホスト層:
オープンソース製品にはFacebookがありますOsquery

アプリケーション層:
Baiduのオープンソース製品OpenRASP

IDとアクセス権の管理:
オープンソース製品はgluu

データのセキュリティとプライバシー:
きめ細かな権利管理を備えたオープンソース製品、Apache Rangerビッグデータのセキュリティとパフォーマンス分析を備えたオープンソース製品Apache Eagle、およびオープンソースの鍵管理システムVault

安全な運用:
オープンソース製品にはMozillaオープンソースSIEMプラットフォームが含まれますMozDef

3.セキュリティシステム構築v3.0-完全な改善

システムセキュリティ構築の第二段階以降、企業は基本的に完全なセキュリティシステムを構築しているため、セキュリティシステム構築の第三段階は主にそれを包括的に改善することです。

3.1安全文化の構築を強化する

企業の安全文化を構築する方法は?安全は会社の価値観に組み込まれ、パフォーマンスとともに評価されるべきです。企業文化が壁に貼られていて、それを評価する方法がわからない場合、企業文化はほとんど効果がありません。会社の安全文化が確立されて初めて、会社は人事異動のために安全値を徐々に希釈することはありません。

3.2セキュリティと回復力のフレームワークを改善する

セキュリティと復元力のアーキテクチャは、主に4つの機能を実装しています。

1.情報に基づいた侵入の準備を予測して維持する
能力2. 侵入された場合でも耐えられる能力は、基本的なタスクまたはビジネス機能を引き続き実行できる;
3.回復力、侵入中および侵入後のタスクまたはビジネス機能を復元する;
4.適応タスクまたはビジネス機能のサポート機能を変更して、テクノロジー、運用、脅威環境の変化を予測する能力。

添付:セキュリティシステム管理

システムは通常、記事の形式で表示され、名前は通常、ポリシー、規制、方法、手順、ルール、ガイドラインなどのタイトルが付けられます。システムは、記事または非記事の形式で表示できるシステムパッチによって調整、補足、改善できます。通常、改訂通知、補足通知、強化管理通知などのタイトルに反映されます。

1.制度的システム

システムは、合理的な構造、明確な階層、包括的なカバレッジの原則に従う必要があります。システムには通常、次の3つのレベルが含まれます。

1.政策レベルのシステムとは、事業部門の運営および管理責任の基本的な事項を規制するために使用されるシステムを指し、名前の一般的な使用は、システム、規制、方針、規制などです。

2.方式レベル体系とは、業務方法や事業内容の具体的な内容を統一するための制度であり、一般的には管理手法や管理手順を用いた名称です。

3.規制レベルのシステムは、特定の運用内容を標準化するために使用され、その名前は、通常、運用規制、運用ルール、実装ルール、ガイドラインなどを使用します。

2.システムの起草

システム構築の過程では、システムの必要性、有効性、合理性、運用性を実証するために、システム導入部門の担当者や部門内の関係者の意見を広く募る調査・研究を行うべきである。意見募集は、募集メールの送信やシステム協議会の開催などにより行うことができます。

システムの内容には通常、一般的なルール(目的の根拠、適用範囲、管理の原則、責任の区分、定義などを含む)、管理プロセス、監督、検査と罰のルール、および補足的なルール(詳細なルールの要件、解釈部門、実施日、無効化ステートメントなど)が含まれます。 。

3.システムレビュー

システムレビューには、主に以下が含まれます。

1.法律、規則、ガイドライン、規制要件に準拠しているかどうか
2.会社の関連システムとのインターフェースとの整合性が明確
かどうか3.会社の全体的なシステム構造の合理性と明確性に影響している
かどうか4.システム記述のプロセスかどうか明快さと操作性;
5.それが会社のシステムの規範的な要件を満たしているかどうか;
6.レビュー担当者は、検討する他のシステム問題についてのレビュー意見を提出できます。

4.システムのリリース

見直し、見直し、承認された制度は、全従業員に通知する形で発行され、制度の維持管理を容易にするため、原則として1つのシンボルの制度とする。主催者は、システムの実施日を合理的に決定し、システムで明確にする必要があります。「この記事の発行日からの実施」ではなく、直接実施日を明確にすることをお勧めします。

5.システムメンテナンス

システムのメンテナンスには、その後のシステムの評価と改善が含まれます。システムのフォローアップ評価とは、システムの問題点を発見し、是正の必要性を評価することを目的とした、スポンサー部門による実際のシステム運用効果の自己評価です。フォローアップ評価には以下が含まれます。

1.コンプライアンス、有効性、操作性、標準化などのシステムの問題があるかどうか
2.
システム間に重複や矛盾があるかどうか3.システムや管理の盲点がないかどうか
4.システムを分類して調べるシステムのパッチ状況、統合の実装の実現可能性と必要性​​を評価します。

幹部レベルで多くの意見を反映するシステムの場合、スポンサーはフォローアップ評価をタイムリーに実施する必要があります。同時に、受入部門は、システムの後続の評価の効率と品質を向上させるために、システム情報を適時に収集および整理する必要があります。システム情報には、外部ポリシーの変更、草の根のオペレーターからのフィードバック、ビジネス検査で発見された管理の脆弱性、外部またはピアケースに反映された管理の脆弱性、内部組織構造、管理、およびビジネスプロセスの調整が含まれます。

システム改善とは、システムの事後評価結果や事業運営ニーズに応じて、受入部門が実施するシステムの追加・変更・修正・補足・統合などの作業を指します。システム改善作業を実装する前に、ホスト部門は、システムの安定性と実装の利便性を考慮して、システム改善のコストを評価し、システムパッチの発行、新しいシステムの追加、バージョンの変更を選択してシステムを改善する必要があります。システムに多数のパッチがある場合、スポンサー部門はシステムを部門のシステム構造の配置と統合するものとします。

6.システムの日常管理

解釈については、システムが明確に説明する必要があり、原則としてシステムの担当部署が担当し、特別な場合は各部の解釈の範囲を明確にすべきである。低レベルのシステムが高レベルのシステムの規制と矛盾する場合、システム解釈部門が別の方法で正式に承認または回答しない限り、高レベルのシステムの規定が優先されます。

公開された234元の記事 ウォンの賞賛1264 ビュー23万+

おすすめ

転載: blog.csdn.net/wutianxu123/article/details/104404999