(dankon al Sergej G. Brester pro la ideo pri la titolo) )
Kolegoj, la celo de ĉi tiu artikolo estas dividi la sperton de jarlonga testa operacio de nova klaso de IDS-solvoj bazitaj sur Deception-teknologioj.
Por konservi la logikan koherecon de la prezento de la materialo, mi opinias necese komenci per la premisoj. Do, la problemaro:
- Celitaj atakoj estas la plej danĝera tipo de atako, malgraŭ la fakto, ke ilia parto en la tuta nombro de minacoj estas malgranda.
- Ne ekzistas garantiite efika rimedo de perimetroprotekto (aŭ komplekso de tiaj rimedoj), kiu ankoraŭ estis inventita.
- Tipe, celitaj atakoj okazas en pluraj stadioj. Perimetra rompo estas nur unu el la komencaj stadioj, kiu (vi povas ĵeti ŝtonojn al mi) ne kaŭzas multan damaĝon al la "viktimo", krom se, kompreneble, temas pri DEoS (Detruo de Servo) atako (ĉifriloj, ktp.). La vera "doloro" komenciĝas poste, kiam la kaptitaj aktivaĵoj komencas esti uzataj por pivoti kaj disvolvi atakon "profunde", kaj ni ne rimarkis ĝin.
- Ĉar ni komencas suferi realajn perdojn kiam atakantoj finfine atingas la atakcelojn (aplikaĵservilojn, DBMS-ojn, datumstokadon, deponejojn, kritikajn infrastrukturelementojn), estas logike, ke unu el la taskoj de la informa sekurecservo estas interrompi atakojn antaŭ tiu malĝoja evento. Sed por interrompi ion, oni unue devas scii pri ĝi. Kaj ju pli frue - des pli bone.
- Sekve, por sukcesa risktraktado (t.e., reduktado de damaĝo de celitaj atakoj), estas grave havi ilojn, kiuj certigos minimuman TTD (tempon por detekto - la tempo de la momento de entrudiĝo ĝis la momento de detekto de la atako). Depende de la industrio kaj regiono, ĉi tiu periodo estas averaĝe 99 tagoj en Usono, 106 tagoj en la EMEA-regiono, 172 tagoj en la APAC-regiono (M-Trends 2017, A View From the Front Lines, Mandiant).
- Kion ofertas la merkato?
- "Sandboxes". Alia preventa kontrolo, kiu estas malproksima de ideala. Ekzistas multaj efikaj teknikoj por detekti kaj preteriri sandboxes aŭ blanklistigi solvojn. La uloj de la "malhela flanko" ankoraŭ estas unu paŝon antaŭe ĉi tie.
- UEBA (sistemoj por konduta profilado kaj anomalia detekto) – teorie, ĝi povas esti tre efika. Sed, laŭ mia opinio, tio estas iam en la fora estonteco. Praktike, ĝi estas ankoraŭ tre multekosta, nefidinda kaj postulas tre maturan kaj stabilan IT- kaj IS-infrastrukturon, kie jam ekzistas ĉiuj iloj, kiuj generos datumojn por konduta analizo.
- SIEM estas bona ilo por esploroj, sed ĝi ne kapablas vidi aŭ montri ion novan aŭ originalan ĝustatempe, ĉar la korelaciaj reguloj estas esence la samaj signaturoj.
- Rezulte, necesis ilo, kiu povus:
- sukcese funkciigita en jam kompromitita perimetro,
- detektas sukcesajn atakojn preskaŭ realtempe sendepende de la iloj kaj vundeblecoj uzitaj,
- ne dependis de subskriboj/reguloj/skriptoj/politikoj/profiloj kaj aliaj statikaj aferoj,
- ne postulis grandajn kvantojn da datumoj kaj iliaj fontoj por analizo,
- permesus al ni difini atakojn ne kiel ian riskopoentadon rezulte de la laboro de "la plej bonaj en la mondo, patentitaj kaj tial fermitaj matematikoj", kio postulas plian esploron, sed praktike kiel binaran okazaĵon - "Jes, ni estas atakataj" aŭ "Ne, ĉio estas en ordo",
- estis universala, efike skalebla kaj farebla por efektivigi en iu ajn heterogena medio, sendepende de la fizika kaj logika rettopologio uzata.
La tiel nomataj trompaj solvoj nuntempe pretendas la rolon de tia ilo. Tio estas, solvoj bazitaj sur la bona malnova koncepto de mielpotoj, sed kun tute malsama nivelo de efektivigo. Ĉi tiu temo sendube pliiĝas nun.
Laŭ la rezultoj Tromposolvoj estas inter la 3 plej rekomendindaj strategioj kaj iloj.
Laŭ la raporto Trompo estas unu el la ĉefaj direktoj de disvolviĝo de IDS-solvoj (Entrudiĝdetektosistemoj).
Tuta sekcio de ĉi-lasta , dediĉita al SCADA, baziĝas sur datumoj de unu el la gvidantoj en ĉi tiu merkato, TrapX Security (Israelo), kies solvo funkcias en nia testzono jam dum unu jaro.
TrapX Deception Grid permesas al vi konstrui kaj funkciigi grandegajn distribuitajn IDS-ojn centre, sen pliigi la licencan ŝarĝon kaj aparatarajn rimedajn postulojn. Fakte, TrapX estas konstruilo, kiu permesas al vi krei unu grandan entrepren-kovrantan atakan detektan mekanismon el elementoj de la ekzistanta IT-infrastrukturo, specon de distribuita reto-"alarmo".
Solva Strukturo
En nia laboratorio ni konstante studas kaj testas diversajn novigojn en la kampo de IT-sekureco. Nuntempe, estas ĉirkaŭ 50 malsamaj virtualaj serviloj deplojitaj ĉi tie, inkluzive de TrapX Deception Grid-komponantoj.
Do, de supre malsupren:
- TSOC (TrapX Security Operation Console) estas la cerbo de la sistemo. Ĉi tiu estas la centra administra konzolo, per kiu la solvo estas agordita, deplojita kaj ĉiu ĉiutaga laboro estas plenumata. Ĉar ĉi tiu estas retservo, ĝi povas esti deplojita ie ajn - en la perimetro, en la nubo aŭ ĉe la MSSP-provizanto.
- TrapX Appliance (TSA) estas virtuala servilo, al kiu ni konektas la subretojn, kiujn ni volas monitori, per trunk-pordo. Ĉiuj niaj retsensiloj fakte "loĝas" ĉi tie.
En nia laboratorio, ni deplojis unu TSA-on (mwsapp1), sed reale povas esti multaj el ili. Ĉi tio povas esti necesa en grandaj retoj kie ne ekzistas L2-konektebleco inter segmentoj (tipa ekzemplo estas "Holding kaj filioj" aŭ "Banko-ĉefsidejo kaj branĉoj") aŭ se estas izolitaj segmentoj en la reto, ekzemple, aŭtomatigita procesrega sistemo. En ĉiu tia branĉo/segmento, vi povas deploji vian propran TSA-on kaj konekti ĝin al ununura TSOC, kie ĉiuj informoj estos centre prilaboritaj. Ĉi tiu arkitekturo permesas al vi konstrui distribuitajn monitoradajn sistemojn sen la bezono de radikala restrukturado de la reto aŭ interrompo de ekzistanta segmentado.
Ni ankaŭ povas sendi kopion de eliranta trafiko al TSA per TAP/SPAN. Kaze de detekto de konektoj kun konataj botretoj, komandserviloj, TOR-sesioj, ni ankaŭ ricevos la rezulton en la konzolo. Network Intelligence Sensor (NIS) respondecas pri tio. En nia medio, ĉi tiu funkcio estas efektivigita sur la fajromuro, do ni ne uzis ĝin ĉi tie.
- Aplikaĵaj Kaptiloj (Plena OS) - tradiciaj mielpotoj bazitaj sur Windows-serviloj. Ne multaj estas bezonataj, ĉar la ĉefa celo de ĉi tiuj serviloj estas provizi IT-servojn al la sekva tavolo de sensiloj aŭ detekti atakojn kontraŭ komercaj aplikaĵoj, kiuj eble estos deplojitaj en Windows-Merkredo. Ni havas unu tian servilon (FOS01) instalitan en nia laboratorio.
- Simulitaj kaptiloj estas la kerna komponanto de la solvo, permesante al ni krei tre densan minkampon por atakantoj uzante unuopan virtualan maŝinon kaj saturi la entreprenan reton, inkluzive de ĉiuj ĝiaj VLAN-oj, per niaj sensiloj. La atakanto vidas tian sensilon, aŭ fantoman gastiganton, kiel realan. Windows komputilo aŭ servilo, Linux servilo aŭ alia aparato, kiun ni decidas montri ĝin.
Por komerco kaj scivolemo, ni deplojis "paron de ĉiu kreitaĵo" - Windows Komputiloj kaj serviloj de diversaj versioj, Linux-serviloj, bankomataj Windows enigita, SWIFT Web Access, retprintilo, Cisco-ŝaltilo, Axis IP-fotilo, MacBook, PLC-aparato, kaj eĉ inteligenta ampolo. Tio estas 13 gastigantoj entute. Ĝenerale, la vendisto rekomendas deploji tiajn sensilojn ĉe almenaŭ 10% de la tuta nombro de faktaj gastigantoj. La supra limo estas la disponebla adresspaco.Tre grava punkto estas, ke ĉiu tia gastiganto ne estas plenkreska virtuala maŝino, kiu postulas rimedojn kaj licencojn. Ĝi estas "ŝajnilo", emulado, unu procezo sur TSA, kiu havas aron da parametroj kaj IP-adreson. Tial, per la helpo de eĉ unu TSA, ni povas saturi la reton per centoj da tiaj fantomaj gastigantoj, kiuj funkcios kiel sensiloj en la alarmsistemo. Ĝuste ĉi tiu teknologio permesas ekonomie kaj efike skali la koncepton de "mielpotoj" je la skalo de iu ajn granda distribuita entrepreno.
Ĉi tiuj gastigantoj estas allogaj el la vidpunkto de la atakanto, ĉar ili enhavas vundeblecojn kaj aspektas kiel relative facilaj celoj. La atakanto vidas la servojn sur ĉi tiuj gastigantoj kaj povas interagi kun ili, ataki ilin uzante normajn ilojn kaj protokolojn (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, ktp.). Sed estas neeble uzi ĉi tiujn gastigantojn por disvolvi atakon kaj lanĉi vian kodon.
- La kombinaĵo de ĉi tiuj du teknologioj (FullOS kaj imititaj mielpotoj) permesas al ni atingi altan statistikan probablecon, ke atakanto poste renkontos iun elementon de nia signala reto. Sed kiel ni povas igi ĉi tiun probablecon proksima al 100%?
La tiel nomataj ĵetonoj (Deception tokens) eniras la batalon. Danke al ili, ni povas inkluzivi ĉiujn disponeblajn komputilojn kaj servilojn de la entrepreno en nian distribuitan IDS. Ĵetonoj estas metitaj sur realajn komputilojn de uzantoj. Gravas kompreni, ke ĵetonoj ne estas agento, kiu konsumas rimedojn kaj povas kaŭzi konfliktojn. Ĵetonoj estas pasivaj informaj elementoj, ia "panero" por la atakanto, kiu kondukas ĝin en kaptilon. Ekzemple, konektitaj retaj diskoj, legosignoj al falsaj retaj administraj paneloj en la retumilo kaj konservitaj pasvortoj al ili, konservitaj ssh/rdp/winscp-sesioj, niaj kaptiloj kun komentoj en gastigaj dosieroj, pasvortoj konservitaj en memoro, akreditaĵoj de neekzistantaj uzantoj, oficejaj dosieroj, kies malfermo ekigos la sistemon, kaj multe pli. Tiel, ni metas la atakanton en distorditan medion saturitan de atakvektoroj, kiuj fakte ne prezentas minacon al ni, sed male. Kaj li havas neniun manieron determini kie la informo estas vera kaj kie ĝi estas falsa. Tiel, ni ne nur certigas rapidan detekton de la atako, sed ankaŭ signife malrapidigas ĝian progreson.
Ekzemplo de kreado de retkaptilo kaj agordo de ĵetonoj. Uzant-amika interfaco kaj neniu mana redaktado de agordoj, skriptoj, ktp.
En nia medio, ni agordis kaj deplojis kelkajn tiajn ĵetonojn sur FOS01 sub la kontrolo de Windows Server 2012R2 kaj testa komputilo sub Windows 7. Ĉi tiuj maŝinoj funkciigas RDP, kaj ni periode "pendigas" ilin en la DMZ, kie ankaŭ troviĝas kelkaj el niaj sensiloj (imititaj kaptiloj). Tiel, ni ricevas konstantan fluon de okazaĵoj, tiel diri, nature.
Do, jen kelkaj koncizaj statistikoj por la jaro:
56 – okazaĵoj registritaj,
2 - atakfontaj gastigantoj detektitaj.
Interaga, klakebla atakmapo
Samtempe, la solvo ne generas ian mega-protokolon aŭ okazaĵofluon, kies ordigo bezonas longan tempon. Anstataŭe, la solvo mem klasifikas okazaĵojn laŭ iliaj tipoj kaj permesas al la informa sekureca teamo koncentriĝi ĉefe pri la plej danĝeraj - kiam la atakanto provas komenci kontrolajn sesiojn (interagado) aŭ kiam binaraj utilaj ŝarĝoj (infekto) aperas en nia trafiko.
Ĉiuj informoj pri eventoj estas legeblaj kaj prezentitaj, laŭ mia opinio, en facile komprenebla formo eĉ por uzanto kun bazaj scioj pri informa sekureco.
Plej multaj el la registritaj okazaĵoj estas provoj skani niajn gastigantojn aŭ individuajn konektojn.
Aŭ provoj perforte trudi pasvortojn por RDP
Sed estis ankaŭ pli interesaj kazoj, precipe kiam atakantoj "sukcesis" akiri la pasvorton por RDP kaj akiri aliron al la loka reto.
Atakanto provas ekzekuti kodon uzante psexec.
La atakanto trovis konservitan sesion, kiu kondukis lin en kaptilon en la formo de Linux-servilo. Tuj post konekto, uzante unuopan, antaŭpreparitan aron da komandoj, ĝi provis detrui ĉiujn protokoldosierojn kaj respondajn sistemajn variablojn.
Atakanto provas fari SQL-injekton sur mielpoton kiu imitas SWIFT Web Access.
Aldone al tiaj "naturaj" atakoj, ni ankaŭ faris kelkajn proprajn testojn. Unu el la plej indiktivaj estas testi la tempon necesan por detekti retvermon en la reto. Por tio, ni uzis ilon de GuardiCore nomatan Ĉi tiu estas retvermo kiu povas kapti Windows и Linux, sed sen ia ajn “utila” ŝarĝo.
Ni deplojis lokan komandcentron, lanĉis la unuan instancon de la vermo sur unu el la maŝinoj, kaj ricevis la unuan sciigon en la TrapX-konzolo en malpli ol minuto kaj duono. TTD 90 sekundoj kontraŭ 106 tagoj averaĝe...
Danke al la kapablo integriĝi kun aliaj klasoj de solvoj, ni povas moviĝi de nur rapida detektado de minacoj al aŭtomata respondo al ili.
Ekzemple, integriĝo kun NAC (Network Access Control) sistemoj aŭ CarbonBlack permesos, ke infektitaj komputiloj estu aŭtomate malkonektitaj de la reto.
Integriĝo kun sablokestoj permesas al vi aŭtomate sendi dosierojn implikitajn en atako por analizo.
McAfee-integriĝo
La solvo ankaŭ havas sian propran enkonstruitan sistemon por korelacii eventojn.
Sed ni ne estis kontentaj pri ĝiaj kapabloj, do ni integris ĝin kun HP ArcSight.
La enkonstruita bileta sistemo helpas trakti detektitajn minacojn "kiel teamo".
Ĉar la solvo estis evoluigita "dekomence" por la bezonoj de registaraj agentejoj kaj granda entreprena segmento, ĝi nature efektivigas rol-bazitan alirmodelon, integriĝon kun AD, evoluigitan sistemon de raportoj kaj ellasiloj (okazaĵaj sciigoj), orkestradon por grandaj posedstrukturoj aŭ MSSP-provizantoj.
Anstataŭ vivresumo
Se ekzistas tia monitora sistemo, kiu, metafore parolante, kovras nian dorson, tiam kun la kompromiso de la perimetro, ĉio nur komenciĝas. La plej grava afero estas, ke aperas vera ŝanco por batali kontraŭ informaj sekurecaj incidentoj, kaj ne por okupiĝi pri la forigo de iliaj sekvoj.
fonto: www.habr.com
