(dankon al Sergey G. Brester pro la titolideo )
Kolegoj, la celo de ĉi tiu artikolo estas kunhavigi la sperton de tutjara 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 necesa komenci per la premisoj. Do, la problemo:
- Celitaj atakoj estas la plej danĝera speco de atako, malgraŭ la fakto, ke ilia parto en la totala nombro de minacoj estas malgranda.
- Neniu garantiita efika rimedo por protekti la perimetron (aŭ aro da tiaj rimedoj) ankoraŭ estis inventita.
- Kiel regulo, celitaj atakoj okazas en pluraj stadioj. Venki la perimetron estas nur unu el la komencaj etapoj, kiu (vi povas ĵeti ŝtonojn al mi) ne kaŭzas multe da damaĝo al la "viktimo", krom se, kompreneble, ĝi estas DEoS (Detruo de servo) atako (ĉifriloj, ktp). .). La vera "doloro" komenciĝas poste, kiam la kaptitaj valoraĵoj komencas esti uzataj por pivoti kaj disvolvi "profundan" atakon, kaj ni ne rimarkis ĉi tion.
- Ĉar ni komencas suferi verajn perdojn kiam atakantoj finfine atingas la celojn de la atako (aplikserviloj, DBMS, datumstokejoj, deponejoj, kritikaj infrastrukturaj elementoj), estas logike, ke unu el la taskoj de la informa sekureca servo estas interrompi atakojn antaŭe. ĉi tiu malĝoja evento. Sed por interrompi ion, vi devas unue ekscii pri tio. Kaj ju pli frue, des pli bone.
- Sekve, por sukcesa riska administrado (tio estas, redukto de damaĝo de celitaj atakoj), estas grave havi ilojn, kiuj provizos minimuman TTD (tempo por detekti - la tempo de la momento de entrudiĝo ĝis la momento de la atako estas detektita). Depende de la industrio kaj regiono, ĉi tiu periodo averaĝas 99 tagojn en Usono, 106 tagojn en la regiono EMEA, 172 tagojn en la APAC-regiono (M-Trends 2017, A View From the Front Lines, Mandiant).
- Kion ofertas la merkato?
- " Sablokestoj " . Alia preventa kontrolo, kiu estas malproksime de ideala. Estas multaj efikaj teknikoj por detekti kaj preteriri sablokestojn aŭ blanklistigajn solvojn. La uloj de la "malhela flanko" ankoraŭ estas unu paŝo antaŭen ĉi tie.
- UEBA (sistemoj por profili konduton kaj identigi deviojn) - en teorio, povas esti tre efika. Sed, laŭ mi, ĉi tio estas iam en la malproksima estonteco. En la praktiko, ĉi tio ankoraŭ estas tre multekosta, nefidinda kaj postulas tre maturan kaj stabilan infrastrukturon pri IT kaj informa sekureco, kiu jam havas ĉiujn ilojn, kiuj generos datumojn por konduta analizo.
- SIEM estas bona ilo por esploroj, sed ĝi ne kapablas vidi kaj montri ion novan kaj originalan ĝustatempe, ĉar la korelaciaj reguloj estas la samaj kiel subskriboj.
- Kiel rezulto, estas bezono de ilo, kiu:
- sukcese laboris en kondiĉoj de jam kompromitita perimetro,
- detektis sukcesajn atakojn en preskaŭ reala tempo, sendepende de la iloj kaj vundeblecoj uzataj,
- ne dependis de subskriboj/reguloj/skriptoj/politikoj/profiloj kaj aliaj senmovaj aferoj,
- ne postulis grandajn kvantojn da datumoj kaj iliaj fontoj por analizo,
- permesus difini atakojn ne kiel ia risko-poentado rezulte de la laboro de "la plej bona en la mondo, patentita kaj do fermita matematiko", kiu postulas plian esploron, sed praktike kiel binara evento - "Jes, ni estas atakitaj" aŭ "Ne, ĉio estas en ordo",
- estis universala, efike skalebla kaj efektivigebla en iu heterogena medio, sendepende de la fizika kaj logika retotopologio uzita.
Tiel nomataj trompsolvoj nun konkuras por la rolo de tia ilo. Tio estas, solvoj bazitaj sur la bona malnova koncepto de mielpotoj, sed kun tute alia nivelo de efektivigo. Ĉi tiu temo certe pliiĝas nun.
Laŭ la rezultoj Trompsolvoj estas inkluzivitaj en la TOP 3-strategioj kaj iloj, kiujn oni rekomendas uzi.
Laŭ la raporto Trompo estas unu el la ĉefaj direktoj de disvolviĝo de IDS Intrusion Detection Systems) solvoj.
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 testa areo dum jaro.
TrapX Deception Grid permesas kosti kaj funkciigi amase distribuitajn IDS centre, sen pliigi la licencadŝarĝon kaj postulojn por aparataj rimedoj. Fakte, TrapX estas konstrukciisto, kiu ebligas al vi krei el elementoj de la ekzistanta IT-infrastrukturo unu grandan mekanismon por detekti atakojn je entreprena skalo, specon de distribuata reto "alarmo".
Solva Strukturo
En nia laboratorio ni konstante studas kaj testas diversajn novajn produktojn en la kampo de IT-sekureco. Nuntempe, ĉirkaŭ 50 malsamaj virtualaj serviloj estas deplojitaj ĉi tie, inkluzive de TrapX Deception Grid-komponentoj.
Do, de supre ĝis malsupre:
- TSOC (TrapX Security Operation Console) estas la cerbo de la sistemo. Ĉi tiu estas la centra administra konzolo per kiu agordo, deplojo de la solvo kaj ĉiuj ĉiutagaj operacioj estas efektivigitaj. Ĉar ĉi tio estas retservo, ĝi povas esti deplojita ie ajn - sur la perimetro, en la nubo aŭ ĉe MSSP-provizanto.
- TrapX Appliance (TSA) estas virtuala servilo en kiu ni konektas, uzante la trunkan havenon, tiujn subretojn, kiujn ni volas kovri per monitorado. Ankaŭ ĉiuj niaj retaj sensiloj efektive "vivas" ĉi tie.
Nia laboratorio havas unu TSA deplojita (mwsapp1), sed fakte povus esti multaj. Tio povas esti necesa en grandaj retoj kie ekzistas neniu L2-konektebleco inter segmentoj (tipa ekzemplo estas "Holding kaj filioj" aŭ "Banka ĉefsidejo kaj branĉoj") aŭ se la reto havas izolitajn segmentojn, ekzemple, aŭtomatigitaj procezkontrolsistemoj. En ĉiu tia branĉo/segmento, vi povas deploji vian propran TSA kaj konekti ĝin al ununura TSOC, kie ĉiuj informoj estos centre prilaboritaj. Ĉi tiu arkitekturo permesas konstrui distribuitajn monitorajn sistemojn sen la bezono radikale restrukturi la reton aŭ interrompi ekzistantan segmentadon.
Ankaŭ, ni povas sendi kopion de elira trafiko al TSA per TAP/SPAN. Se ni detektas konektojn kun konataj botnetoj, komandaj kaj kontrolaj serviloj aŭ 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 fajroŝirmilo, do ni ne uzis ĝin ĉi tie.
- Aplikaj Kaptiloj (Plena OS) - tradiciaj mielpotoj bazitaj sur Vindozaj serviloj. Vi ne bezonas multajn el ili, ĉar la ĉefa celo de ĉi tiuj serviloj estas provizi IT-servojn al la sekva tavolo de sensiloj aŭ detekti atakojn kontraŭ komercaj aplikoj kiuj povas esti deplojitaj en Vindoza medio. Ni havas tian servilon instalitan en nia laboratorio (FOS01)
- Emulitaj kaptiloj estas la ĉefa komponanto de la solvo, kiu permesas al ni, uzante unu solan virtualan maŝinon, krei tre densan "minkampon" por atakantoj kaj saturi la entreprenan reton, ĉiujn ĝiajn vlanojn, per niaj sensiloj. La atakanto vidas tian sensilon, aŭ fantoman gastiganton, kiel vera Vindoza komputilo aŭ servilo, Linuksa servilo aŭ alia aparato, kiun ni decidas montri al li.
Por la bono de la komerco kaj pro scivolemo, ni deplojis "paron de ĉiu estaĵo" - Vindozaj komputiloj kaj serviloj de diversaj versioj, Linuksaj serviloj, ATM kun Vindozo enigita, SWIFT Web Access, retprintilo, Cisco. ŝaltilo, Axis IP-fotilo, MacBook, PLC-aparato kaj eĉ inteligenta ampolo. Estas 13 gastigantoj entute. Ĝenerale, la vendisto rekomendas deploji tiajn sensilojn en kvanto de almenaŭ 10% de la nombro da realaj gastigantoj. La supra trinkejo estas la disponebla adresspaco.Tre grava punkto estas, ke ĉiu tia gastiganto ne estas plentaŭga virtuala maŝino, kiu postulas rimedojn kaj licencojn. Ĉi tio estas forlogaĵo, emulado, unu procezo sur la TSA, kiu havas aron de parametroj kaj IP-adreso. Tial, helpe de eĉ unu TSA, ni povas saturi la reton per centoj da tiaj fantomaj gastigantoj, kiuj funkcios kiel sensiloj en la alarmsistemo. Estas ĉi tiu teknologio, kiu ebligas kostefike skali la koncepton de mielpoto tra iu ajn granda distribuita entrepreno.
De la vidpunkto de atakanto, ĉi tiuj gastigantoj estas allogaj ĉar ili enhavas vundeblecojn kaj ŝajnas esti relative facilaj celoj. La atakanto vidas servojn sur ĉi tiuj gastigantoj kaj povas interagi kun ili kaj 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 aŭ ruli vian propran kodon.
- La kombinaĵo de ĉi tiuj du teknologioj (FullOS kaj emulitaj kaptiloj) permesas al ni atingi altan statistikan probablecon, ke atakanto pli aŭ malpli frue renkontos iun elementon de nia signala reto. Sed kiel ni povas certigi, ke ĉi tiu probableco estas proksima al 100%?
La tielnomitaj Trompo-ĵetonoj eniras la batalon. Danke al ili, ni povas inkluzivi ĉiujn ekzistantajn komputilojn kaj servilojn de la entrepreno en niaj distribuitaj IDS. Tokens estas metitaj sur realaj komputiloj de uzantoj. Gravas kompreni, ke ĵetonoj ne estas agentoj, kiuj konsumas rimedojn kaj povas kaŭzi konfliktojn. Tokens estas pasivaj informaj elementoj, speco de "panpecetoj" por la atakanta flanko, kiuj kondukas ĝin en kaptilon. Ekzemple, mapitaj retaj diskoj, legosignoj al falsaj retaj administrantoj en la retumilo kaj konservitaj pasvortoj por ili, konservitaj ssh/rdp/winscp-sesioj, niaj kaptiloj kun komentoj en gastigaj dosieroj, pasvortoj konservitaj en memoro, akreditaĵoj de neekzistantaj uzantoj, oficejo. dosieroj, malfermo kiu ekigos la sistemon, kaj multe pli. Tiel, ni metas la atakanton en distordita medio, saturita per atakvektoroj kiuj fakte ne prezentas minacon al ni, sed prefere la malon. Kaj li ne havas manieron determini kie la informo estas vera kaj kie ĝi estas malvera. Tiel, ni ne nur certigas rapidan detekton de atako, sed ankaŭ signife malrapidigas ĝian progreson.
Ekzemplo de kreado de reto-kaptilo kaj starigado de ĵetonoj. Amika interfaco kaj neniu mana redaktado de agordoj, skriptoj, ktp.
En nia medio, ni agordis kaj metis kelkajn tiajn ĵetonojn sur FOS01, kiu funkcias Windows Server 2012R2 kaj testan komputilon, kiu funkcias Windows 7. RDP funkcias sur ĉi tiuj maŝinoj kaj ni periode "pendas" ilin en la DMZ, kie kelkaj niaj sensiloj. (imititaj kaptiloj) ankaŭ estas montrataj. Do ni ricevas konstantan fluon de okazaĵoj, nature por tiel diri.
Do, jen kelkaj rapidaj statistikoj por la jaro:
56 - okazaĵoj registritaj,
2 - atakfontogastigantoj detektitaj.
Interaga, klakebla atakmapo
Samtempe, la solvo ne generas ian mega-registraĵon aŭ eventon, kio bezonas longan tempon por kompreni. Anstataŭe, la solvo mem klasifikas eventojn laŭ iliaj specoj kaj permesas al la informa sekureca teamo koncentriĝi ĉefe pri la plej danĝeraj - kiam la atakanto provas levi kontrolsesiojn (interago) aŭ kiam binaraj utilaj ŝarĝoj (infekto) aperas en nia trafiko.
Ĉiuj informoj pri eventoj estas legeblaj kaj prezentitaj, laŭ mi, en facile komprenebla formo eĉ por uzanto kun bazaj scioj pri informa sekureco.
La plej multaj el la registritaj okazaĵoj estas provoj skani niajn gastigantojn aŭ ununurajn konektojn.
Aŭ provoj al krudfortaj pasvortoj por RDP
Sed estis ankaŭ pli interesaj kazoj, precipe kiam atakantoj "sukcesis" diveni la pasvorton por RDP kaj akiri aliron al la loka reto.
Atakanto provas ekzekuti kodon per psexec.
La atakanto trovis konservitan sesion, kiu kondukis lin en kaptilon en la formo de Linuksa servilo. Tuj post la konekto, per unu antaŭpreparita aro de komandoj, ĝi provis detrui ĉiujn protokoldosierojn kaj respondajn sistemajn variablojn.
Atakanto provas fari SQL-injekton sur mielpoto kiu imitas SWIFT Web Access.
Krom tiaj "naturaj" atakoj, ni ankaŭ faris kelkajn niajn proprajn provojn. Unu el la plej malkaŝaj estas testado de la tempo de detekto de retvermo en reto. Por fari tion ni uzis ilon de GuardiCore nomita . Ĉi tio estas retvermo, kiu povas kaperi Vindozon kaj Linukso, sed sen iu ajn "utila ŝarĝo".
Ni deplojis lokan komandcentron, lanĉis la unuan kazon de la vermo sur unu el la maŝinoj, kaj ricevis la unuan atentigon 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 transiri de nur rapide detekti minacojn al aŭtomate respondi al ili.
Ekzemple, integriĝo kun NAC (Network Access Control) sistemoj aŭ kun CarbonBlack permesos vin aŭtomate malkonekti kompromititajn komputilojn de la reto.
Integriĝo kun sablokestoj permesas aŭtomate sendi dosierojn implikitajn en atako por analizo.
McAfee integriĝo
La solvo ankaŭ havas sian propran enkonstruitan eventan korelacian sistemon.
Sed ni ne kontentiĝis pri ĝiaj kapabloj, do ni integris ĝin kun HP ArcSight.
La enkonstruita biletsistemo helpas la tutan mondon trakti detektitajn minacojn.
Ĉar la solvo estis evoluigita "de la komenco" por la bezonoj de registaraj agentejoj kaj granda kompania segmento, ĝi nature efektivigas rol-bazitan alirmodelon, integriĝon kun AD, evoluinta sistemo de raportoj kaj ellasiloj (okazaj alarmoj), instrumentado por grandaj tenaj strukturoj aŭ MSSP-provizantoj.
Anstataŭ vivresumo
Se ekzistas tia monitora sistemo, kiu, figure parolante, kovras nian dorson, tiam kun la kompromiso de la perimetro ĉio ĵus komenciĝas. La plej grava afero estas, ke ekzistas vera ŝanco trakti incidentojn pri informa sekureco, kaj ne trakti iliajn sekvojn.
fonto: www.habr.com