Kiel parto de siaj profesiaj agadoj, programistoj, pentesteroj kaj sekurecprofesiuloj devas trakti procezojn kiel ekzemple Vulnerability Management (VM), (Secure) SDLC.
Sub ĉi tiuj frazoj estas diversaj aroj da praktikoj kaj iloj uzataj, kiuj estas interplektitaj, kvankam iliaj uzantoj diferencas.
Teknologia progreso ankoraŭ ne atingis la punkton, kie unu ilo povas anstataŭigi homon por analizi la sekurecon de infrastrukturo kaj programaro.
Estas interese kompreni kial tio estas tiel, kaj kiajn problemojn oni devas alfronti.
Procezoj
La procezo pri Vulnerability Management estas desegnita por kontinue monitori infrastrukturan sekurecon kaj flikadministradon.
La Secure SDLC-procezo ("sekura evoluciklo") estas dizajnita por konservi aplikaĵsekurecon dum evoluo kaj operacio.
Simila parto de ĉi tiuj procezoj estas la procezo de Takso de Vulnerabileco - taksado de vundebleco, skanado de vundebleco.
La ĉefa diferenco inter skanado ene de VM kaj SDLC estas, ke en la unua kazo, la celo estas trovi konatajn vundeblecojn en triaparta programaro aŭ en agordo. Ekzemple, malmoderna versio de Vindozo aŭ la defaŭlta komunuma ĉeno por SNMP.
En la dua kazo, la celo estas detekti vundeblecojn ne nur en triaj komponantoj (dependecoj), sed ĉefe en la kodo de la nova produkto.
Ĉi tio kaŭzas diferencojn en iloj kaj aliroj. Miaopinie, la tasko trovi novajn vundeblecojn en aplikaĵo estas multe pli interesa, ĉar ĝi ne temas pri versio fingrospurado, rubando-kolekto, pasvorta krudforto ktp.
Altkvalita aŭtomatigita skanado de aplikaĵaj vundeblecoj postulas algoritmojn, kiuj konsideras la semantikon de la aplikaĵo, ĝian celon kaj specifajn minacojn.
La infrastruktura skanilo ofte povas esti anstataŭigita per tempigilo, kiel la . La punkto estas, ke pure statistike, vi povas konsideri vian infrastrukturon vundebla se vi ne ĝisdatigis ĝin dum, ekzemple, monato.
Iloj
Skanado, same kiel sekureca analizo, povas esti faritaj kiel nigra skatolo aŭ blanka skatolo.
Black Box
Kun nigraskatolo-skanado, la ilo devas povi labori kun la servo per la samaj interfacoj per kiuj uzantoj laboras kun ĝi.
Infrastrukturaj skaniloj (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ktp.) serĉas malfermajn retajn havenojn, kolektas "standardojn", identigas instalitajn programversiojn kaj serĉas informojn pri vundeblecoj en ĉi tiuj versioj en sia sciobazo. Ili ankaŭ provas detekti agordajn erarojn kiel defaŭltajn pasvortojn aŭ publikan aliron al datumoj, malfortajn SSL-ĉifrojn, ktp.
Retaj aplikaĵaj skaniloj (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ktp.) ankaŭ povas detekti konatajn komponentojn kaj iliajn versiojn (ekz. CMS, kadrojn, JS-bibliotekojn). La ĉefaj rampaj paŝoj estas rampantaj kaj fuzantaj.
Dum rampado, la rampilo kolektas informojn pri ekzistantaj aplikaĵinterfacoj kaj HTTP-parametroj. Dum fuzzing, ĉiuj detektitaj parametroj estas anstataŭigitaj per mutaciitaj aŭ generitaj datumoj por provoki eraron kaj detekti vundeblecon.
Tiaj aplikaĵskaniloj apartenas al la DAST kaj IAST klasoj - respektive Dynamic kaj Interactive Application Security Testing.
Blanka skatolo
Kun blankkesto-skanado, estas pli da diferencoj.
Kiel parto de la VM-procezo, skaniloj (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ktp.) ofte ricevas aliron al sistemoj farante aŭtentikigitan skanadon. Tiel, la skanilo povas elŝuti instalitajn pakaĵajn versiojn kaj agordajn parametrojn rekte de la sistemo, sen diveni ilin el retservaj standardoj.
La skanado estas pli preciza kaj kompleta.
Se ni parolas pri whitebox-skanado (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ktp.) de aplikaĵoj, tiam ni kutime parolas pri statika koda analizo kaj la uzo de la respondaj SAST-klasaj iloj - Static Application Security Testing.
Problemoj
Estas multaj problemoj pri skanado! Mi devas persone trakti la plimulton de ili kiel parto de la liverado de servo por konstruado de skanado kaj sekuraj evoluaj procezoj, kaj ankaŭ dum sekureca analizo.
Mi elstarigos 3 ĉefajn grupojn de problemoj, kiujn ankaŭ konfirmas konversacioj kun inĝenieroj kaj estroj de informasekurecaj servoj en diversaj kompanioj.
Problemoj pri Skanado de Retaj Aplikaĵoj
- Malfacileco de efektivigo. Skaniloj devas esti deplojitaj, agorditaj, personecigitaj por ĉiu aplikaĵo, asignitaj testan medion por skanadoj kaj efektivigitaj en la CI / KD-procezo por esti efikaj. Alie, ĝi estos senutila formala proceduro, elsendante nur falsajn pozitivojn
- Skanado daŭro. Skaniloj, eĉ en 2019, faras malbonan laboron por dedupliki interfacojn kaj povas skani mil paĝojn kun po 10 parametroj dum tagoj, konsiderante ilin malsamaj, kvankam la sama kodo respondecas pri ili. Samtempe, la decido deploji al produktado ene de la evoluciklo devas esti farita rapide.
- Malbonaj rekomendoj. Skaniloj donas sufiĉe ĝeneralajn rekomendojn, kaj ne ĉiam eblas por programisto rapide kompreni de ili kiel redukti la nivelon de risko, kaj plej grave, ĉu ĝi devas esti farita nun, aŭ ĝi ankoraŭ ne timigas.
- Detrua efiko sur la aplikaĵo. Skaniloj povas facile fari DoS-atakon sur aplikaĵo, kaj ili ankaŭ povas krei grandan nombron da entoj aŭ ŝanĝi ekzistantajn (ekzemple, krei dekojn da miloj da komentoj en blogo), do vi ne senpripense ruli skanadon en produkto.
- Malbona kvalito de vundebleco-detekto. Skaniloj kutime uzas fiksan aron de utilaj ŝarĝoj kaj povas facile maltrafi vundeblecon, kiu ne kongruas kun ilia konata aplika konduto.
- La skanilo ne komprenas la funkciojn de la aplikaĵo. Skaniloj mem ne scias, kio estas "Interreta banko", "pago", "komento". Por ili, ekzistas nur ligiloj kaj parametroj, do grandega tavolo de eblaj komercaj logika vundeblecoj restas tute malkovrita, ili ne divenos fari duoblan forĵeton, rigardi aliulajn datumojn per identigilo aŭ fini la ekvilibron per rondigo.
- Miskompreno de paĝa semantiko fare de la skanilo. Skaniloj ne povas legi Oftaj Demandojn, ne povas rekoni kapĉasojn, ili ne mem divenos kiel registriĝi kaj poste re-ensaluti, ke vi ne povas klaki "elsaluti", kaj kiel subskribi petojn kiam ŝanĝante parametrajn valorojn. Kiel rezulto, plejparto de la aplikaĵo povas resti tute neskanita.
Problemoj pri Skanado de Fontkodo
- Falsaj pozitivoj. Statika analizo estas kompleksa tasko, kiu implikas multajn kompromisojn. Ofte vi devas oferi precizecon, kaj eĉ multekostaj entreprenaj skaniloj donas grandegan nombron da falsaj pozitivoj.
- Malfacileco de efektivigo. Por pliigi la precizecon kaj kompletecon de statika analizo, necesas rafini la skanajn regulojn, kaj skribi ĉi tiujn regulojn povas esti tro tempopostula. Kelkfoje estas pli facile trovi ĉiujn lokojn en la kodo kun ia cimo kaj ripari ilin ol skribi regulon por detekti tiajn kazojn.
- Manko de dependeca subteno. Grandaj projektoj dependas de granda nombro da bibliotekoj kaj kadroj, kiuj etendas la kapablojn de la programlingvo. Se ne estas informoj pri danĝeraj lokoj ("lavujoj") en ĉi tiuj kadroj en la sciobazo de la skanilo, tio fariĝos blinda punkto, kaj la skanilo simple eĉ ne komprenos la kodon.
- Skanado daŭro. Trovi vundeblecojn en kodo estas malfacila tasko ankaŭ laŭ algoritmoj. Tial, la procezo povas bone esti prokrastita kaj postuli signifajn komputikresursojn.
- Malalta kovrado. Malgraŭ konsumo de rimedoj kaj daŭro de skanado, programistoj de SAST-iloj ankoraŭ devas recurri al kompromisoj kaj analizi ne ĉiujn ŝtatojn en kiuj programo povas esti.
- Trovi reprodukteblecon. Montri al la specifa linio kaj voka stako kiu kondukas al vundebleco estas bonega, sed fakte, ofte la skanilo ne provizas sufiĉajn informojn por kontroli eksteran vundeblecon. Post ĉio, la difekto ankaŭ povas esti en la mortinta kodo, kiu estas neatingebla por la atakanto.
Problemoj pri Skanado de Infrastrukturo
- Nesufiĉa inventaro. En grandaj infrastrukturoj, precipe geografie disigitaj, estas ofte la plej malfacile eltrovi kiujn gastigantojn skani. Alivorte, la tasko de skanado estas proksime rilata al la tasko de administrado de valoraĵoj.
- Malbona prioritatigo. Retaj skaniloj ofte produktas multajn rezultojn kun difektoj kiuj ne estas ekspluateblaj en praktiko, sed formale ilia nivelo de risko estas alta. La konsumanto ricevas raporton malfacile interpreteblan, kaj ne estas klare, kio unue devas esti korektita
- Malbonaj rekomendoj. La skanila scio-bazo ofte enhavas nur tre ĝeneralajn informojn pri la vundebleco kaj kiel ripari ĝin, do administrantoj devos armi sin per Guglo. La situacio estas iomete pli bona kun blankskatolaj skaniloj, kiuj povas doni specifan komandon por ripari
- Manfarita. Infrastrukturoj povas havi multajn nodojn, kio signifas, ke eble ekzistas multaj difektoj, raportoj pri kiuj devas esti analizitaj kaj analizitaj permane ĉe ĉiu ripeto.
- Malbona kovrado. La kvalito de infrastruktura skanado rekte dependas de la grandeco de la sciobazo pri vundeblecoj kaj softvarversioj. Kie, , eĉ la merkataj gvidantoj ne havas ampleksan scion, kaj estas multe da informoj en la datumbazoj de senpagaj solvoj, kiujn la gvidantoj ne havas.
- Problemoj kun flikado. Plej ofte, fliki infrastrukturajn vundeblecojn estas ĝisdatigi pakaĵon aŭ ŝanĝi agordan dosieron. La granda problemo ĉi tie estas, ke la sistemo, precipe la hereda, povas konduti neantaŭvideble kiel rezulto de ĝisdatigo. Fakte, vi devos fari integrigajn testojn sur viva infrastrukturo en produktado.
Alproksimiĝoj
Kiel esti?
Mi eniros pli detale pri ekzemploj kaj kiel trakti multajn el ĉi tiuj problemoj en la sekvaj partoj, sed nuntempe mi indikos la ĉefajn areojn en kiuj vi povas labori:
- Agregado de diversaj skanaj iloj. Kun la ĝusta uzo de multoblaj skaniloj, signifa pliiĝo en la sciobazo kaj la kvalito de la detekto povas esti atingita. Vi povas trovi eĉ pli da vundeblecoj ol la sumo de ĉiuj skaniloj prizorgita individue, dum vi povas pli precize taksi la nivelon de risko kaj fari pli da rekomendoj.
- Integriĝo de SAST kaj DAST. Eblas pliigi DAST-kovradon kaj SAST-precizecon dividante informojn inter ili. De la fonto vi povas ricevi informojn pri ekzistantaj itineroj, kaj kun la helpo de DAST vi povas kontroli ĉu la vundebleco estas videbla de ekstere.
- Maŝina Lernado™. En 2015 I (kaj ) pri uzado de statistikoj por doni al skaniloj la intuicion de retpirato kaj akceli ilin. Ĉi tio certe estas nutraĵo por la disvolviĝo de aŭtomata sekureca analizo en la estonteco.
- IAST-integriĝo kun aŭtotestoj kaj OpenAPI. Ene de la CI/KD-dukto, eblas krei skanan procezon bazitan sur iloj, kiuj funkcias kiel HTTP-prokuriloj kaj funkciaj testoj, kiuj funkcias per HTTP. OpenAPI/Swagger-testoj kaj kontraktoj donos al la skanilo la mankantajn informojn pri datumfluoj, ebligos skani la aplikaĵon en diversaj ŝtatoj.
- Ĝusta agordo. Por ĉiu aplikaĵo kaj infrastrukturo, vi devas krei taŭgan skanan profilon, konsiderante la nombron kaj naturon de interfacoj, la teknologiojn uzatajn.
- Skanilo personigo. Ofte, aplikaĵo ne povas esti skanita sen modifi la skanilon. Ekzemplo estas pagpordejo kie ĉiu peto devas esti subskribita. Sen skribado de konektilo al la enireja protokolo, skaniloj senpripense bekos petojn kun malĝusta subskribo. Ankaŭ necesas skribi specialigitajn skaniloj por specifa speco de difektoj, kiel ekzemple
- Administrado de risko. La uzo de diversaj skaniloj kaj integriĝo kun eksteraj sistemoj kiel Asset Management kaj Threat Management permesos multoblajn parametrojn esti uzitaj por taksi la nivelon de risko, tiel ke administrado povas akiri adekvatan bildon de la nuna sekureca stato de la evoluo aŭ infrastrukturo.
Restu agordita kaj ni interrompu la vundeblecon skanadon!
fonto: www.habr.com