本記事は『AWS継続的セキュリティ実践ガイド ログの収集／分析による監視体制の構築』（日比野恒）の「Chapter 1：継続的セキュリティとは」から一部を抜粋したものです。掲載にあたって編集しています。
継続的セキュリティの必要性
クラウドの概念が浸透し、新規に導入するシステムではクラウドを前提としたアーキテクチャを採用することが増えてきました。日本国政府は、2018年に「政府情報システムにおけるクラウドサービスの利用に係る基本方針」において「クラウド・バイ・デフォルト原則」という言葉を使い、政府のシステム導入にはクラウドサービスの利用を第一候補とする方針を打ち出しています。
クラウドの登場により、システムにかかるコストの考え方が設備投資から経費に変わりました。所有から利用へのシフト、クラウドの特徴である「オンデマンド／セルフサービス」や「スピーディな拡張性」は、ビジネスにアジリティ（俊敏性）を提供することになりました。
そこでまず、アジリティを得たことによりビジネスはどのように変化してきたのか、なぜ継続的セキュリティが必要になってきたのかを解説します。
年次サイクルの限界
近年、ビジネスの変化スピードは日増しに速くなっています。新しいアプリケーションやサービスが登場しては消え、またすぐに新しいものが登場するといったように、マーケットの寿命が短命になってきていると感じます。そのため、システムを開発するユーザー企業としても、いち早く市場に製品やサービスを投入しなければマーケットを獲得できなくなってきました。クラウドの利用が進むひとつの要因として、ビジネスの変化のスピードが加速度的に上がっていることが挙げられるのではないでしょうか。
また、クラウド上で展開されるアプリケーションの開発手法や開発技法についても、そのトレンドは大きく変化してきています。開発手法はウォーターフォール型からアジャイル型への移行、開発技法はマイクロサービスアーキテクチャ（図1）を採用する企業が増えてきました。どちらが優れているというものではありませんが、ビジネスの変化に対応するための手段として、重要な要素となっていることは確かでしょう。
ビジネスの変化のスピードにシステムが対応できるようになってきたことで、新機能のリリースは年単位から週単位へと劇的に短くできるようになりました。一方、この技術的な進歩は、企業のセキュリティを脅かす悪意ある攻撃者にとっても、その攻撃の進化に寄与することとなりました。
セキュリティの新たな脅威（攻撃手法）が次々に開発され、脆弱性が公開されてから攻撃が開始されるまでの期間が劇的に短くなって、いわゆるイタチごっこの状態になっています。ITがビジネスを支えるツールとして欠かせない存在となったことで、サイバー犯罪も愉快犯から金銭目的へとビジネス化が進んでいます。
システム開発サイクルの短縮化による影響
これまでのシステム開発の多くはウォーターフォール型の開発でした。ウォーターフォール型の開発は、開発対象のシステムに対する要求事項を最初に定義し、計画（スケジュールや予算）どおりに設計／実装／テスト／リリースを行う手法です。前工程に戻ることは許可されておらず、「いつまでに何を作ればよいか」を見通せている場合に向いています。システムのリリース後は、運用保守フェーズに入ります。
運用保守フェーズでは、ハードウェアやソフトウェアのEOSL（End of Service Life：製品サポート終了）までの約5年間、要件定義で決めた要求仕様どおりにシステムを維持管理することが求められていました。運用保守フェーズでは、大きなシステム変更は起きにくいため、脆弱性診断やシステム監査（図2）は年次のサイクルで実施されるのが一般的です。
人間で例えるのであれば、定期健康診断を年単位で受診し、健康状態を測定／可視化することで健康を維持できていることを確認することと同じです。
しかし、システムの開発手法にアジャイル型を採用している場合は、そう簡単にはいきません。アジャイル型の開発は、先の見通しが悪い不確実性の高い状況におけるシステム開発に向いています。ユーザーの要求事項の変化に対応しながら、優先度の高い機能から短期間で開発を繰り返す（イテレーションと呼びます）ため、週単位、さらには日単位で新しい機能がリリースされます。
優先度の高い要求から市場投入し、早く動くものを使ってもらうことで現実的なフィードバックを得て、それを次の機能開発に活かしながらサービスの付加価値を向上させられます（図3）。
アジャイル型の開発では、優先度の高い要求を取り込み続けるために常に機能が拡張され、システム構成が変わります。週単位での機能リリースに対して、従来の年単位での脆弱性診断やシステム監査では、時間軸が完全に合わなくなってしまいます。脆弱性診断やシステム監査は人手による作業工程が多く、頻度高く実施するには費用対効果が見合わない状態となってしまうという課題が生まれてきました。
攻撃の進化速度向上による影響
サイバー犯罪が金銭目的になってきたことで、攻撃手法はより組織的になってきています。AI技術の活用や効果の高いマルウェア、攻撃方法がダークウェブ経由で拡散されるなど、最新テクノロジーの活用は攻撃者側のほうが速いこともあります。従来のセキュリティ対策基準では、リスク対応が難しくなってきました。
多くの企業では、対策基準などの情報セキュリティガイドライン（図4）の改訂を年単位で実施していることと思います。従来の改訂サイクルでまったく対応が追い付かないとは言い切れませんが、それでも以前よりは更新頻度が短くなる要素は増えてきています。
これまで良しとされてきた守るべきルールが頻繁に変更されてしまうと、多くのユーザーは正確なルールの把握が困難となり、ルールを正しく理解することを諦めてしまいます。これでは、しだいに情報セキュリティガイドラインが形骸化してしまうリスクが出てきます。
リスクの変化に対して、更新すべき内容が含まれていないか、毎年情報セキュリティガイドラインをチェックすることにも労力を要します。改訂が必要な場合、改訂による事業影響の調査、対策基準や運用手順などのドキュメント更新作業、新しいルールの周知徹底や教育／啓蒙活動などにも時間と人的リソースがかかります。守ることのできるポリシーを適切に維持するための仕組みを考え直すタイミングが来ているとも言えるでしょう。
また、パッケージ製品のような数年に一度のバージョンアップとは異なり、クラウドでは新しいサービスや機能のリリース周期が圧倒的に短くなります。そのため、情報セキュリティポリシーで許可されていないものを利用したくても利用できないケースも出てきます。セキュリティがビジネスの生産性や利便性を損ない、事業のスピードが落ちることでビジネスの競争力を失ってしまっては本末転倒です。
世の中には、ISOやNISTなどが公開している情報セキュリティに関するガイドラインや基準、認証規格などさまざまなドキュメントがあります。しかし、それらのドキュメントどおりにすることが必ずしも事業のリスクを下げるとは限らない点にも注意が必要です。事業の現場で重要視されているポイントを理解し、生産性と安全性とのバランスの中で必要最低限のやるべきセキュリティ（リスク許容できるかどうか）を決断できることが、今後ますます重要になってくるでしょう（図5）。
図6は、リスク対応マトリクスの4つの対応内容の説明になります。具体例には、顧客から預かっている機密情報を保存したノートPCを不注意により社外で紛失してしまった際の再発防止策を記載しています。
継続的セキュリティ
2000年前半以降、日本における情報セキュリティのベースとなっている考え方は、Pマーク（正式名称：プライバシーマーク制度）やISMSだと筆者は認識しています。
2005年4月に個人情報保護法（正式名称：個人情報の保護に関する法律）が全面施行され、多くの企業は個人情報取扱事業者として、生存する個人を特定する情報を安全に管理することが義務付けられてきました。個人データ（個人情報を容易に検索できるように体系的にまとめた「個人情報データベース等」を構成する個人情報）を保護するために講ずるべき安全管理措置（組織的／人的／物理的／技術的）をもとに、その考え方を情報セキュリティにも拡大させ、適用してきた背景があります。
ISMS
Pマークと併せて、大企業を中心にISMS（ISO/IEC27001）を取得する国内企業が増え、2022年9月時点で7,000社を超える状況となっています（図7）。
日本は、他国に比べるとISMSを取得する組織が多い傾向にあります。ISMSの取得目的や取得範囲は企業によってさまざまだと思いますが、取得している組織における情報セキュリティポリシーやガイドラインのベースにしている企業は多いことでしょう。
ISMSは、企業／組織の重要な情報を守るためのシステム／仕組みが定義されていることを第三者機関にお墨付きを頂くことで認証される規格になります。取得後も定義されたルールどおりに情報セキュリティの運用管理ができていることを毎年監査し、それを継続審査することで維持します。「年単位でチェックする仕組み」であるということを覚えておいてください。
ISO/IEC27001は、1999年に初版が発行されてから何度か改訂されており、2022年には最新版であるISO/IEC27001:2022がリリースされています。変更の背景には、テレワークによる業務環境の変化、クラウドサービスの利用拡大、データプライバシー保護への関心の高まりなどがあります。
2013年版では、10項目の要求事項と114項目のセキュリティ管理策から構成されていましたが、2022年版は既存114項目が統合／更新されて82項目となり、新規に11項目の管理策が追加されています（図8）。
NISTCyberSecurityFramework
かつては米国でもサイバー攻撃が組織のネットワーク内に侵入してこないようにブロックすることに集中する考え方を採用していました（ISMSの考え方と同じ）。しかし、サイバー攻撃が金銭目的で行われるようになったことで攻撃が巧妙化し、ファイアウォールやアンチウイルス製品での防御だけではその進化のスピードに追い付けなくなってきました。
そこで、2011年に攻撃のブロックを重視した方針から、ネットワーク内に侵入されることを前提とした考え方にシフトしました。仮に侵入されたとしてもすぐに異常を検知することで被害の拡大を防ぎ、迅速に元の正常な状態に戻すための機能をフレームワークとして定義しました。そのフレームワークが、NIST CSF（Cyber Security Framework）です（図9）。
2013年2月の米国のオバマ大統領による重要インフラのサイバーセキュリティの強化に向けた大統領令に則り整備され、2014年2月にバージョン1.0が公開されました。2018年4月には改訂されたバージョン1.1が公開されています。もともとは重要インフラの運用者を対象としたもので、正式名称は「重要インフラのサイバーセキュリティを向上させるためのフレームワーク」になります。
セキュリティ管理の具体的な手法と手順を明記したガイドラインSP800シリーズはNISTCSFの下位概念にあたり、NISTCSFに則って整備されています（図10）。
ISMSを含むこれまでのセキュリティガイドラインでは、脅威やリスクの「識別」や「防御」といった侵入前の予防を目的としていますが、NISTCSFは「検知」「対応」「復旧」といった侵入後の対応まで網羅しているところに特徴があります。
サイバー攻撃の手法は高度化しているため、「侵入を完全に予防するのは現実的ではないことから、攻撃を受けることを前提に被害からいかに早く復旧するかが重要」という考え方が近年のサイバーセキュリティ対策の主流になっています。インシデント対応のできるセキュリティ組織を構築するうえで参考になります。
NISTSP800-171（正式名称：非連邦政府システムと組織における非機密管理情報の保護）は、軍事情報などの機密情報以外の重要情報（CUI：Controlled Unclassified Information）を扱う民間企業が、14種類のセキュリティ要件を満たすことができる対策をまとめています。図11のとおり、NISTCSFの考え方に準じたSP800系のガイドラインになります。
なお、このガイドラインは先に発行されていたNISTSP800-53をベースに制定されています。NISTSP800-53（正式名称：連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策）は、戦闘機の図面や性能そのものの情報などの軍事に関する機密情報（CI：Classified Information）を扱う政府機関のためのガイドラインです。
米国防総省は、取引を行うすべての企業に対して、2017年12月31日までにNISTSP800-171に準拠するように通達しており、日本においても同様の動きが進んでいます。よって、NISTSP800-171は、今後のセキュリティ標準となるガイドラインになると言われています。
ここでは、NISTCSFの「検知」以降のインシデント対応で、必要な情報を収集／活用するためのナレッジを解説するように構成しています。「識別」と「防御」の状態を年次の監査でチェックする従来のやり方では対応しづらくなっている昨今のサイバー攻撃において、システムが出力するログなどのイベント情報からリアルタイムかつ継続的にリスクを検出し、実態に則した対応が取れるようになることを目標としています。
システムの動作履歴であるログから得られる情報は計り知れません。今後、その価値はより一層高まるでしょう。システムの声であるログとうまく付き合うことでリアルタイムにログから事実を把握し、いち早くリスクから組織の情報資産を守れるようになってください。
継続的セキュリティとは、APIやデータを活用し、企業における情報セキュリティリスクをリアルタイムに検知し、ビジネスの損失を最小限に抑えることです。
実現のためのアプローチ
継続的セキュリティのなかで、一番始めに考えるべき「監視」と「分析」について解説します。組織のセキュリティが十分なレベルで維持されていることをどのように評価するかに関する代表的な2つのアプローチを述べ、それぞれの構成要素について触れていきます。この内容を参考に、まずは大きな方針を理解、整理しましょう。
ベースラインアプローチ
ベースラインとは、組織の中で基準として設けているレベルや内容のことです。ベースラインアプローチは、網羅性のあるチェックリストに基づいたリスク評価が可能なアプローチになります。
あらかじめ実現すべきセキュリティレベルを設定し、実現するために必要な対策を選択し、対象となる自組織のシステムに一律に適用することで実施すべき対策の漏れを見付けることが期待できます。言い換えれば、簡単なリスクアセスメントを実施し、それに見合った管理策を適用するということです。おもにセキュリティ要求事項の低い組織や部門に適用できます（図13）。
情報セキュリティの分野には、国別や業界別で各々の運営団体の目的に応じた多くのセキュリティ基準（業界標準やガイドライン）が存在します。AWSでは、コンプライアンスプログラムが用意されており、「認証および証明」「法律、規制とプライバシー」「準拠とフレームワーク」により多くの基準が分類されています（図14）。
メリットは、標準的なセキュリティ基準をもとに行った場合、実施すべき管理策について漏れなく検討できる点です。また、評価観点や評価項目が明示されているため、評価がしやすい点も挙げられます。
デメリットは、選択するセキュリティ基準によって、求められる対策レベルが高かったり低かったりと自組織に合った基準を選ぶことの難しさが挙げられます。また自組織のシステムや環境では存在しないリスクに対してもガイドラインで対策が要求される場合に、実施する判断をしてしまうと効果がない対策にコストがかかってしまう点も挙げられます。
構成管理と構成記録
セキュリティに関連するベースラインは、組織内で使用しているサーバーのセキュリティ設定群や、脆弱性が発見された日から何日以内にセキュリティパッチを当てるという基準などが考えられます。このようなベースラインを組織内で事前定義したうえで、現状のITリソースはどの程度準拠しているのかを評価するのがベースラインアプローチです。
柔軟性や拡張性に富んだクラウド環境に代表されるように、昨今のITリソースは非常に変化が大きく、ベースラインアプローチを取るためには、現状がどうなっているかを継続的に記録し続けなければなりません。サーバーの起動や停止などの状態変化や、設定の追加／削除／更新などの値変化に対して、ITリソースの構成を継続的に管理し、記録することが重要です。企業の組織内のすべてのITリソースに関して人力による管理をすることは現実的に不可能で、自動的に構成管理や記録が取れるツールやサービスの導入は必要不可欠でしょう。逆に言うと、自動的に構成管理や記録を取ることで現在のITリソースの状況を可視化できますし、それをリアルタイムに把握することもできます（図15）。
例えば、サーバーの稼働時間や稼働率、パッチが当たっていないサーバーの数や時間、安全でないネットワーク構成のネットワークセグメントの数や範囲などです。このような自動構成管理ツールを使う前は、自組織の状態が普段どのような状態なのかを知らないことが多くあります。最初に自組織の標準的な状態を知ったうえで、基準を決めていくことをここではベースライニング（Baselining）と呼び、組織の大きさにもよりますが、通常3か月から6か月かけて実施されることが多いです。
セキュリティ基準
ベースラインアプローチとしてよく利用されるセキュリティ基準を紹介します。世の中には、さまざまなセキュリティ基準が存在しますが、大きくは「認証および証明」「法律、規制とプライバシー」「準拠とフレームワーク」と分類できます（AWSコンプライアンスプログラムより）。
さらに次のような分類ができます。
業界特化の基準
FISC安全対策基準：日本の金融機関のシステムで守るべきガイドライン PCIDSS（Payment Card Industry Data Security Standard）：クレジットカード情報を保護するための国際基準 HIPAA（Health Insurance Portability and Accountability Act of 1996）法：電子化した医療情報に関するプライバシー保護／セキュリティ確保に関する米国法律
政府調達基準
ISMAP（Informationsystem Security Managementand Assessment Program）：日本政府が活用するクラウドサービスのセキュリティを評価する制度 FedRAMP（Federal Riskand Authorization Management Program）：米国政府が活用するクラウドサービスのセキュリティを評価する制度
個人情報保護法
個人情報保護法：各国における個人情報保護に関する法律 GDPR（General Data Protection Regulation：EU一般データ保護規則）：EU域内の個人データ保護を規定する法律
クラウド事業者向け基準
CSASTAR（Security, Trust ＆ Assurance Registry）認証：CSAが提供するクラウドセキュリティの認証制度 SOC（Systemand Organization Controls）レポート：外部委託先の内部統制の状況を確認するために使用される報告書 上記以外にも汎用的に利用できる国際標準であるISO/IECやNISTの発行するSPシリーズがあります。近年、サイバー攻撃に対する技術的な対策を中心に、ITシステムを安全に構成するためのベストプラクティスが記載されたガイドラインであるCIS（Center o fInternet Security）Controlsがベースラインアプローチに利用されています（図16）。
リスクベースアプローチ
セキュリティ対策にかけるコストに上限はあるのでしょうか。経営者にその質問をすると、「セキュリティは極めて重要なので、いくらでもお金をかけます」という回答を得ることが多いです。セキュリティ事故による、一般消費者への被害補填、ビジネスパートナーに対する契約不履行、レピュテーション（評判）の低下、規制当局からの業務停止命令、株価暴落や金融機関評価の低下、経営陣の辞任、などのビジネスリスクを考慮した文脈では、（企業の実質的被害総額を超えるまでは）いくらお金をかけてでもセキュリティ事故を防ぎたいというのは理にかなっています。
一方で、ITの現場で業務していると、サービスや機能実装を優先することによるセキュリティ検討の後回し、利益確保重視によるコスト低下圧力、セキュリティ対策の費用対効果の見えづらさ、などさまざまな理由でセキュリティ対策の実現に制限がかかることがあります。
セキュリティ対策にかけられる経営資源に制約がありつつも、経営陣やステークホルダーに対してはセキュリティ対策や状況を説明する責任があるなかで、リスクベースアプローチという概念が台頭してきました。リスクベースアプローチでは、ビジネス影響度分析などの手法を用いて、ITリソースのリスクを評価し、リスクが高いものから優先的に対応可否や内容を考えるやり方です。
青天井に予算をかけるでもなく、実現可能な対応を考えることでステークホルダーに納得感を持って説明できるアプローチは、規制業界を含むあらゆる業界で採用されてきました。このアプローチを採るために、最初にやらなければならないことは、対象となる組織や環境におけるリスクを分析することです。ここで、リスクを分析する方法論のひとつとして、リスクを「脅威リスク」「脆弱性リスク」「情報資産リスク」に要素分解して考えてみましょう。
脅威リスク
脅威とは、その環境が理想とする状態からかけ離れてしまうようなネガティブな影響を与える要因のことです。セキュリティ脅威の具体例としては、標的型攻撃やマルウェアによる攻撃を含むサイバー攻撃などがあります。また、企業の外部ネットワークから来る不正通信などの脅威リスクは、その企業の状態とは無関係に、環境要因で変動しうるものです。
例えば、地政学的な変化、マクロ経済状況、世界規模イベント開催などですら、関連企業に対するDDoS（Distributed Denial of Service）攻撃が観測されることがあります。よって、脅威という要素は企業がコントロールできるものではなく、急激な脅威リスク増大の可能性には常に備えておく必要があります。
脆弱性リスク
脆弱性とは、ソフトウェアにおけるプログラム上の不具合や設計上の間違いに起因する情報セキュリティ上の欠陥などを指します。この欠陥を攻撃者に突かれることにより被害が発生します。脆弱性のより広い意味として、ソフトウェアのモジュールの構成や設定のミスを含むこともありますし、さらには人間の心理的な要素も組織に対する被害の発生に大きく関わってきます。
例えば、経理部の人間が決算期末の繁忙期にメールを受け取り、請求書と書かれた添付ファイルを不注意にも開いてマルウェアに感染してしまった場合、それは人間の心理的脆弱性を突いた攻撃だったとも言えます。このような脆弱性は組織内のあらゆるところに存在しうるものですし、それらをすべてなくすことは現実的ではないものの、常に注意を払い適切に管理するべきものです。
ソフトウェアのプログラムの脆弱性であれば、開発時におけるセキュアコーディングや静的アプリケーションセキュリティテスト、動的アプリケーションセキュリティテストなどが発生防止や早期発見に役立ちます。ソフトウェア構成や設定ミスに起因する脆弱性であれば、セキュアな構成を定義した組織のセキュリティルールや、一般的なセキュリティベストプラクティス、業界ベンチマークなどを参考に、それらの標準から逸脱していないかを常に評価するのが効果的です。
人間の心理的脆弱性には、おもにセキュリティ教育による啓蒙活動が必要になりますが、重要データは人間に直接アクセスさせずに、ツールやサービスにのみアクセスさせるという仕組みでセキュリティを担保することが多いです。
情報資産リスク
企業内には数々の情報資産が存在します。機密情報、個人情報、知的財産など、重要情報と言われるものは企業ごとの情報分類ポリシー（機密区分）に基づいて定義されていることが一般的です。
世に言う情報漏洩が事件としてニュースになるのは、その情報の漏洩による被害が社会的にも大きいからで、重要な情報であればあるほど企業の賠償額や評判毀損、金融機関評価低下、株価暴落など被害が大きくなりがちです。
つまり、企業内に存在する情報資産の価値が大きければ大きいほど、リスクも大きいと言えます。逆に、情報資産の価値がそれほど大きくない（例えば、すでにインターネットに公開されている情報の）場合、漏洩や侵害があったとしても、そこまで大きな被害は受けません。情報資産の価値がその企業のリスクを決める要因になるからこそ、情報の分類結果や重要度に基づいて、扱い方やセキュリティ管理策が変わることが多いわけです。
また、考慮点として、情報の重要度は普遍的なものではなく、時間軸に沿って変化する場合があることがあります。例えば、企業が市場に投入する新商品の情報は、発表前であれば機密度の非常に高い情報です。しかし、市場投入発表後であれば周知の情報となり、機密度は大きく下がります。これは情報の鮮度によって情報資産リスクが変化した例です。よって、情報資産の価値は変化することを前提に、リスクも継続的に評価されなければいけないと分かります。
Security Hubとは
Security Hubは、AWSが提供するAWSクラウド環境におけるセキュリティ状態を包括的に把握するためのマネージドサービスです。ここまで説明してきたベースラインアプローチとリスクベースアプローチを組み合わせた高いレベルの脅威検出として活用できます。
具体的には、AWSクラウド環境とセキュリティ基準とのギャップ分析（ベースラインアプローチ）、各種AWSセキュリティマネージドサービス（GuardDuty、Macie、Inspector、Firewall Manager、IAMAccess Analyzerなど）やサードパーティのツールで検出した脅威イベントの集約管理（リスクベースアプローチ）を兼ね備えたサービスとなっています。リアルタイムにリスクを検出できるため、継続的セキュリティを実現するための要となります（図17）。
リスクベースアプローチ
- イベント情報（動的なもの）
- Findings（ログからリスクを検出したもの）を収集
- Security Hubで可視化／分析、アラート通知
リスクベースアプローチとして、セキュリティ脅威の検出結果であるFindingsを使い、優先度の高い脅威リスクに対応します。Findingsは、システムが出力するログなどのイベント情報をベースに相関分析／機械学習された結果を脅威として判定したものです。Findingsで検出できないリスクの分析には、イベント情報をそのまま利用することもあるでしょう。
継続的セキュリティを語るうえで外すことができないキーワードのひとつがクラウドです。
NISTSP800-145で定義されたクラウドコンピューティングの特徴から見えてくるクラウド特有の脅威について、CSAジャパンによって翻訳された「クラウドの重大セキュリティ脅威11の悪質な脅威」を紹介しました。
クラウドでは、利用者の設定ミスによって致命的なインシデントにつながるケースが多数報告されています。クラウド特有の脅威に対して適切に対応できるよう、クラウド責任共有モデル、AWS Well-Architectedフレームワーク、国際標準であるISO/IEC27017:2015について触れることで対策の概要を掴んでいただけたのではないでしょうか。
クラウドが当たり前となり、システム開発に欠かせない存在となった昨今では、システム開発サイクルが劇的に短縮され、これまでの年次ベースでのセキュリティ対策には一定の限界が見え始めていました。Webサービスを中心にアジャイル開発を採用する企業が増える一方、攻撃手法の進化スピードも以前とは比べ物にならないほどに速くなりました。侵入されないための対策だけではなく、侵入されることを前提とした対策へのシフトとして、NISTCyberSecurityFrameworkの考え方を紹介しました。
繰り返しになりますが、継続的セキュリティとは「APIやデータを活用し、企業における情報セキュリティリスクをリアルタイムに検知し、ビジネスの損失を最小限に抑えること」です。
