Bepaling van de wanbetalingsstaat voor een Sourcefire-regel in een inbraakbeleid

Inleiding

Dit artikel beschrijft hoe het Vulnerability Research Team (VRT) de standaardstaat in het inbraakbeleid bepaalt, en hoe een Sourcefire-apparaat de juiste standaardstatus voor een nieuwe regel bepaalt.

Vaststelling van een rechtsstaat in een beleid van wanbetaling

Elke regel heeft een metagegevensveld, met nul of meer beleidswaarden. Op dit moment zijn er zes mogelijke beleidswaarden:

1. veiligheidsdruppels
2. veiligheidsalarm
3. druppel
4. waarschuwing
5. aansluitings-ips-druppels
6. aansluitingswaakzaamheid

Als een IPS-beleid is afgeleid van bijvoorbeeld het door Sourcefire geboden gebalanceerde security en connectiviteitsbeleid, is het beheerde apparaat in inline modus en een regel heeft een metagegevensbeleidswaarde van een gebalanceerde IPS-toets, wordt de regel ingesteld om gebeurtenissen in uw IPS-beleid te laten vallen en genereren. Als een regel een beleidswaarde heeft van slechts veiligheidsdaling, zal het in uw beleid gehandicapt zijn.

Opmerking: Als een regel meerdere gespecificeerde beleidswaarden heeft, bijvoorbeeld: beleidsveiligheidsnips vallen af, de beleid-evenwichtsdruppels daalt, verschijnt deze in beide beleidsmaatregelen. Als voor een gegeven regel geen beleidswaarde is opgegeven, verschijnt deze standaard in geen enkel beleid.

Als een beheerd apparaat is ingesteld op passieve modus en een beleid is ingesteld op drogen, heeft dit geen effect. Het apparaat genereert simpelweg waarschuwingen. Als een apparaat in de inline modus staat en een beleidswaarde is ingesteld om te zetten, worden de pakketten standaard op de regel geplaatst. Als de beleidswaarde is ingesteld op alert, genereren het alleen gebeurtenissen, zonder te vallen.

Ten slotte wordt er in de meeste gevallen een melding gegenereerd als een pakje is ingetrokken. Dit geldt tenzij de onderdrukking van signaleringen voor een bepaalde regel afzonderlijk is ingesteld.

Hoe bepaalt Sourcefire een geschikte standaardstatus voor een nieuwe regel

De standaard status van een regel is gebaseerd op een aantal factoren. Bijvoorbeeld:

impact

Te overwegen dingen

Hoe waarschijnlijk is het dat er pogingen zullen worden gedaan om deze kwetsbaarheid uit te buiten en welk percentage van onze gebruikers (zowel Sourcefire-klanten als de bredere Snort-gemeenschap) zal waarschijnlijk kwetsbaar zijn voor deze kwetsbaarheid?

Te onthouden dingen

Een kwetsbaarheid van Internet Explorer met bekende aanvallen in het wild heeft een veel hogere impact dan bijvoorbeeld een SAP-gegevensfunctie die kwaadaardig kan worden gebruikt wanneer permissie niet correct is geconfigureerd, of een complexe denial-of-service aanval in een obscure module van de Linux-tunnel. VRT maakt een effectbeoordeling, te beginnen met de CVSS-score van een kwetsbaarheid, door deze zo nodig aan te passen met alle aanvullende informatie die we kunnen bezitten. Dit is de belangrijkste maatstaf van allemaal, omdat we soms een regel mogelijk maken die anders niet aan zou gezet worden of niet ingesteld zou worden om te vallen als de impact hoog genoeg is.

Prestaties

Te overwegen dingen

Verwachten we dat deze regel snel of langzaam zal zijn op een "gemiddeld" netwerk?

Te onthouden dingen

Hoewel de snelheid van een regel volledig afhankelijk is van het verkeer dat hij inspecteert, wat de prestaties moeilijk te meten maakt, hebben we een algemeen idee van wat een normaal netwerk is en hoe een bepaalde regel op dat normale netwerk presteert. We weten ook dat een regel met bijvoorbeeld één enkele content match die relatief lang is (6 of meer bytes, doorgaans) en relatief uniek (d.w.z. "obscureJavaScriptFunctie()" en niet "|00 00 00 00|" of "GET / HTTP/1.1") zal sneller evalueren dan een regel met een complexe PCRE, een reeks byte_test en/of byte_spring clausules, enz. Met deze kennis kunnen we bepalen of een regel snel of langzaam zal zijn en daarmee rekening houden.

vertrouwen

Te overwegen dingen

Hoe waarschijnlijk is het dat deze regel valse positieven oplevert?

Te onthouden dingen

Sommige kwetsbaarheden vereisen zeer specifieke, gemakkelijk ontdekte omstandigheden om te kunnen worden uitgebuit, in welk geval we er zeer zeker van kunnen zijn dat wanneer de daarmee gepaard gaande regelgeving brandt, er een actieve exploitatie gaande is. Bijvoorbeeld, als er een bufferoverflow is in een protocol dat een unieke magische string heeft op een vaste positie, en dan een gespecificeerde lengte die een vaste afstand is van die magische string, kunnen we vertrouwen hebben in ons vermogen om de magische string te vinden en te controleren op een bekende waarde voor problemen. In andere gevallen zijn de problemen veel minder duidelijk gedefinieerd; Zo kunnen bepaalde DNS cache-vergiftigingsaanvallen worden aangegeven door een abnormaal groot aantal NXDOMAIN-antwoorden die binnen een bepaalde periode van een server afkomstig zijn. In een dergelijk geval is de loutere aanwezigheid van een NXDOMAIN-antwoord op zich geen indicator van een exploitatielening; het is de aanwezigheid van een zeer groot aantal van deze antwoorden in een korte periode die het probleem aangeeft . Aangezien dat aantal voor verschillende netwerken anders zal zijn, moet VRT een waarde kiezen die voor de meeste netwerken moet werken en die moet vrijgeven. we kunnen er echter niet volledig van op aan dat , wanneer de regel brandt , er daadwerkelijk kwaadaardige activiteiten plaatsvinden .

Ten slotte, maar niet in de laatste plaats, hoewel andere factoren van tijd tot tijd als relevant kunnen worden beschouwd, is de impact aan het eind van de dag koning - waarbij ervoor wordt gezorgd dat onze klanten worden beschermd tegen de dreigingen die zij in het wild waarschijnlijk het meest zullen zien - onze voornaamste zorg.

Revisiegeschiedenis