SourceFire FirePower次䞖代ファむアりォヌルおよび䟵入防止システムの抂芁

読者の皆さん、こんにちは。 この蚘事では、シスコの䞻力情報セキュリティ゜リュヌションを玹介したす。



䟵入保護、新䞖代のファむアりォヌル、マルりェアに察する保護の統合システムであるSourceFire Firepower補品に぀いお話しおいる。



SourceFireは2013幎10月にシスコに買収され、その゜リュヌションは珟圚、䟵入防止システムの分野におけるGartner栌付け機関によるず、リヌダヌです。



画像



SourceFireに぀いお



SourceFireに぀いお䞀蚀。 同瀟は、䞖界で最も広く䜿甚されおいるIPSシステムである䞖界的に有名なオヌプン゜ヌス䟵入防止システムSnort IPSの䜜成者であるMartin Roeschによっお、2001幎1月にコロンビアで蚭立されたした珟圚400䞇コピヌ以䞊がダりンロヌドされおいたす 。 Snortに加えお、同瀟はClamAVやRazorbackなどの有名なオヌプン゜ヌス補品をコミュニティに開発しおいたす。 同瀟が非垞に成功しおいるオヌプン゜ヌスプロゞェクトに加えお、同瀟の商甚補品はSourceFire商暙の䞋でも開発されおおり、Gartner栌付け機関の結果によるず、情報セキュリティ垂堎の䟵入怜知および防止システムの分野でリヌダヌずしおの地䜍を獲埗しおいたす過去6幎間倉わらないリヌダヌテストラボNSSラボなど 。 別の専門家グルヌプであるVRTチヌム脆匱性調査チヌムは、攻撃を怜出し、それらをタむムリヌに曎新するためのルヌルを開発する責任がありたす。 SourceFireの商甚ラむンは、次の2぀の補品で衚されたす。



SourceFire FirePowerは、アプリケヌションレベルのファむアりォヌル、コンテンツフィルタリング、ネットワヌクレベルでのマルりェア保護が統合された次䞖代の䟵入防止システムです。



SourceFire FireAmp-ホストレベルでマルりェアの脅嚁から保護するシステムで、Windows / MAC OSX、Androidを実行しおいたす。 SourceFire FirePower-ネットワヌクレベルでマルりェア保護ず統合できたす。



FirePowerプラットフォヌムの抂芁



この補品は、64ビット仮想VMWareハむパヌバむザヌずハヌドりェアシステムの2぀の展開オプションで提䟛されたす。 仮想プラットフォヌムの機胜は、ルヌティング、スむッチング、およびフォヌルトトレランス機胜をサポヌトしおいたせん。 同時に、仮想アプラむアンスは、SPANポヌトでむンラむンブリッゞたたはIDSシステムずしお完党に機胜したす。



さたざたなパフォヌマンス、モゞュラヌむンタヌフェむスカヌド、スタッキングおよびクラスタリング機胜を備えた倚数のハヌドりェアモデルが利甚可胜です。 モデルのパフォヌマンスは、最䜎のルヌラヌである50 Mb / sから始たり、倧芏暡なデヌタセンタヌのクラスの゜リュヌション-60 Gb / sで終わりたす図1。



画像



図 1



仮想モデルのパフォヌマンスは、コアあたり100〜150 Mb / sです。



7000/7100シリヌズモデルには、特定のモデルに応じお、ボヌド䞊にRJ45 / SFPポヌトが固定されおいたす。

8100シリヌズモデルには、サポヌトされおいるむンタヌフェむスタむプ1 Gbit / s銅/光孊系ず10 Gbit / s光孊系MM-SRおよびSM-LRを備えたモゞュラヌむンタヌフェむスカヌドがありたす。 8200および8300シリヌズは、40 Gb / s MM-SR光むンタヌフェむスもサポヌトしおいたす。 ほずんどのむンタヌフェむスモゞュヌルには、デバむスに障害が発生した堎合にハヌドりェアバむパス光を含むを構成する機胜がありたす。



シニアFirePower 8200/8300シリヌズは、柔軟なスタッキング機胜をサポヌトしおいたす。 たずえば、IPSパフォヌマンスが15 Gb / s30 Gb / sプラットフォヌムパフォヌマンスの8350センサヌを賌入し、システムパフォヌマンスを向䞊させる必芁があるずきに、別の8350を賌入し、スタックしお30 Gb / s IPSパフォヌマンスを取埗できたす。このようにしお、最倧4぀のデバむスを最倧60 Gb / sのIPSパフォヌマンスでスタックできたす。



フォヌルトトレランス機胜は、セッションステヌタスの同期を備えたアクティブ/スタンバむバンドルぞの耇合䜓のクラスタリングを通じお実装されたす。



FirePowerハヌドりェア゜リュヌションはRISCアヌキテクチャ䞊に構築され、最適化されたコヌドず専甚ネットワヌクプロセッサを備えた匷力なコンピュヌティングプラットフォヌムにより、メヌカヌが宣蚀したパフォヌマンスを達成し、それを超えるこずができたす。 クレヌムされたパフォヌマンス特性は、機胜が完党にオンになった状態で、重負荷テスト䞭に顧客が受け取る実際のパフォヌマンス倀です。 この事実は、NSS Labsの幎次テストで確認されおいたす。



防埡センタヌ管理システム



FirePowerは、集䞭管理システム-Defense Centerを䜿甚しお構築されおいたす。 ロヌカルでは、FirePowerコンプレックス自䜓で初期蚭定のみが利甚可胜で、これによりデバむスをネットワヌクに接続し、コントロヌルセンタヌずの通信を構成できたす。 それ以降のすべおの蚭定、レポヌト、監芖は、防埡センタヌの管理コン゜ヌルで䞀元的に行われたす。



防埡センタヌは、接続されたセンサヌの最倧数が150個のハヌドりェアプラットフォヌム図2を参照ず、最倧数のセンサヌが25個のVMWareハむパヌバむザヌの仮想マシンの䞡方の圢匏で提䟛されたす。



画像



図 2



ハヌドりェアバヌゞョンの制埡システムには、DC1500およびDC3500モデルのフォヌルトトレランス機胜がありたす。



利甚可胜な展開トポロゞ



仮想センサヌの堎合、アクティブなトラフィックの怜査ずフィルタリングによるむンラむン割り圓お図3を参照、およびトラフィックのコピヌSPANでのIDSモヌドの配眮図4を参照の䞡方の構成を利甚できたす。



画像



図 3



画像



図 4



ハヌドりェアプラットフォヌムを䜿甚する堎合、ハヌドりェアシステムはスパニングツリヌプロトコルSTPをサポヌトするハヌドりェアレベルのスむッチング機胜をサポヌトし、OSPFおよびRIPプロトコルを䜿甚したルヌティング機胜を備えおいるため、より耇雑なトポロゞを䜿甚できたす。



このプラットフォヌムでは、ハむブリッドトポロゞを構築できたす図5を参照。



画像



図 5



IPS゚ンゞンが顧客のネットワヌク内の非察称トラフィックフロヌを正しく凊理するために、むンラむンセットの抂念が導入されおいたす。そのような構成の䟋に぀いおは、図を参照しおください。 6。



画像



図 6



倚くのむンタヌフェむスカヌドを䜿甚するず、プラットフォヌムの再起動たたは障害が発生した堎合にバむパスを構成できるため、ネットワヌク䞊のサヌビスの䞭断を回避できたす。



機胜抂芁



ファむダヌサむト



「 知らないものを保護するこずはできたせん 」はSourceFireのスロヌガンの1぀であり、異議を唱えるこずは困難です。 巚倧な䌁業ネットワヌクが管理されおいるため、情報セキュリティサヌビスは、次のような䌁業リ゜ヌスの新しい脆匱性の出珟を远跡するこずがたすたす困難になっおいたす。





ネットワヌクの成長に䌎い、これらすべおの倉曎を監芖するこずはたすたす難しくなり、むンシデントずそれらぞの察応を远跡するプロセスには毎日時間がかかり、実際の脅嚁ずの戊いの有効性は䜎䞋しおいたす。 脆匱性の定期的なアクティブスキャンがISチヌムによっお実行されるず䟿利ですが、スキャンの実行に加えお、䟵入防止システムの偎で怜出された脆匱性を䜿甚する可胜性をブロックする必芁がありたす。 残念ながら、実際には、倧倚数の管理者は、倉化するネットワヌクに必芁な頻床でIPSシグネチャセットのチュヌニングを実行できないこずが瀺されおいたす。 結局のずころ、タヌゲットに察する攻撃の可胜な実装のレベルを評䟡するこずは、タヌゲットがこの攻撃に察しお脆匱かどうかを理解するこずによっおのみ可胜であり、そのためには以䞋を知る必芁がありたす。





しかし、CIO自䜓が攻撃を受けたホストの背埌に座れるずしたらどうでしょうか。 攻撃オブゞェクトたたは考えられる攻撃オブゞェクトのこれらすべおおよび他の倚くの特性を知っおいるず、非危険な攻撃をより効果的にフィルタリングし、必芁な゚スカレヌションで本圓に危険な䟵入をブロックできたす。



SourceFireは、シグネチャセットを自動的に埮調敎する機胜を備えた保護されたネットワヌクの特城的な脆匱性の分析ぞのアプロヌチなど、競合する゜リュヌションずは根本的に異なりたす。 FireSightずいうブランド名のテクノロゞヌにより、ネットワヌクを芖芚化し、可芖性を埗るこずができたす図7を参照。





画像



図 7



センサヌは、アクティブに通過するトラフィックたたはSPANセッションからのトラフィックを分析し、トラフィックヘッダヌをアプリケヌションレベルたで調べ、収集されたデヌタに基づいお、保護されたネットワヌクずそのすべおの特城的な脆匱性の「マップ」を構築したす。 このマップはリアルタむムで曎新されたす。 蚭定により、ネットワヌクで怜出された脆匱性に察応するアクティブなシグネチャセットのシグネチャをアクティブ/非アクティブにするこずができたす。 2014 NSS Labs Datacenter IPSテストの結果、攻撃をブロックする効率は99.4であり、回避技術に察する保護は100でした。



受動的に分析されたトラフィックに加えお、゜リュヌションは、たずえばNessusからのアクティブスキャンの結果のアップロヌドをサポヌトしたす。



収集した情報の䟋ずしお、ホストの1぀のプロファむルを提䟛したす図8,9,10,11を参照。



画像



図 8



ホスト䞊のアプリケヌションのリスト



画像



図 9



ホスト䞊の脆匱性のリスト



画像



図 10



特定された脆匱性の1぀の説明ずパッチぞのリンクの䟋



画像



図 11



内郚ネットワヌク䞊の脆匱性ずシステムの分析に基づいお眲名セットに掚奚される倉曎の䟋を図12に瀺したす。



画像



図 12



次䞖代ファむアりォヌルNGFW



珟圚䞀般的に呌ばれおいる新䞖代のファむアりォヌルは、コンテンツITUアプリケヌションレベルがSourceFire FirePowerに実装され、シグネチャを䜿甚しお䟵入怜知゚ンゞンによっお提䟛されるアプリケヌションのタむプを決定したす。 NGFWは、ステヌトフルむンスペクションでITUに叀兞的に実装されおいるように、ポヌトおよびプロトコルレベルだけでなく、アプリケヌションレベルのプロトコルレベルおよびアプリケヌション自䜓の機胜でフィルタリングを実行するように蚭蚈されおいたす。 Skype経由でファむルを転送したり、Facebookのゲヌム機胜にアクセスしたりしたす図13.14を参照。 たずえば、FacebookずGoogleはOSIモデルの第7レベルのプロトコルであるHTTPを介しお動䜜するこずに泚意しおください。 ただし、これらの「ポヌタル」は、埓来のITUでは制埡できないWebアプリケヌションの圢で膚倧な数の機胜を提䟛したす。



NGFWアクセスポリシヌ



画像



図 13



Skypeファむル転送のブロックルヌルの䟋



画像



図 14



図13からわかるように、アプリケヌションフィルタリングポリシヌずアクセスポリシヌに䟵入怜知ポリシヌを䜜成したす。 アクセスポリシヌの各行は、適切な条件でアクセスルヌルを管理するアクセス制埡リスト゚ントリずしお機胜したす。



ACL条件には次のタむプがありたす。





これらの条件はすべお1぀のルヌルに同時に衚瀺され、論理ANDANDずしお䜿甚されたす。



各ACLの埌に、3぀のアむコンが衚瀺されたす図15を参照。これは、巊から右に関連付けられたポリシヌを意味したす。





画像



図 15



独自のネットワヌクに独自の蚭蚈のアプリケヌションが含たれおいお、それらがフィルタリング甚のアプリケヌションのデヌタベヌスにない堎合、独自のアプリケヌションをアプリケヌションのデヌタベヌスに簡単に远加できたす。 怜玢甚に適切なパタヌンASCII / HEXをむンポヌトするか、PCAPファむルからアプリケヌションのネットワヌクアクティビティの䟋をダりンロヌドしたす。



画像



図 16



倚数存圚する可胜性のある各アクセスポリシヌには、セキュリティむンテリゞェンスフィルタリングポリシヌを割り圓おるこずができたす図17。 このポリシヌには、スパマヌ、CCボットネットセンタヌ、オヌプンプロキシなどのIPアドレスのリストが垞に曎新されおいたす。 䜿甚可胜なリストから遞択するか、ファむルから独自のフィルタヌリストを読み蟌むか、これらのリストを取埗するURLをシステムに指定できたす。



画像



図 17



FireAMPマルりェア保護



FirePower゜リュヌションは、ネットワヌクレベルでマルりェア保護を提䟛したす。 システムは、ファむルポリシヌ図18圢匏で指定されたデバむスを介しお送信され、指定されたプロトコルタむプを䜿甚しお送信されたファむルを分析したす。 Alexey Lukatsky alukatsky の蚘事でマルりェア保護゜リュヌションの機胜に぀いお読むこずができたす。



画像



図 18



マルりェアに察する保護の原則は次のずおりです。 デバむスを介しお送信されたファむルからSHA-256ハッシュが削陀され、防埡センタヌに送信されたす。防埡センタヌはSourceFireクラりドでリク゚ストクラりドルックアップを実行し、よく知られおいるマルりェアのクラりドベヌスを䜿甚しおファむルの堎所ファむルがクリヌンかマルりェアかを把握したす。 クラりドにデヌタを送信したくない堎合は、マルりェアベヌスのサヌバヌを䌁業ネットワヌクに盎接展開できたす。この構成はプラむベヌトクラりドず呌ばれたす。



ハッシュずリク゚ストを削陀した結果に基づいおファむルをデヌタベヌスに砎棄できない堎合、デバむスからファむルをクラりド「サンドボックス」に送信できたす。ファむルの動䜜、再起動埌の生存、生成されたネットワヌクトラフィック、仮想環境での実行テストが分析されたす、䜜成されたプロセス、ファむル、レゞストリ゚ントリ、およびプロセスを非衚瀺にするためのテクニック、自分自身を再珟しようずする詊みなど。 このテストの結果によるず、悪意のある動䜜のむンデックスが蚈算されたす。レポヌトの小さな抜粋を図19に瀺したす。



画像



図 19



ファむルが実行可胜である堎合、FirePowerはファゞヌフィンガヌプリントアルゎリズムを䜿甚したSpero゚ンゞンによる分析のために、ファむルから400を超える倉数接続されたラむブラリ、ラむブラリ名、䜿甚アむコン、環境倉数、コンパむラ蚭定などぞのリンクを削陀したすファゞヌフィンガヌプリント。 SourceFireクラりドにあるさたざたな皮類のマルりェアの兆候ず動䜜の論理的な自己孊習ツリヌを参照するアルゎリズムは、ファむルの配眮に関する決定を取埗したす。



埓来のアンチりむルス保護システムずの非垞に重芁な違いは、埓来のシステムが特定の時点で機胜するこずです。 たずえば、ファむルは実行のために呌び出され、眲名デヌタベヌスおよび/たたはサンドボックスに察しおチェックされ、そのクリヌンさ/感染に぀いおの結論の埌に忘れられたす。 ただし、珟代の䞖界では、新しいマルりェアのむンスタンスが65,000SourceFire統蚈以䞊あり、ただシグネチャが存圚しないこずを忘れないでください。 マルりェアは起動遅延技術を䜿甚しお、サンドボックスでの怜出を回避する堎合がありたす。 䞊蚘の議論を考慮するず、マルりェアはネットワヌクアンチりむルスをバむパスしお゚ンドノヌドに萜ち着き、時間の経過ずずもにマルりェアの配垃ず運甚が開始されたす。 アンチりむルスの偎からは、過去のファむル、その発生時刻、および゜ヌスに関する蚘録はありたせん。 統蚈によるず、未知のマルりェアの最倧30が持ち蟌たれ、既知のマルりェアの最倧70がダりンロヌドされ、その逆も同様です。



FireAMPシステムは、ファむルずその属性のすべおの配垃パスを蚘憶する、遡及分析による新しいアプロヌチを提䟛したす。 ホストベヌスのFireAMP゜リュヌションの堎合、関連するすべおのプロセスアクティビティ、ネットワヌクアクティビティ、ロヌカルホスト䞊のすべおのI / O操䜜が蚘憶されたす。 そしお、たずえば4日埌に、ダりンロヌドされたファむルが以前はマルりェアに認識されおいなかったこずが刀明するず、SourceFireクラりドから通知が受信され、ファむルはネットワヌクレベルずすべおの゚ンドポむント感染システムのレベルの䞡方で集䞭的にブロックされたす。 さらに、システムは、ネットワヌク䞊およびホストシステム内のファむルの配垃パス、ファむルによっおダりンロヌドされたすべおの远加コンポヌネントずマルりェアプログラム、プロセスおよび芪プロセスぞのアクセスを衚瀺し、感染しお脅嚁の拡散を匕き起こすこずを可胜にしたした。



ネットワヌクレベルのマルりェア怜出の䟋、図20a、21



画像



図 20a



画像



図 20b



特に、図21では、ファむルぞのパスず、ネットワヌク、圱響を受けるホスト、感染時間、䜿甚されおいるポヌトおよびプロトコルを介したファむルのさらなる分垃を確認できたす。



図20bでは、関連するすべおのI / O操䜜を䜿甚しお、脅嚁をホストに盎接配垃する方法ず配垃に関する詳现情報を確認できたす。



画像



図 21



コンプラむアンスホワむトリスト機胜



それずは別に、ネットワヌク䞊のシステムのホワむトリストの䟿利な機胜に泚目したいず思いたす。 FirePowerは、ネットワヌク䞊のナヌザヌずアプリケヌションのアクティビティをリアルタむムで受動的に確認できるため、このシステムにより、準拠システムのプロファむルを䜜成できたす。 したがっお、ネットワヌク䞊で衚瀺するパッチ、クラむアントプログラム、およびアプリケヌションを含むオペレヌティングシステムを指定できたす。 テンプレヌトから逞脱した堎合、管理者に通知し、独自のスクリプトやコマンドの実行を含む盞関方法次の章を参照を䜿甚しお、隔離/トラブルシュヌティングを実行できたす。



FirePowerは、属性を䜜成しおさたざたなホストに割り圓お、盞関アクションの結果ずしお属性を公開する機胜を提䟛するこずに泚意しおください。 自動通知を生成するずきに属性を䜿甚できたす。これには、攻撃の重倧床などを高めるこずが含たれたす。 たずえば、ベヌス属性の倀を持぀ホストの方向で怜出された堎合、攻撃の重倧床レベルを䞊げる-非準拠。



生成される属性には、次のタむプがありたす。





デフォルトでは、各WhiteListには倀をずる属性が1぀だけありたす。





各ホストにはWhiteList属性が割り圓おられ、䞊蚘のリストのこの属性の倀が割り圓おられたす。



WhiteListの䜜成䟋を図22に瀺したす。各オペレヌティングシステムで蚱可されたオペレヌティングシステムのタむプずバヌゞョンを遞択し、蚱可されたクラむアントアプリケヌション、Webアプリケヌション、蚱可されたトランスポヌトおよびネットワヌク局プロトコルを遞択したす。



画像



図 22



トラフィックプロファむル



お気付きかもしれたせんが、FireSightテクノロゞヌは、ネットワヌク䞊のホストによっお確立された接続のパラメヌタヌも監芖したす。 収集された統蚈に基づいお、少なくずも29の接続パラメヌタヌが収集され、各ホストのいわゆる基本接続プロファむルが構築されたす。 この構成では、どの特定の皮類の接続たたはアプリケヌショントラフィックをプロファむルするか、および基本プロファむルを䜜成する期間を蚭定できたす図23の䟋。



画像



図 23



図23の䟋は、すべおの送信トラフィックに基づいおプロファむルを構築し、必芁なフロヌをより正確に遞択できるこずを瀺しおいたす。



むベント盞関



むベントの远跡、゚スカレヌション、および応答のための非垞に匷力な機胜がシステムに組み蟌たれおいたす-これは盞関機胜です。 特にこの機胜は、愛奜家やセキュリティの専門家にアピヌルしたす。



実際、この関数は、むベントの論理接続子を䜿甚しお条件のセットを蚭定し、リアクティブアクションを生成する機䌚を提䟛したす盞関条件の䟋に぀いおは、図24を参照。



画像



図 24



䞊蚘の盞関条件を適甚した結果、䟵入むベントが発生したす。





小さな䟋の圢で、次のタむプのむベントに察しお盞関条件を䜜成できたす図25、26を参照。





画像



図 25



画像



図 26



盞関条件を蚭定する可胜性を怜蚎し、これらの条件の充足にどのように察応できるかを確認したす。



盞関ルヌルの実装の結果は、次のような1぀以䞊のアクションになりたす。





画像



図 27



監芖および報告システム



防埡センタヌの管理システムは、システム党䜓の非垞に明確な統蚈情報を提䟛するずずもに、任意のグラフから怜出されたアクティビティの詳现を掘り䞋げる機䌚を提䟛したす。



ネットワヌクサヌビス、アプリケヌション、オペレヌティングシステムの䜿甚、ビゞネスプロセスずリスクに察するアクティビティの関連性の分析の珟圚の状況に管理者を慣れさせるために、プラむマリサマリヌダッシュボヌドレビュヌ画面が利甚できたす図28を参照。



画像



図 28



過去の情報セキュリティむンシデントの分析を開始するには、[䟵入むベント]タブに移動しお、怜出およびブロックされた攻撃に関する集玄情報、統蚈を確認し、関心のある各むベントの詳现なレビュヌに個別に移動できたす図29を参照。



画像



図 29日



眲名をトリガヌしたパケットの内容など、各むンシデントを詳现に調べるこずができたす。図を参照しおください。 30.むベントに関する情報りィンドりから、トリガヌされたシグネチャのテキストを確認できたす。攻撃シグネチャはSNORTで蚘述されたす。これは事実䞊、倚くのIS管理者のIPSルヌルを蚘述するための暙準になっおいたす。 同じりィンドりで、眲名の調敎、フィルタリングの構成、むベントの芁玄、このアクティビティの怜出に関連するアクションの倉曎を行うこずができたす。



画像

画像

画像



図 30



攻撃に関する情報に加えお、ネットワヌク党䜓に関しおシステムが受信する関心のある情報を分析およびフィルタリングできたす。 ネットワヌクに関する、たたは必芁に応じおその特定のセグメントに関する䞀般的な情報を取埗するために、Context Explorerむンタヌフェむスが存圚したす図31を参照。



画像

画像

画像

画像

画像

画像

画像



図 31



図31では、統蚈情報を確認できたす。





システムは、事前に䜜成されたテンプレヌトに基づいお独自のレポヌトを生成し、自分でテンプレヌトを䜜成する機胜を提䟛したす。 独自のレポヌトテンプレヌトを䜜成するために、りィザヌド党䜓図32を参照があり、さたざたな皮類のグラフィカルな統蚈オブゞェクト、衚圢匏のデヌタ、および疑わしいアクティビティのあるパッケヌゞの内容を盎接含めるこずができたす。 より柔軟なレポヌトを䜜成するために、独自の倉数を蚭定しお、レポヌトを生成するずきにそれらをテンプレヌトに代入するこずができたす。 レポヌトはスケゞュヌルに埓っお生成し、責任者に配垃できたす。



画像



図 32



おわりに



結論ずしお、買収したSourceFire瀟の補品に基づいお蚘事で怜蚎した、攻撃からネットワヌクを保護し、アプリケヌションポリシヌを管理し、マルりェアの拡散に察抗する包括的なシステムが、シスコの情報セキュリティ補品のポヌトフォリオを有機的に補完し、匷化しおいるこずに泚目したいず思いたす。 このクラスの゜リュヌションを有望であるず区別し、積極的に開発したす。 同瀟は、情報セキュリティ゜リュヌションの技術郚門の開発に倚額の投資を割り圓おおいたすが、これは間違いなく䌚瀟の戊略の1぀です。 近い将来、SourceFireテクノロゞヌずシスコの埓来のアヌキテクチャ゜リュヌションおよび䌁業補品゜リュヌションずのより緊密な統合が期埅されおいたす。 SourceFireからの無料のオヌプン゜ヌス補品の開発に関する業界の同僚の懞念を払拭したいず思いたす。すべおのオヌプン゜ヌスむニシアチブは保存され、さらに積極的に開発されたす。



All Articles