Unelte de Securitate Pentru Retele de Calculatoare. Rootkit Uri

1. Motivarea alegerii temei

Prezenta lucrare de licență își propune descrierea și definirea securității operaționale și a unui instrument de tip malware: rootkit-ul.

Numărul tot mai mare de incidente ce au loc în rețelele de calculatoare (Internet), este în continuă creștere. În majoritatea atacurilor asupra calculatoarelor țintă se utilizează din ce în ce mai mult rootkit-urile. „Avantajul” acestora este că sunt greu de detectat, ele integrându-se perfect pe sistemul de operare care este atacat, având capacitatea de a avea acces la root-ul calculatorului (privilegii de administrator). În această prezentare rootkit-urile sunt utilizate pe sistemul de operare Windows XP, al celor de la Microsoft. Rootkit-urile pot fi folosite și în scopuri juste, cum ar fi detectarea de către organe abilitate ale statului asupra unor fapte care încalcă legea: pornografia infantilă, clonarea de carduri bancare, piratarea anumitor produse digitate (filme, jocuri, muzică etc.).

Lucrarea de licență prezentată în continuare are ca scop principal vizualizarea funcționării acestor rootkit-uri precum și modul în care acționează asupra calculatorului atacat și care sunt efectele pe care le lasă în urma folosiri lor.

Rootkit-urile sunt open source (surse libere) și pot fi modificate, scopul lor fiind unul educativ, prin care se încearcă efectuarea anumitor teste, ca la sfârșitul lor să se poată observa efectele distructive asupra sistemului de operare Windows XP.

2. Introducere în securitatea operațională

În această lucrare de licență este vorba despre securitatea operațională (SecOp). Se măsoară cât de bine funcționează securitatea. În timp ce ni se poate părea simplu și clar: “Oare nu ne ocupăm toți cu securitatea operațională?”, există o distincție de făcut, deoarece marea parte a obiectivelor de conformitate nu necesită mai mult decât procese și configurații asemănătoare pentru a seta cele mai bune aplicații. Acestă lucrare de licență și procesul de testare pe care îl schițează necesită ca tu să nu faci presupuneri cum ar fi funcționarea pe durata utilizării operaționale a unei soluții, unui produs sau unui proces de securitate, după cum s-a desemnat să funcționeze pe hârtie. Mai simplu de atât, această metodologie îți va spune dacă ceea ce deții va face ceea ce vrei tu și nu doar ceea ce i s-a spus să facă.

SecOp este o combinație de separare și control. În cadrul SecOp, pentru ca o amenințare să fie eficientă trebuie să interacționeze fie în mod direct, fie în mod indirect cu profitul economic. Separarea amenințării de bunul economic înseamnă evitarea unei posibile interacțiuni. Prin urmare este posibilă deținerea unei securități totale (100%) în cazul în care amenințarea este separată complet de bunul economic. Altfel, ceea ce ai este siguranța bunului economic, care este produsă de controlul pe care îl ai asupra acestuia sau gradul la care vrei să micșorezi impactul amenințării [1].

De exemplu, pentru a fi protejat de fulgere trebuie să te muți acolo unde fulgerul nu poate ajunge, ca de exemplu în mijlocul unui munte. Amenințările care nu pot fi separate de bunuri, trebuie îmbunătățite pentru a fi mai sigure, astfel încât interacțiunea lor sau efectele din urma interacțiunii să nu facă multe pagube, ba chiar deloc. În același exemplu, pentru a fi protejat de fulger trebuie să stai în casa în timpul furtunii, să eviți geamurile și alte locuri deschise spre mediul exterior și să folosești paratrăsnet pe acoperiș. Prin urmare, în cadrul contextului unei securități operaționale, numim securitate separarea unui produs de amenințare și numim siguranță controlul amenințării sau efectele sale.

Pentru siguranța reală a produselor se necesită diferite tipuri de control. Totuși, controlul poate, de asemenea, mări numărul de interacțiuni din cadrul scopului, ceea ce înseamnă că mai mult control nu este în mod necesar cea mai bună opțiune. Mai mult control asemănător cu controlul operațional nu asigură o apărare mai bună, deoarece accesul într-unul reprezintă de obicei, accesul în tot ce este de același tip. Acesta este motivul pentru care este atât de important să putem clasifica controlul în acțiunile sale din cadrul operațiilor, pentru a fi siguri de nivelul de protecție asigurat de ei.

Pentru a înțelege modul în care poate funcționa, SecOp trebuie redus la elementele sale, în cadrul unui mediu operațional. Aceste elemente permit cuantificarea Suprafeței de Atac, care reprezintă lipsa unei separări specifice și a unui control funcțional care există pentru acel Vector, direcția interacțiunii. Abordarea reducționistă ne permite să vedem securitatea și siguranța într-un mod nou, unul care le permite să existe independent de risc, fiind capabilă pe deplin să creeze Securitatea Perfectă, echilibrul perfect dintre securitate și control, cu operații și limitări. Totuși, pentru a putea vedea securitatea într-un mod nou, este nevoie de asemenea și de o terminologie nouă.

2.1 Securitate

Securitatea reprezintă funcția unei separări, fie separarea de un produs, fie de existenta sau nu a unei amenințări. Există 3 moduri logice și proactive de a crea această separare:

Mutarea produsului pentru a crea o barieră fizică sau logică între acesta și amenințări.

Schimbarea amenințării într-o situație inofensivă.

Distrugerea amenințării.

În timp ce analizăm securitatea situației putem vedea locurile în care există posibilitatea unei interacțiuni. Noi cunoaștem o parte, toată partea sau chiar nimic din aceste interacțiuni care pot fi solicitate pentru operații. Precum ușile dintr-o clădire, unele uși sunt necesitate pentru clienți și altele pentru consumatori. Totuși, fiecare ușă reprezintă un punct interactiv care poate mări atât operațiile necesare, cât și pe cele nedorite, cum ar fi furtul. Întrucât testarea securității nu poate cunoaște în acest moment justificarea afacerii, în aceste puncte interactive ne referim la ea cu termenul de porozitate. Porozitatea reduce separarea dintre o amenințare și un acces. În plus este clasificată ca una din cele 3 elemente: vizibilitatea, accesul sau încrederea, descriind rolul său în operații; mai departe va permite adăugarea controlului adecvat din timpul fazei de remediere a protecției de îmbunătățire.

Astfel se consideră că dacă separarea există departe de amenințări, ca de exemplu un om din mijlocu muntelui care vrea să evite fulgerul, atunci securitatea respectivă este adevărată, este 100%. Pentru fiecare gaură din munte, fiecare mod a fulgerului de a face pagube omului, porozitatea crește ca un Acces. Fiecare punct de interacțiune reduce securitatea sub 100 %, 100 % reprezentând separarea completă. Deci, mărirea porozității reprezintă scăderea securității și fiecare por este fie Vizibilitatea, fie Accesul sau Încrederea [1].

2.2 Control

Atunci când amenințarea se afla peste tot, controlul este cel care oferă protecție în timpul operațiilor. Controlul este un mod de a influența impactul amenințărilor și a efectelor pe care le au atunci când interacțiunea este necesară.

În timp ce există multe nume și tipuri diferite de control al operației, există numai 12 categorii principale care conțin toate tipurile posibile de control. Totuși, două dintre aceste categorii, Identificarea, verificarea unei identități existente și Autorizația, acordarea permisiunilor de către autoritatea de drept, nu pot exista de unele singure în mediul operațional, ci mai degrabă în operații, care se combină sau sunt adăugate controlului de Autentificare. Acesta lăsă SecOp cu 10 tipuri posibile de control pe care un Analist va trebui să le identifice și să le înțeleagă.

Motivul pentru care Identificarea și Autorizația nu pot fi exprimate în mod operațional este acela că nici una nu poate fi transferată. În timp ce mijlocul de identificare luat drept un proces este un aspect operațional, procesul actual reprezintă verificarea unei identități prevăzute înaintea unei alte surse sau a ultimului lanț de surse. Chiar și în cazurile în care o agenție guvernamentală schimba în mod oficial identitatea unei persoane, aceasta rămâne aceeași persoană în ceea ce privește ADN-ul sau, astfel încât se schimbă numai documentele. Prin urmare, un proces de securitate poate încerca să identifice pe cineva, verificându-i identitatea, însă în acest caz nimic nu este garantat sau prevăzut. Nu există o “garanție” reală a identificării, la fel cum nu poate exista “furt” real al identității. În plus, identitatea este o colecție de gânduri, emoții, experiențe, relații și intenții, precum și forma corpului și semnele distinctive de pe acesta. Ești cine ești pentru că exiști și nu pentru că cineva ți-a permis acest lucru. O sosie perfectă a ta sau o clonă nu sunt cine ești tu, pentru că încă de la început experiențele voastre vor fi diferite. În timp ce aceasta poate semăna mai mult cu filozofia decât cu securitatea, este foarte important ca Analiștii să înțeleagă acest lucru. Procesele de identificare se verifică numai contra unui prim proces de identificare. Dacă acel proces a fost stricat, atunci toată fundația de securitate care are nevoie de identificare adecvată este defectă [1].

Autorizația, la fel ca Identificarea, este alt control de operații, care nu poate fi transferat. Este rolul controlului de a acorda permisiuni. Un angajat autorizat să intre în cameră poate ține ușa deschisă pentru a permite intrarea altei persoane. Dar noua persoană nu este autorizată. Autorizația nu este transferabilă. Această persoană nouă intră într-o zonă intrezisă, iar angajatul care a ținut ușa deschisă face parte din limitarea procesului de Autentificare, care acordă Acces.

O altă proprietate a Autorizației este faptul că are nevoie de identificare pentru a putea lucra. Fără identificare, autorizația este o pătură “care permite accesul tuturor” fără să știe măcar ceea ce reprezintă termenul “tuturor”. Totuși, în cadrul operațiilor, acesta este un paradox deoarece, a autoriza accesul necontrolat tuturor persoanelor înseamnă că nu există autorizație. Prin urmare, nu folosi autorizație pentru a nu te autoriza.

Controlul de Autentificare combină atât identificarea cât și autorizația de a reprezenta Accesul. Procesul este de a ști cine (sau ce) este și cantitatea, locul și momentul accesării înainte de a li se acorda accesul. Deoarece autentificarea este un control față de interactivitate, este un control din cadrul celor 5 Clase A, cunoscute și sub numele de “Control Interactiv”.

Controlul interactiv

Controlul interactiv din Clasa A adună exact jumătate din toate tipurile de control operațional. Aceste tipuri de control influențează direct vizibilitatea, accesul sau încrederea interacțiunilor. Categoriile din Clasa A sunt Autentificarea, Compensația, Subjugarea, Continuarea și Reziliența.

Autentificarea este un control din cadrul provocării credentialelor bazată pe identificare și autorizație.

Compensația este un control din cadrul unui contract dintre proprietarul produsului și partea interactivă. Acest contract poate exista sub forma unui avertisment vizibil precum un precursor al acțiunii legale, în cazul în care normele postate nu sunt respectate, sub forma unei protecții publice legislative specifice, sau sub forma unui furnizor terț de asigurare în caz de daune, precum o companie de asigurări.

Reziliența este controlul asupra tuturor interacțiilor pentru a menține protecția produselor in cazul corupției sau a eșecului.

Subjugarea este controlul care asigură ca interacțiunile să aibă loc numai în conformitate cu procesele definite. Proprietarul produsului definește modul în care are loc interacțiunea, eliminând libertatea alegerii, precum și răspunderea pierderii din partea interacțiunii.

Continuitatea este controlul asupra tuturor interacțiunilor pentru a menține interactivitatea cu produsele în cazul corupției sau a eșecului.

Controlul de Proces

Cealaltă jumătate a controlului operațional este reprezentată de controlul din Clasa B care este folosit pentru a crea procesele defensive. Aceste tipuri de control nu influențează în mod direct interacțiunile, mai degrabă protejează produsele din moment ce amenințarea este prezentă. Acestea sunt de asemenea cunoscute sub numele de Control de Proces și includ Non-repudierea, Confidențialitatea, Intimitatea, Integritatea și Alarma.

Non-repudierea este controlul care previne refuzarea rolului de interactivitate de către partea interactivă.

Confidențialitatea este un control pentru asigurarea afișării sau schimbării între părțile unui produs, fără a se putea afla în exteriorul acelor părți.

Intimitatea este controlul pentru asigurarea modului în care un produs este accesat, afișat sau schimbat între părți, fără a se putea afla în exteriorul acelor părți.

Integritatea este un control care asigură modul în care părțile interactive cunosc timpul în care s-au schimbat produsele și procesele.

Alarma este controlul de a notifica că o interacțiune are loc sau a avut loc.

În timp ce procesul de control reprezintă o influență pozitivă asupra SecOp, micșorând suprafața de atac, acesta se poate adăuga singur suprafeței de atac, dacă are restricții. Uneori acest efect nu este văzut, iar dacă mecanismele de protecție nu sunt testate până la sfârșit, cum ar fi modul de funcționare în toate condițiile, s-ar putea să nu devină aparent. De aceea utilizarea controlului trebuie să asigure că nimeni nu poate realiza un nou atac de vectori în cadrul țintei. Așadar, câteodată lipsa controlului e mai bună decât un control defect [1].

Exemplul încuietorii stricate

Este o încuietoare stricată mai bună decât lipsa totală a acesteia? Un Analist trebuie să folosească securitatea critică gândindu-se la o formă de abilități logice care înving înțelesul înnăscut al securității pe care dorim să îl înțelegem, pentru a cunoaște motivul din cauza căruia controlul defect poate mări suprafața de atac, ajungând la un control mai bun decât lipsa totală a acestuia.

Ideea generală este că e mai bună deținerea unui control restricționat decât lipsa totală a acestuia. Nu este mai bine să avem o încuietoare slabă decât să nu avem nici o încuietoare? Până la urmă, după cum sugerează înțelepciunea convențională, o înțelepciune suportată mai degrabă de emoție decât de verificare, o anumită “securitate” este mai bună decât lipsa totală a acesteia. De aceea analogia încuietorii este un exemplu atât de bun și poate să răspundă mult mai bine întrebării decât orice alt exemplu, deoarece arată foarte bine modul în care confundăm controlul atât de comun din jurul nostru.

Întreabă pe oricine care a trebuit să spargă o ușă închisă cu o încuietoare, unde a lovit-o pentru a se deschide? Răspunsul diferă în funcție de încuietoare, care poate fi exterioară sau interioară. Există un motiv pentru asta.

Atunci când o încuietoare (care se consideră a fi controlul de autentificare) este pusă pe o ușă, ușa solidă trebuie să aibă un spațiu scobit în care să se poată adăuga încuietoarea. Acest lucru creează o restricție, un punct slab în ușă. La fel se întâmplă și cu adăugarea unui mâner. Ușile fără mâner și cu încuietoare interioară nu au această restricție. Totuși e nevoie ca ușa să fie deschisă din interior prin alte moduri. Astfel, pentru a deschide o ușă cu o astfel de încuietoare, trebuie să o lovești la mâner sau la mecanismul încuietorii.

Dacă este vorba de un zăvor, această restricție nu există deoarece ușa rămâne solidă. Acele uși au nevoie de o forță de deschidere, care mai degrabă va sparge ușa decât încuietoarea. Ușile făcute pentru a rezista presiunii mari au zăvorul pe dinafară și mecanismul de deschidere în centrul ușii, sub forma unei găuri mici, precum ușile unui vapor sau ale unui submarin, pentru a împiedica slăbiciunile să spargă o parte din ușă.

Acum poți răspunde întrebării: este mai bine să existe o încuietoare slabă decât nici una? Această întrebare se referă la o ușă slabă, cu o încuietoare simplă sau ieftină (autentificare), care poate fi deschisă de cineva care vrea să intre. Deci, dacă știm că autentificarea este slabă, atunci știm că cineva poate intra sau chiar mai rău, o poate face fără să strice încuietoarea ușii, ceea ce înseamnă că nici nu ne putem da seama de intruziune. Dacă tu crezi că este în regulă, deoarece problema nu este escrocul real, ci oportuniștii care caută produsele cele mai accesibile, care sunt cel mai ușor de vândut, atunci iei o decizie riscantă; aceasta nu îți afectează suprafața de atac care este formată din ceea ce ai și nu din ceea ce vrei. În plus, dacă ai o încuietoare foarte dotată, toți oportuniștii vor ști că există ceva valoros înăuntru [1].

Dacă adaugi un control, orice control, mărești suprafața de atac la orice. Dacă acel lucru nou pe care îl adaugi aduce un nou vector de atac, atunci probabil era mai bine fără el. În unele cazuri, noul vector de atac este mai mic decât siguranța cantității actuale primite de noul control. Totuși, un control bun nu va avea restricții și poate micșora suprafața de atac.

O încuietoare dintr-o ușă nu ar trebui învârtită ușor sau adăugată la suprafața de atac într-un mod semnificativ. O asemenea încuietoare necesită forță de deschidere și atunci acest lucru adaugă încă un control asigurat de încuietoare, alarma. O încuietoare stricată este de asemenea o notificare bună pentru a anunța spargerea.

2.3 Obiectivele de asigurare a informației

Pentru a facilita înțelegerea controlului operațional, pot fi din nou adăugate la cele trei obiective de asigurare a informației, Confidențialitatea, Disponibilitatea și Integritatea. Aceste obiective sunt folosite în cadrul industriei de securitate a informației, deși se datorează, în parte, supra-simplificării; sunt mai mult pentru beneficiul de a-l conduce mai degrabă, decât de a-l crea sau a-l testa. Reprezentarea nu este perfectă, 1:1, totuși este suficientă pentru a demonstra controlul operațional în ceea ce privește triada de bază CIA (Central Intelligence Agency). Deoarece definițiile folosite pentru CIA sunt foarte extinse, reprezentarea se prezintă astfel:

2.4 Restricții

Incapacitatea mecanismelor de protecție cu care se lucrează reprezintă restricțiile lor [1]. Prin urmare, starea securității în ceea ce privește defectele cunoscute ale operațiilor, se numește Restricție. Se presupune că defectele, vulnerabilitățile, slăbiciunile și problemele în păstrarea acelei separări dintre un produs și o amenințare sau asigurarea controlului, continuă să funcționeze corect.

Restricțiile au fost clasificate în cinci categorii și aceste categorii definesc tipul vulnerabilității, greșelii sau deficiențe de operare. Este diferit de modul în care restricțiile sunt clasificate sub marea parte a contextelor de securitate a managementului și a celor mai bune practici, motiv pentru care folosim mai degrabă termenul Restricție decât termenii mai comuni, evitând astfel confuzia. Ceilalți termeni se referă la vulnerabilități sau deficiențe deoarece sunt clasificați în timpul atacului sau uneori chiar a amenințării. Există o focalizare asupra riscului din partea atacului. Totuși, pentru a elimina interferența din unitatea securității și pentru a asigura un produs mai acceptabil, am eliminat utilizarea riscului. Riscul este puternic interferat și deseori foarte variat, depinzând de mediu, produse, amenințări și mult mai mulți factori. Așadar, în cadrul SecOp folosim termenul de Restricții pentru a exprima diferența de clasificare a modului în care SecOp eșuează. Din moment ce numărul și tipul amenințărilor nu pot fi cunoscute, e mai ușor de înțeles conceptul securității sau a unui mecanism de siguranță bazat pe momentul în care va eșua. Astfel se permite Analistului să testeze condițiile în care nu se va mai susține nivelul necesar de protecție. Numai atunci când deținem acestă cunoștință putem să începem jocul amenințărilor și al riscului. După aceea putem, de asemenea, investi în tipul adecvat de separare sau control necesar și putem crea planuri exacte pentru a combate dezastrele și accidentele .

Chiar dacă aici Restricțiile sunt clasificate de la 1 la 5, nu înseamnă că se află într-o ordine ierarhică a severității. Mai degrabă sunt numerotate pentru a le diferenția, atât de planificarea operațională cât și de unitățile de măsură. De asemenea înseamnă că există șansa ca mai multe tipuri de Restricție să fie aplicate unei singure probleme. În plus, greutatea (valoarea) unei anumite Restricții se bazează pe cealaltă, care este disponibilă și tipurile de control corespunzătoare din zonele interactive față de scop, neputând există o anumită ierarhie, întrucât valoarea fiecăruia este specifică măsurilor de protecție cu scopul de a fi verificate.

În SecOp, cele cinci Restricții sunt clasificate astfel:

Vulnerabilitatea este defectul sau eroarea care: (a) refuză accesul persoanelor sau proceselor autorizate la produse, (b) permite acces privilegiat persoanelor sau proceselor neautorizate la produse sau (c) permite persoanelor sau proceselor neautorizate să ascundă produsele sau să intre de unii singuri în domeniu.

Slăbiciunea este defectul sau eroarea care întrerupe, reduce, abuzează sau anulează în mod specific efectele celor cinci tipuri de control interactiv: autentificarea, compensația, reziliența, subjugarea și continuitatea.

Preocuparea este eroarea care întrerupe, reduce, abuzează sau anulează efectele defectului sau ale executării celor cinci procese ale controlului: non-repudierea, confidențialitatea, intimitatea, integritatea și alarma [1].

Expunerea este o acțiune nejustificată, un defect sau o eroare care asigură vizibilitatea directă sau indirectă a țintelor sau a produselor, în scopul selectat.

Anomalia este orice element neidentificat sau necunoscut care nu a fost controlat și pe care nu te poți baza în procese normale.

Reprezentarea Restricțiilor

Pentru a înțelege mai bine modul în care Restricțiile se încadrează în cadrul SecOp, se pot vedea reprezentările anterioare ale securității și ale siguranței:

Reprezentarea arată modul în care Restricțiile afectează securitatea și cum sunt determinate valorile lor.

O vulnerabilitate este defectul sau eroarea care: (a) refuză accesul persoanelor sau proceselor autorizate la produse, (b) permite acces privilegiat persoanelor sau proceselor neautorizate la produse sau (c) permite persoanelor sau proceselor neautorizate să ascundă produsele sau să intre de unii singuri în domeniu. Asta înseamnă că Vulnerabilitatea trebuie reprezentată în toate punctele de interacțiune sau în SecOp; deoarece Vulnerabilitatea poate naviga în jur sau anula Controlul, acestea trebuie de asemenea, luate în considerare pentru măsurarea Vulnerabilității.

O slăbiciune este un defect din Controlul Clasei A, dar totuși poate avea un impact asupra SecOp, deci este reprezentată în toți parametrii SecOp, la fel cum sunt reprezentate în această categorie interactivă a controlului [1].

O preocupare poate fi găsită numai în Controlul Clasei B. Totuși poate avea un impact asupra SecOp, deci este reprezentată în toți parametrii SecOp, la fel cum sunt reprezentate în această categorie de procese a controlului.

O expunere ne învață despre interacțiunea cu o țintă și astfel reprezintă în mod direct Vizibilitatea și Accesul. Această cunoștință poate de asemenea, ajuta un atacator să navigheze în jurul câtorva sau a tuturor categoriilor, astfel încât Expunerea este reprezentată în ambele clase de control. În cele din urmă, Expunerea nu are nici o valoare dacă nu există o modalitate de a folosi această cunoștință, în exploatarea produsului, sau un Control, și așa Vulnerabilitățile, Slăbiciunile și Preocupările joacă un rol în măsurarea valorii Expunerii.

O anomalie este un element neidentificat sau necunoscut care nu a fost controlat și nu poate fi luat în considerare în operații normale. Faptul că nu a fost controlat și nu poate fi luat în considerare, înseamnă că are o legătură directă cu Încrederea. Restricția poate, de asemenea, provoca anomalii în modul de funcționare a Controlului, fiind astfel inclusă în procesul de măsurare. În sfârșit, la fel ca în cazul Expunerii, Anomalia nu poate afecta SecOp de una singură, fără existența fie a Vulnerabilității, a Slăbiciunii sau a Preocupării care pot exploata acest comportament rar.

În plus, se pot aplica mai multe categorii unei restricții, atunci când defectul împarte SecOp în mai multe locuri. De exemplu, un control de Autentificare ce permite unei persoane să confiște acreditarea altei persoane, suferă de Slăbiciune, iar acreditarea ar trebui să permită Acces, care de asemenea cuprinde Vulnerabilitatea.

Într-un alt exemplu, un control de Autentificare utilizează o listă comună de nume care corespund adreselor electronice. Fiecare adresă care poate fi găsită sau ghicită și folosită pentru conectare este o Expunere, în timp ce, chiar și controlul are o Slăbiciune față de neputința de a identifica utilizatorul adevărat al mecanismului de autentificare, din procesul de conectare. Dacă orice acreditare permite Accesul, atunci îl includem de asemenea în lista Vulnerabilității.

Justificarea Restricțiilor

Conceptul că restricțiile sunt numai restricții dacă nu au decât justificare de afaceri este fals. O restricție este o restricție dacă se comportă ca unul din factorii restrictivi descriși aici. Justificarea unei restricții este o decizie riscantă care este luată fie cu un control, fie cu un fel de acceptare a restricției. Deciziile riscante care acceptă restricțiile așa cum sunt se rezumă deseori la: alterarea care poate fi provocată de o restricție, nu justifică costul de a fixa sau de a controla restricția; aceasta trebuie să rămână în concordanță cu legislația, contractele sau politica, sau cu garantarea că nu există o amenințare, iar dacă există, este puțin probabilă pentru acest tip de restricție. Întrucât justificările riscante nu fac parte din calcularea suprafeței de atac, toate restricțiile descoperite trebuie să fie luate în considerare în cadrul acesteia, indiferent dacă cea mai bună practică, practica comună sau practica legală indică lipsa riscului. Dacă nu are loc, atunci verificarea nu va da dovadă de o reprezentare reală securității operaționale ce definește scopul.

Administrarea Restricțiilor

Un alt concept care trebuie luat în considerare este cel al defectelor și erorilor de administrare din procesul de verificare. Trei din cele mai directe moduri de a administra restricțiile sunt eliminarea zonei problematice care menține punctele interactive împreună, le fixează sau le acceptă ca și parte din afacere, cunoscută drept justificarea afacerii.

O verificare va descoperi deseori mai multe probleme a țintei. Analistul trebuie să raporteze restricțiile țintei și nu doar țintele slabe. Aceste restricții probabil fac parte din măsurile de protecție și control, diminuând puterea SecOp. Fiecare restricție trebuie notată în funcție de ceea ce se întâmplă atunci când este invocată problema, chiar dacă invocarea este teoretică sau verificarea are o executare limitată de a restricționa daunele actuale. Clasificarea teoretică, unde nu se poate face nici o verificare, este un teren minat și ar trebui să fie limitată cazurilor în care verificarea ar reduce calitatea operațiilor. Atunci când se clasifică problemele, fiecare restricție ar trebui analizată și calculată în termeni specializați de operație până la componentele de bază. Totuși, Analistul ar trebui să fie sigur, să nu raporteze niciodată “un defect dintr-un defect”, în care defectele împart aceeași componentă și același efect operațional. Un exemplu ar fi o ușă spartă cu un geam spart. Deschizătura ușii este un Acces chiar dacă la fel este și geamul spart, dar ambele reprezintă aceeași componentă, ușa indică drumul, și același efect operațional, deschizătura. Un exemplu din Data Networks ar fi un sistem al unui calculator care trimite un răspuns esențial, cum ar fi ICMP “ușa închisă” pachetul T03C03, unui port particular. Această interacțiune nu este luată în considerare pentru toate porturile de acest fel, întrucât Accesul provine din aceeași componentă, esență, și are același efect operațional, trimițând un pachet T03C03 la portul interogat [1].

2.5 Securitate Actuală

Rolul controlului este de a controla porozitatea în SecOp. Este ca și cum ai avea 10 moduri de a controla amenințările care au venit prin gaura din perete. Pentru fiecare gaură, maxim 10 tipuri diferite de control pot fi aplicate, care readuc securitatea, câteodată și până la 100%. Atunci restricțiile reduc eficacitatea SecOp și a Controlului. Rezultatul unei verificări care descoperă și arată securitatea, Controlul și Restricțiile, demonstrează efectiv Securitatea Actuală.

Securitatea Actuală este un termen pentru o suprafață de atac instantanee dintr-un mediu operațional. Este o reprezentare logaritmică a Controlului, Restricțiilor și a SecOp în anumite momenete particulare. Este logaritmică deoarece reprezintă realitatea mărimii, unde un scop mai mare va avea o suprafață de atac mai mare, chiar dacă din punct de vedere matematic Controlul va balansa SecOp. O folosim pentru construirea blocurilor, putând înțelege mai bine funcționarea securității, iar vizualizarea pe care o realizăm de aici este echilibrul efectiv creat între locul în care se poate produce un atac, locul în care Controlul poate administra un atac și restricțiile măsurilor de protecție.

Un alt beneficiu al reprezentării matematice a unei suprafețe de atac luată drept Securitate Actuală, este că pe lângă a arăta numai locul în care lipsesc măsurile de protecție, poate arăta de asemenea și opusul. Întrucât este posibilă existența mai multor tipuri de control decât este necesar, se poate reprezenta matematic la mai mult de 100% RAV. Chiar dacă evaluarea de risc poate face acest punct posibil, reprezentarea matematică este folositoare pentru arătarea risipei. Poate fi folosită pentru a demonstra că banii pot fi cheltuiți în cantități mari pe tipurile greșite de control sau pe tipurile excesive de control.

2.6 Acordul

Acordul este diferit de securitate și există separat de aceasta. Este posibil de a fi de acord, și totuși nesigur și este posibil de a fi relativ sigur, dar nu și de acord, iar de aici rezultă lipsa de încredere.

Proiectele despre acord nu reprezintă timpul de a redefini solicitările securității operaționale ca un rezultat al unui test SecOp, dar totuși pot reprezenta timpul specific testării SecOp, într-o bază periodică, pentru a îndeplini solicitarea unui control schițat, ca un rezultat al unei evaluări bazate pe încredere, care a supravegheat numărul minim de control solicitat pentru a dobândi un stat conform (nu trebuie neapărat să fie asigurat) [1].

Marea problemă cu acordul este că necesită multă documentație care trebuie scrisă și adusă la zi. Aceasta documentație poate fi despre procesele de afaceri, narative, evaluări de încredere, evaluări de risc, teste deconectate de design, verificări operaționale, atestări și așa mai departe. Această documentație este verificată de controlori financiari și trebuie să își îndeplinească în mod logic existența într-o lume a statului.

Cele mai recente eforturi de acord au fost conduse de solicitări pe termen scurt a regulațiilor impuse, cu solicitări de implementare de scurtă durată. Astfel s-au creat multe solicitări de resurse și cost. În timpul alocat meditării asupra sa, încercăm să construim acordul, să evidențiem producția printr-un proces și să administrăm această resursă de echilibru și cost.

Acordul este o abordare largă a aplicării formei cele mai practice, atâta timp cât privește Tehnologia Informației, probabilitățile COBIT (Information Systems Audit and Control Association) și ITIL (Information Technology Infrastructure Library); un test SecOp ar trebui să asigure documentația care prevede un nivel inteligibil și verificat al calității. Totuși, utilizarea SecOp este desemnată pentru a permite Analistului să vadă și să înțeleagă securitatea și siguranța. Prin urmare, odată cu utilizarea acestei metodologii, orice acord este, cel puțin, producția evidentă a guvernării din procesul de afacere a securității [1].

3. Ce trebuie să faci

De unde să începi? Testarea este o afacere complicată, iar ca orice lucru complicat, o abordezi încet, în părți mici, pentru a fi sigur că nu vei greși.

Înțelepciunea convențională arată că, complexitatea este dușmanul securității. Totuși, există șanse numai cu natura umană. Orice este mai complex nu este în mod inerent și nesigur. Ia drept exemplu un calculator care poate îndeplini sarcini complicate. După cum știm, problema nu constă în faptul că acel calculator va face greșeli, va încurca sarcinile sau va uita să termine unele dintre ele. Cu cât sunt adăugate mai multe sarcini, acesta va începe să funcționeze din ce în ce mai încet, luându-i mai mult timp să le termine pe toate. Totuși, oamenii fac greșeli, uită sarcinile și abandonează sarcini cu voia lor, fie pentru că nu sunt importante, fie pentru că nu sunt necesare în acel moment. Deci, atunci când se testează securitatea, este nevoie să se administreze corect orice complexitate. Acest lucru se poate face definind corect testul de securitate.

3.1 Definirea testului de securitate

Acești 7 pași te vor duce la începutul testului de securitate definit corect.

Definește ceea ce vrei să protejezi. Acestea sunt produsele. Mecanismul de protecție pentru aceste produse constă în tipurile de Control pe care le vei testa pentru a identifica Restricțiile.

Identifică zona din jurul produselor care includ protejarea mecanismelor și a proceselor sau a serviciilor construite în jurul produselor. Aici este locul în care va avea loc interacțiunea cu produsele. Este zona ta de angajament.

Definește tot ce se află în afara zonei de angajament pentru a putea să îți menții produsele operaționale. Pot fi lucruri pe care nu le poți influența în mod direct, cum ar fi electricitatea, mâncarea, apa, aerul, pământul stabil, informația, legislația, regulațiile și lucruri cu care ai putea să lucrezi, cum ar fi uscarea, căldura, frigul, claritatea, contractorii, colegii, firma, parteneriatul și așa mai departe. De asemenea este bine de știut că ceea ce menține infrastructura operațională sunt procesele, protocolul și resursele permanente. Acesta este scopul testului tău.

Definește modul în care testul tău interacționează cu el însuși și cu exteriorul. Comportamentalizează în mod logic produsele din scop prin direcția interacțiunilor, cum ar fi din interior în exterior, din exterior în interior, din interior în interior, din departamentul A în departamentul B etc. Aceștia sunt vectorii tăi. Fiecare vector ar trebui să fie un test separat pentru a menține durata scurtă a fiecărui test comportamentalizat, înainte de a avea loc prea multă schimbare de mediu [1].

Identifică tipul de echipament de care vei avea nevoie la fiecare test. În fiecare vector, pot avea loc interacțiuni la mai multe nivele. Aceste nivele pot fi clasificate în mai multe moduri, dar totuși aici au fost clasificate în funcție de 5 canale. Ele sunt Uman, Fizic, Wireless, Telecomunicații și Rețeaua de Date. Fiecare canal trebuie să fie testat separat, pentru fiecare vector. [1]

Determină informația pe care vrei să o înveți de la test. Vei tasta interacțiunile cu produsele sau, de asemenea, răspunsul de la măsurile active de securitate? Tipul testului trebuie să fie definit individual pentru fiecare test, dar totuși aici există șase tipuri comune identificate, cum ar fi: Pe nevăzute, Dublă pe nevăzute, Cutia Gri, Cutia dublă gri, Tandem și Inversare.

Asigură-te că securitatea testului, pe care ai definit-o, este în acord cu Regulile de Angajament, un ghid folosit la asigurarea procesului unui test de securitate, fără a crea neînțelegeri, concepții greșite sau false așteptări.

Rezultatul final va fi măsurarea Suprafeței de Atac. Suprafața de atac este partea neprotejată a Scopului dintr-un Vector nedefinit.

3.2 Scopul

Scopul este întreg mediul posibil de securitate operațională pentru orice produs care poate include și componentele măsurilor de securitate. Scopul este cuprins în trei clase și cinci canale: Canalele de Telecomunicații și Rețea de Date care fac parte din clasa COMESC, Canalele de Fizică și Securitate Umană din clasa PHYSSEC și întreg Canalul de Securitate Wireless din clasa SPESEC. Clasele fac parte din desemnări oficiale folosite momentan în industria securității, guvern și armată. Clasele sunt folosite pentru a defini o zonă de învățământ, investigare sau operare. Totuși, Canalele sunt mijloacele specifice de a interacționa cu produsele. Un produs poate fi orice lucru care reprezintă o valoare sentimentală proprietarului. Produsele pot fi proprietăți fizice, cum ar fi aurul, oamenii, laptopurile, semnalul tipic de frecvență a telefonului mobil de 900 MHz și banii; sau proprietate intelectuală cum ar fi informațiile personale, relația, numele firmei, procesele afacerii, parolele și ceea ce se comunică prin semnalul telefonului de 900 MHz. Uneori, scopul se extinde mult mai departe de raza de acțiune a deținătorului produsului, din moment ce dependențele sunt mai departe de abilitatea deținătorului produsului de-a se aproviziona într-un mod independent. Scopul necesită ca toate amenințările să fie considerate posibile, chiar dacă nu sunt probabile. Totuși, trebuie clarificat faptul că analiza unei securități trebuie restricționată astfel încât să fie în tipul siguranței (a nu se confunda cu riscul care nu este o certitudine, ci o probabilitate). Aceste restricții includ:

Non-evenimente precum erupția unui Vulcan în locuri în care nu există vulcani.

Non-impact precum raza lunii prin fereastra centrului de informații, sau

Impactarea globală precum impactul catastrofic al unui meteorit.

În timp ce o verificare completă a securității necesită testarea tuturor celor 5 canale, în realitate, testele sunt realizate și clasificate de către expertiza necesară a Analistului și de către echipamentul pentru verificare.

Canalele

În timp ce canalele și diviziile lor pot fi reprezentate în orice fel, în acest capitol sunt organizate sub forma unor modalități de recunoaștere a comunicației și a informației. Această organizație este desemnată pentru a facilita procesul de testare în timpul minimalizării ineficienței asupra acesteia, care este deseori asociată cu metodologii stricte [1].

3.3 Tipuri comune de teste

Aceste șase tipuri diferă în funcție de cantitatea de informație cunoscută de persoana care le testează drept ținte, ceea ce ținta știe despre ei sau la ce se așteaptă de la test, și despre legitimitatea testului. Unele teste vor testa aptitudinile, mai mult decât orice testând siguranța țintei.

Figura 3.1- Tipuri comune de testare

De reținut că atunci când se raportează verificarea, există deseori o cerere de a identifica exact tipul verificării performante. De cele mai multe ori verificările bazate pe diferite tipuri de teste sunt comparate pentru a urmări delta (deviațiile) de la stabilirea liniei de bază, până la scop. Dacă nu este disponibil tipul precis de test unui redactor sau unui regulator, verificarea ar trebui considerată ca un test pe nevăzute, care are cel mai mic merit față de testul complet de securitate [1].

3.4 Regulile Angajamentului

Aceste reguli definesc ghidul operațional al practicilor acceptabile din marketing și din testarea vânzării, performând sarcini de testare și ocupându-se de rezultatele testării angajamentului.

Vânzări și Marketing

Utilizarea fricii, nesiguranței, îndoielii și decepției nu pot fi folosite în prezentările vânzării și a marketingului, pe paginile de internet, în materialele de sprijin, în rapoarte sau în discuții despre testarea de securitate cu scopul de a vinde sau de a aproviziona teste de securitate. Aceasta include, dar nu în cantități limitate, evidențierea criminalilor, a faptelor, criminalii promovați sau profilul hackerilor și statisticile de a promova vânzările [1].

Este interzisă oferta serviciilor gratuite pentru eșec, pentru a pătrunde în țintă.

Sunt interzise procedeele de pătrundere fără autorizație în sisteme de securitate, pentru a promova evaluarea securității vânzărilor sau testarea marketingului de securitate, sau produsele de securitate.

Se permite a numi foști clienți sau clienți actuali din marketing sau vânzări, pentru clienți potențiali, numai dacă munca față de client a fost în mod specific aceeași, de a fi promovat sau vândut, iar clientul din acest caz a avut permisiunea scrisă de a proceda în această manieră.

Se recomandă sfătuirea corectă și factuală a clienților în ceea ce privește siguranța lor și măsurile de protecție. Ignoranța nu este o scuză pentru consultarea necinstită.

Evaluarea/ Livrarea Estimată

Este strict interzisă performarea testelor de securitate împotriva oricărui scop, fără permisiunea scrisă de la proprietarul țintei sau autoritatea adecvată.

Este interzisă testarea securității sistemelor instabile și de nesiguranță înaltă a locurilor și proceselor, până se stabilește o infrastructură adecvată pentru securitate.

Contracte și negocieri

Cu sau fără un contract de Acord Non-Divulgare, Analistul securității trebuie să asigure confidențialitatea și non-divulgarea informației despre client și rezultatele testelor.

Contractele ar trebui să limiteze răspunderea cu prețul slujbei, cu excepția dovedirii activității malicioase.

Contractele trebuie să explice în mod clar limitele și pericolele testului de securitate, sub forma unei declarații de muncă.

În cazul testării de la distanță, contractul trebuie să includă locul de origine a Analistului, adresa, numărul de telefon și adresa IP.

Clientul trebuie să garanteze un acord semnat care asigură permisiunea testării, scutind Analistul de a încălca scopul și strica răspunderea cu prețul serviciului verificării, cu excepția cazurilor în care a avut loc o activitate malițioasă.

Contractele trebuie să conțină contacte în caz de urgență și numere de telefon.

Contractele trebuie să includă permisiuni clare și specifice despre eșecurile testelor care cuprind datele de supraviețuire, refuzarea serviciilor și ingineria socială.

Contractele trebuie să conțină procesul pentru schimbarea contractelor și a declarațiilor de muncă (SOW).

Contractele trebuie să conțină conflicte verificate de interes pentru un test de securitate ce conține și raport.

Scopul Definiției

Scopul trebuie să fie definit clar în contract înainte de a verifica serviciile de vulnerabilitate.

Verificarea trebuie să explice în mod clar limitele oricărui test de securitate, în concordanță cu scopul [1].

Planul de Testare

Planul de test poate să nu conțină planuri, procese, tehnici sau procedee care se află în afara zonei de expertiză sau a nivelului de competență a Analistului.

Procesul de Testare

Analistul trebuie să respecte și să mențină siguranța, sănătatea, bunăstarea și intimitatea publicului, atât din interiorul cât și din exteriorul scopului.

Analistul trebuie să acționeze mereu în cadrul legii locațiilor fizice a țintelor, pe lângă regulile și legile care guvernează locația de test a Analistului.

Pentru a preveni creșterea temporară a securității din timpul testului, numai oamenii selectați pot cunoaște detalii despre testare. Clientul poate distinge acești oameni; totuși, se crede că ei sunt păstrătorii informației, administratorii proceselor de securitate, personalul ce răspunde de incidente și echipa operațiilor de securitate.

În cazuri necesare pentru testarea privilegiată, clientul trebuie să asigure două simboluri de acces diferite, indiferent dacă sunt parole, certificate, numere de identitate, insigne etc. și ar trebui să fie mai degrabă tipice utilizatorilor privilegiați, decât acceselor goale și sigure.

Când testarea include privilegii cunoscute, Analistul trebuie să testeze în primul rând fără privilegii (ca în mediul cutiei negre), înainte de a testa din nou cu privilegii.

Se cere ca Analiștii să își cunoască locul de origine a instrumentelor, modul cum ele funcționează și să le testeze într-o zonă restricționată de testare înainte de a le folosi în organizația clienților.

Realizarea testelor care trebuie să probeze negarea unui serviciu sau a unui proces sau supraviețuirea, poate fi făcută numai cu permisiunea explicită și numai în scopul în care nici o daună nu se face în afara scopului, sau a comunității în care scopul își are reședința.

Testele care includ oameni pot da rezultate numai pe cei identificați în scop și nu pot include persoane private, clienți, parteneri, asociați sau alte entități externe, fără permisiune scrisă de la ele.

Restricțiile verificate, precum încălcările descoperite, vulnerabilitățile cu rate cunoscute sau înalte de exploatare, vulnerabilități care sunt exploatate pe deplin, acces nemonitorizat și nedetectat, sau care poate pune în pericol vieți, descoperirea din timpul testului trebuie raportată clientului împreună cu o soluție practică, imediat ce s-a găsit.

Este interzisă orice formă de testare a inundației în care scopul este copleșit de o sursă mai mare și mai puternică de-a lungul canalelor non-private [1].

Analistul nu trebuie să părăsească scopul într-o poziție de mai puțină securitate actuală, decât a fost când s-a prevăzut.

Raportarea

Analistul trebuie să respecte intimitatea tuturor persoanelor și să le mențină intimitatea cu orice preț.

Rezultatele care includ persoane neantrenate în domeniul securității sau a non-securității, pot fi raportate numai prin mijloace statistice și de non-identificare.

Analistul nu poate semna rezultatele testării și rapoartele verificării în care nu a fost implicat personal.

Rapoartele trebuie să rămână obiective și fără minciuni sau orice răutăți adresate personal.

Se solicită notificările clienților indiferent dacă Analistul schimbă planul de testare, schimbă sursa de testare, are încredere scăzută în dispozitivele de căutare sau în orice probleme de testare care au avut loc. Notificările trebuie solicitate înainte de a se învechi, de a deveni periculoase sau de a fi solocitate testarea traficului înalt și progresul regular la zi.

În cazurile în care se includ soluții și recomandări în raport, trebuie să fie valide și practice.

Raporturile trebuie să conțină toate necunoscutele și anomaliile.

Raporturile trebuie să declare în mod clar, atât descoperirea cu success a măsurilor de securitate și eșecul lor, cât și controlul de pierdere.

Raporturile trebuie să folosească numai unități de măsură cantitative pentru măsurarea securității. Aceste unități trebuie să se bazeze pe fapte și să evite interpretările subiective.

Clientul trebuie anunțat de trimiterea raportului pentru a îi putea aștepta sosirea și pentru a confirma livrarea primită.

Toate canalele de comunicare pentru livrarea raportului trebuie să fie confidențiale de la un capăt la celălalt.

Rezultatele și raporturile nu pot fi niciodată folosite pentru câștig comercial, mai presus de cea a interacțiunii cu clientul.

3.5 Procesul de Testare a Securității Operaționale

De ce să testăm operațiile? Din păcate, multe lucruri nu funcționează așa cum au fost configurate. Nu toată lumea se comportă după cum a fost antrenată să o facă. Prin urmare, adevărul configurației și al antrenării se află în operațiile rezultante. De aceea trebuie să testăm operațiile [1].

Procesul de testare a SecOp este un test al evenimentelor discrete a unui sistem dinamic și stochastic. Înseamnă că vei face o secvență cronologică de teste într-un sistem care schimbă și nu oferă mereu aceeași producție admisiei prevăzute. Ținta este un sistem, o colecție de procese interactive și co-dependente care este de asemenea influențată de mediul stochastic în care există. A fi stochastic înseamnă că, comportamentul evenimentelor într-un sistem nu poate fi determinat, deoarece următoarea stare de mediu poate fi determinată doar parțial, și nu complet de către starea anterioară. Sistemul conține un număr finit, dar care poate ajunge la un număr mare de variabile, iar fiecare schimbare din variabile poate prezenta un eveniment și o schimbare a stării. Din moment ce mediul este stochastic, există un element al întâmplării și nu există o modalitate de a predetermina cu certitudine modul în care toate variabilele vor afecta starea sistemului.

Marea parte din ceea ce înțeleg oamenii despre SecOp provine din aspectul defensiv care poate fi înțeles, întrucât securitatea este considerată în general o strategie defensivă. Testarea agresivității a SecOp este deci retrogradată în aceeași clasă ca și exploatarea și eludarea schiței curente a configurării. Totuși, problema fundamentală a acestei tehnici este că o schiță sau o configurare nu poate fi egală cu operația.

Există multe momente din viață în care operația nu se conformează cu configurația. Un exemplu simplu este descrierea locului de muncă tipic. Este mai comun decât acela al politicii care dictează slujba, cunoscută de asemenea ca descrierea locului de muncă, se încadrează pe scurt în a reflecta ceea ce facem la muncă. Un alt exemplu este canalul de televiziune. Deoarece un canal este setat pe o frecvență particulară (configurată), nu înseamnă că vom primi difuzarea emisiunii pe acel canal sau că vom primi numai acea emisiune.

Metodologia testării securității este desemnată pe principiul verificării operațiunilor de securitate. În timp ce nu poate testa mereu în mod direct procesele și metodele, un test realizat cu succes va permite analizarea atât a informațiilor directe, cât și a celor indirecte, pentru a studia diferența dintre operații și procese. Acest lucru va arăta mărimea fisurii dintre ceea ce administrarea așteaptă de la operațiile proceselor pe care le-au dezvoltat și ceea ce se întâmplă cu adevărat. Mai simplu de atât, scopul Analistului este de a răspunde la întrebarea: “Cum funcționează operațiile actuale și cum funcționează diferit de modul în care administrarea crede că funcționează?”

Un punct de referință este cercetarea extensivă disponibilă asupra controlului schimbării pentru procesele care limitează cantitatea evenimentelor interminabile din sistemul stochastic. Analistul va încerca deseori să depășească constrângerile controlului de schimbare și să prezinte scenarii “cum ar fi fost dacă” pe care implementatorii controlului de schimbare s-ar putea să nu le fi luat în considerare. O înțelegere completă a controlului de schimbare este esențială pentru orice Analist.

Un test de securitate operațională necesită prin urmare, o înțelegere completă a proceselor de testare, alegând modelul corect de test, recunoscând canalalele și vectorii testului, definind scopul conform indexului corect și aplicând corect metodologia [1].

În mod straniu, în nici un loc, exceptând în cadrul testării securității, testul ecoului nu este considerat testul factor. Precum țipând într-o peșteră și așteptând răspuns, procesul de ecou necesită interacțiunea și pe urmă monitorizarea emanațiilor din ținta pentru indicatorii unei stări particulare, precum siguranța și nesiguranța, vulnerabilitatea și protecția, pornit sau oprit și stânga sau dreapta. Procesul de ecou este cel al unui tip cauză- efect al verificării. Analistul face cauza și analizează efectul asupra țintei. Este straniu că acesta e modul principal de a testa ceva atât de critic precum securitatea, deoarece, chiar dacă realizează un test foarte rapid, este de asemenea predispus erorilor, unele dintre care pot fi devastatoare țintei. Se poate considera că într-un test de scuritate în care se folosește procesul de ecou, o țintă care nu răspunde este considerată sigură. Urmând acea logică, o țintă trebuie să fie non-responsivă față de un anumit tip de cerere pentru a da aparența de securitate, chiar dacă este pe deplin interactivă cu alte tipuri de cereri care arată că nu a avut loc nici o separare.

Dacă spitalele ar fi folosit procesul de ecou pentru a determina sănătatea unei persoane, ar ajuta rar oamenii, dar măcar timpul petrecut în sala de așteptare ar fi foarte scurt. Totuși spitalele, precum majoritatea industriilor științifice, aplică Procesul Numărului Patru, care include o funcție a procesului de ecou numită “interacțiune”, precum unul din cele patru teste. Celelalte trei teste sunt “ancheta” emanațiilor citite de către pacient precum pulsul, presiunea sângelui și undele cerebrale; “intervenția” schimbării și accentuării condițiilor de operare precum homeostazia, comportamentul, rutina sau nivelul de confort al pacientului; și “inducția” examinării mediului înconjurător și modul în care s-ar putea să fi afectat ținta, precum analizarea lucrurilor cu care pacientul a interacționat, pe care le-a atins, le-a mâncat, le-a băut sau ce a respirat. Totuși, în testarea securității, marea parte a testelor sunt bazate numai pe procesul de ecou. Există atât de multă informație pierdută într-o testare de o singură dimensiune încât ar trebui să fim recunoscători că industria medicală a evoluat atât de mult și a trecut de faza de diagnosticare “Te doare dacă apăs aici?”.

Procesul testării de securitate din această metodologie nu recomandă numai procesul de ecou pentru rezultate sigure. În timp ce procesul de ecou poate fi folosit pentru anumite teste particulare în care marja de eroare este mică, iar eficacitatea marită permite timpului să fie schimbat cu alte tehnici intensive de-a lungul timpului, nu se recomandă pentru testele din exterior pentru un mediu determinat. Analistul trebuie să aleagă cu atenție când și sub ce condiții să aplice procesul de ecou.

În timp ce există multe procese de testare, Procesul de Patru Puncte pentru testarea securității este desemnat pentru eficacitate, precizie și meticulozitate optimă, pentru a asigura validitatea testului și să minimizeze erorile în medii necontrolate și stochastice. Este optimizată pentru scenarii de test din viața reală din exteriorul laboratorului. În timp ce folosește de asemenea agitația, diferă de procesul de ecou în aceea că permite, determinarea mai multor cauze pe efect și mai mult decât un efect pe cauză [1].

3.6 Procesul de Patru Puncte

Procesul de Patru Puncte (PPP) dărâmă un test de la început la sfarstit. Sunt lucruri deja realizate de către un grup experimentat de testare. A nu se confunda formalitatea din disecarea unui proces, cu formalitatea reportării. Nu este nevoie să arăți realizarea fiecărui pas, dar ar trebui să înțelegi cum ajungi de la A la C. Este ca și cum ai preda condusul. Le spui pașii pe care trebuie să îi urmeze și proximitatea relativă a lucrurilor pe care le vor vedea, pentru a ști că merg pe drumul cel bun, dar nu le spui să meargă pe fiecare stradă și nu le spui fiecare semn din trafic pe care trebuie să îl urmeze pentru a ajunge la destinație. Deci, PPP reprezintă îndrumarea specifică, iar modul și raportarea sunt de fapt acele relativistice.

Figura 3.2- Procesul celor 4 puncte

Inducția: (Z) stabilirea principiului adevărului despre țintă, din legile și faptele mediului înconjurător. Analistul determină principiile factuale cu privire la ținta din mediul înconjurător, în care aceasta își are reședința. Din moment ce ținta va fi influențată de mediul înconjurător, comportamentul său va fi determinat de influența sa. Unde ținta nu este influențată de mediul înconjurător, există o anomalie care trebuie înțeleasă [1].

Ancheta: (C) investigarea emanațiilor țintei. Analistul investighează emanația țintei și orice urmă sau indicator al acelei emanații. Un sistem sau un proces va lăsa în general, o semnătură a existenței sale prin interacțiunile cu mediul înconjurător.

Interacțiunea: (A/B) precum testele de ecou, standard și non-standard interacționează cu ținta pentru a declanșa răspunsurile. Analistul se va interesa sau va tulbura ținta pentru a declanșa răspunsurile analizei.

Intervenția: (X/Y/Z) resursa de schimbare interacționează cu ținta sau între ținte. Analistul va interveni cu resursele solicitate de țintă, din mediul său înconjurător sau din interacțiunile sale cu alte ținte pentru a înțelege extremele sub care poate continua să funcționeze într-un mod adecvat.

3.7 Trifecta

Metodologia de testare a securității are o bază solidă care ar putea părea destul de complicată, dar de fapt este chiar simplă în realitate. Este desemnată ca o diagramă a fluxului; totuși, spre deosebire de standardul diagramei fluxului, fluxul este reprezentat de săgeți, care pot merge atât înainte, cât și înapoi. Astfel, se integrează mai bine, iar atâta timp cât începutul și sfârșitul sunt clare, verificarea are o flexibilitate mai mare. Analistul crează o cale unică prin metodologia bazată pe țintă, pe tipul testului, pe timpul alocat verificării și pe resursele alocate testului. În cazul unei orchestre, compozitorul scrie muzică pe foi pentru a desemna ordinea și durata notelor, dar numai dirijorul poate controla executarea performanței. Aceasta metodologie se aseamănă cu muzica scrisă pe foi, desemnând testele necesare, dar Analistul este cel care controlează ordinea, durata și executarea. Motivul principal de solicitare a acestui nivel de flexibilitate în SecOp este acela că nici o metodologie nu poate preupune în mod precis justificările operațiilor portalelor canalului într-o țintă și nivelul adecvat al securității. Mai direct de atât, aceasta metodologie nu poate presupune cea mai bună practică pentru realizarea tuturor verificărilor, din moment ce cea mai bună practică se bazează pe o configurare specifică a operațiilor [1].

Cea mai bună practică este cea mai bună, numai pentru unele cazuri; în general celui care a inventat practica. Operațiile spun cum ar trebui să fie serviciile oferite, iar acele servicii dictează solicitările pentru securitatea operațională. Prin urmare, o metodologie care este invocată în mod diferit pentru fiecare verificare și de către fiecare Analist, poate încă avea același rezultat final, dacă Analistul termină metodologia. Din acest motiv una din fundamentele SecOp este înregistrarea exactă a ceea ce nu a fost testat. Comparând ceea ce a fost testat și mărimea testului cu alte teste, este posibilă măsurarea securității operaționale (SecOp) bazată pe rezultatele testului.

Aplicând aceste metodologii vom întâlni scopul Analistului de a răspunde următoarelor trei întrebări care realizează Trifecta, pentru a răspunde nevoilor SecOp.

Cum funcționează operațiile actuale?

Unitățile măsurate pot fi aplicate pentru a determina problema zonelor din scop.Unitățile din această metodologie sunt desemnate pentru a plănui problemele în moduri diferite, pentru a arăta dacă problema este una generală sau una specifică, precum omiterea sau greșeala.

Cât de diferită este funcționarea lor de ceea ce crede administrația?

Accesul la evaluarea politicii sau a încrederii (sau chiar a unui risc) vor reprezenta diferite categorii a unității de măsură. Categoriile asigură valorile stării actuale în care se poate face o comparație, atât cu starea optimă conform politicilor, cât și cu cea conform amenințărilor evaluate.

Cum trebuie să funcționeze?

Unde unitățile de măsură nu arata nici o lipsă între evaluarea valorii optime a politicii și încrederii (sau a riscului), dar totuși testele de securitate arată că există o problemă de protecție, indiferent de controlul implementat în politică, este posibilă clarificarea problemei denotate. Deseori, chiar fără a reprezenta o problemă, este destul de evidentă discrepanța dintre controlul implementat și pierderea protecției [1].

Combinarea dintre Trifecta și Procesul de Patru Puncte

Trifecta combinată cu procesul de patru puncte asigură o aplicație completă a metodologiei din punct de vedere substanțial. Se pot rezuma pașii din această aplicație după cum urmează:

Colectarea pasivă a informațiilor din operațiile normale pentru a putea înțelege ținta.

Figura 3.3- Combinarea dintre trifecta si procesul de patru puncte

Testarea operațiilor în mod activ prin agitarea acestora dincolo de linia de bază normală.

Analizarea informațiilor primite direct de la operațiile testate.

Analiza indirectă a informațiilor de la resurse și operatori (adică muncitori, programe).

Corelarea și reconcilierea inteligenței de la rezultatele testării informațiilor directe (pasul 3) și indirecte (pasul 4), pentru a determina procesele de securitate operațională.

Determinarea și reconcilierea erorilor.

Conducerea unităților de măsură atât din operații normale, cât și din operații agitate.

Corelarea și reconcilierea inteligentă dintre operațiile normale și cele agitate (pașii 1 și 2), pentru a determina nivelul optim al protecției și al controlului care ar putea fi implementate mai bine.

Reprezentarea stării optime a operațiilor (pasul 8) și a proceselor (pasul 5).

Crearea unei analize lipsă, pentru a determina ce tip de intensificări sunt necesare proceselor care guvernează protecția și controlul necesar (pasul 5), pentru a dobândi starea operațională optimă (pasul 8) de la cea actuală.

3.8 Eroarea Manipulării

Realitatea unui test de securitate nu este suma erorilor, ci mai degrabă calculul acestora. Întrucât erorile nu pot fi greșelile Analistului, cunoașterea modului și locului în care erorile pot exista într-un test este mai rezonabilă decât a ne aștepta ca un Analist să realizeze teste fără erori. În plus, Analistul este cel care încearcă ceea ce nu este posibil, fiind mai probabil să întâlnească erori; prin urmare, denotarea erorilor ca pe un lucru negativ reduce practic testăriile complete.

Lucrul cu testarea erorilor

În timpul fazei de analizare, un Analist poate ține evidența cantității și severității erorilor operaționale din timpul testului. O simplă auto-evaluare poate crea o limită a erorilor operaționale cauzate în timpul testului pe care Analistul le poate folosi, fie pentru a încadra completitudinea verificării actuale, fie pentru alte verificări a sistemelor similare.

Întrucât este o auto-evaluare, va exista o tendință de a fi influențată. Analistul ar trebui să aibă mare grijă pentru a fi cât se poate de real, ca o formă a asigurării calității testului și procesele testului. Chiar dacă unii încearcă să înlăture erorile testării care au fost făcute din vina Analistului, ținând evidența tuturor erorilor poate numai să îmbunătățească testele viitoare, iar acest lucru nu trebuie ascuns. Erorile vor avea loc și nu sunt decât încercarea Analistului de a interacționa cu un sistem care se schimba mereu. Indiferent de numărul și severitatea erorilor, urmărirea erorilor de testare va servi la o înregistrare a dificultății și complexității verificării și la dobandirea competenței Analistului de a deduce erorile [1].

O înregistrare a erorilor de testare din scop va ajuta de asemenea, la adunarea mediului într-o formă simplă. Este o reducere simplă a Sumarului Executiv care de obicei descrie părerea Analistului despre starea securității, unde vor apărea puține erori sau nici una, o țintă și un mesaj destul de static. Multe erori arată un mediu haotic și unul care se poate lipsi de control pentru a administra schimbarea sau pierderea.

Luate în mare, înregistrările erorilor de testare sunt folositoare pentru înțelegerea complexității verificării și a controlului de schimbare dintre verificări și intervale regulate.

Rezultatele testului

Rezultatele testului sunt de obicei însoțite de soluții recomandate sau de oferte de consultare, dintre care nici una nu este solicitată pentru verificarea SecOp. Soluțiile recomandate pot fi asigurate ca o adăugare a valorii testului de securitate, dar nu sunt considerate obligatorii. De obicei nu există soluții adecvate bazate pe perspectiva limitată pe care o are un Analist despre mediul clientului. Prin urmare, soluțiile nu sunt solicitate ca o parte din verificarea SecOp.

În mod frecvent un test va depăși limitele controlului securității. Într-un angajament, Analistul trebuie să raporteze mereu starea actuală a securității factuale, orice limitări din starea actuală și oricare dintre procesele care au cauzat acele limitări a controlului și a protecției aplicate.

Pentru a măsura atât complexitatea testului cât și securitatea țintei, utilizarea acestei metodologii ar trebui să se încheie cu Raportul Verificării Testării Securității (RVTS). RVTS solicita următoarele informații:

Data și timpul testului;

Durata testului;

Numele Analiștilor responsabili;

Tipul testului;

Scopul testului;

Indexul (metoda de enumerare a țintei);

Canalul testat;

Vectorul de testare;

Suprafața metrică de atac;

Ce teste au fost completate, necompletate sau completate parțial și până unde au fost completate;

Orice probleme cu privire la test și la validitatea rezultatelor;

Orice procese care influențează securitatea limitărilor;

Orice necunoscute sau anomalii.

Utilizarea cu succes a SecOp arată o măsurare actuală a securității și a controlului. Reprezentarea greșită a rezultatelor poate duce la verificarea frauduloasă a controlului securității și la un nivel de securitate inexact. De aceea, Analistul trebuie să accepte responsabilitatea și răspunderea limitată a raportării inexacte.

3.9 Divulgarea

În timpul testului de securitate apariția limitării securității necunoscute anterior și a securității nepromovate, poate ieși la lumină. Ceea ce Analistul face cu acestea este, în primul rând, un rezultat al reglementării legale a regiunii Analistului și a zonei în care are loc munca.

Drepturile de divulgare

Ceea ce trebuie să faci este să te asiguri că accesul tău la produs sau soluție și utilizarea acestuia nu necesită nici un fel de provizii, un contract de Non-Divulgare sau de Terminare a Acordului de Utilizare a Licenței (TĂUL) care îți neagă dreptul de a solicita, anunța sau distribui orice vulnerabilitate descoperită. Dacă ar face acest lucru, iar tu sau clientul ați acceptat acest contract, atunci nu puteți divulga informația nimănui, poate numai producătorului, fără potențiale repercusiuni legale. În plus, dacă lucrezi la compania care face acel produs sau ești un client legal al ei, nu vei putea divulga nimic din punct de vedere legal. Mai mult, în orice caz drepturile tale pot fi mai degrabă provocate potrivit procesului de lege din regiunea ta, decât să existe un precedent legal [1].

Responsabilități

Totuși, dacă acele cazuri nu ți se aplică, atunci deții în mod eficient acea vulnerabilitate și cu cât o faci mai repede publică, cu atât mai multe drepturi vei avea în calitate de detonator. În multe țări, procesele și informațiile pot fi protejate de lege și de multe ori procesul legal solicită publicație sau legalitate, completându-se cu o asemenea atribuire. Dacă divulgarea ta nu provoacă un rău FIZIC (ca și amenințarea cu foc într-un cinematograf aglomerat), poți să o faci și nici un post legal nu poate să îți facă ceva când este dreptul tău. Totuși, pentru a fi și mai în siguranță, ar trebui de asemenea să promovezi, cu vulnerabilitatea divulgată, controlul care poate fi aplicat pentru a fixa problema. De exemplu, dacă este o problemă în legătură cu modul în care te autentifici cu o soluție, poți sugera apoi un sistem alternativ de autentificare și modul în care se poate integra cu succes. Nu este nevoie să aștepți ca producătorul să vină cu soluția sau să te gândești că oamenii vor rezolva problema. Totuși, dacă alegi să lucrezi în cadrul contextului de notificare a producătorului, va trebui să le dai mult timp la dispoziție pentru a adresa problema înainte de a o face publică. Există un argument valid cum că vulnerabilitatea ar putea fi deja cunoscută în cercurile criminale și are nevoie de o atenție urgentă. Prin urmare, ar trebui să alegi publicarea fără asistența producătorului. Nu uita că includerea unei soluții va arăta, din punct de vedere legal, că ai intenții bune, iar mare parte din sistemul legal se concentrează pe un scop implicit.

Alegerea ta depinde de acceptarea sau nu a proceselor frivole în regiunea ta. Ține minte, nu ești tu Analistul solicitat pentru testarea asigurării calității de către producător, deci nu le datorezi nici o informație în legătură cu munca pe care ai depus-o, chiar dacă le include produsul.

Divulgarea completă este benefică atâta timp cât nu rănește pe nimeni. În plus, consumatorii nu ar trebui să aștepte ca producătorul să își repare produsul pentru a se afla în siguranță. Dacă produsul nu este vândut ca o soluție specifică a securității, atunci consumatorii sunt cei care ar trebui să îl facă sigur sau ar trebui să renunțe la folosirea lui. Dacă este vândut ca fiind sigur, producătorul trebuie să îl rezolve în orice fel, deoarece consumatorul s-ar putea să nu vrea să aștepte până când producătorul o va face. Divulgarea completă permite această opțiune [1].

4. Rootkit

În continuare este prezentat termenul de rootkit și ceea ce reprezintă el, precum și modul în care operează într-un sistem de operare Windows. De asemenea este prezentat și modul în care să ne protejăm împotriva acestora cu ajutorul unor aplicații software free [10].

Un rootkit este un tip de soft „ascuns”, de multe ori rău inteționat, care este proiectat pentru a ascunde existența unor procese sau programe, de metodele uzuale de detectare și pentru a permite accesul continuu privilegiat, la un calculator. Termenul rootkit este format din două cuvinte, prin concatenare și anume: root (rădăcină), care vine de la contul de administrator de pe sistemul de operare Unix și kit, care se referă la componentele software ce implementează instrumentul. Rootkit-ul poate fi instalat automat sau de un atacator care a obținut un cont de root sau administrator, de la calculatorul atacat. Obținerea unui root sau administrator este rezultatul unui atac direct asupra sistemului, de exemplu, prin exploatarea unei vulnerabilitati cunoscute, parole, escaladarea privilegiilor sau de inginerie socială etc. Odată instalat rootkit-ul devine ascuns. În concluzie, controlul complet asupra unui sistem de operare de pe un calculator poate fi modificat, inclusiv și soft-urile care detectează sau elimină aceste rootkit-uri. Detectarea unui rootkit este dificilă deoarece el este capabil să submineze software-ul care are ca țintă găsirea lui. Metodele de detecție includ folosirea unui sistem de operare alternativ, scanarea diferențiată etc. Ștergerea poate fi complicată sau chiar imposibilă, mai ales în cazul în care rootkit-ul se află în kernel-ul sistemului de operare, singura rezolvare fiind reinstalarea acestuia.

Primul rootkit a apărut în anul 1999 și era pentru sistemul de operare Windows NT. Era un troian numit NTRootkit. Acesta a fost urmat de HackerDefender în 2003. Pentru Mac OS X primul rootkit a apărut în anul 2009, în timp ce rootkit-ul de tip worms pe nume Stuxnet, a fost primul care viza controlerele logice paralele (PLC).

Termenul de rootkit este cunoscut de mai bine de 10 ani. Un rootkit este un „kit” format din mici programe, care permit unui atacator să mențină accesul la root-ul unui calculator (sau administrator). Cu alte cuvinte un rootkit este un set de programe și coduri care permit o permanentă sau consecventă prezență, nedectabilă într-un calculator.

În definiția noastra a rootkit-ului, cuvântul cheie este nedetectabil. Cele mai multe dintre tehnologiile și trucurile folosite de un rootkit sunt concepute pentru a ascunde cod și date pe un sistem. De exemplu, un rootkit poate ascunde fișiere și directoare. Alte caracteristici ale rootkit-ului sunt: accesul la distanță, „tragerea cu urechea” și sniffing-ul pachetelor din rețea. Atunci cand aceste caracteristici sunt combinate, ele fac knock-out securitatea sistemului atacat [9].

Rootkit-urile nu sunt niște soft-uri „rele”, nefiind folosite tot timpul de „baieții răi”. Este important să înțelegem că un rootkit este doar o tehnologie. Intenția bună sau rea derivă de la oamenii ce o folosesc. Există o multitudine de programe legitime comerciale care oferă administrarea de la distanță și chiar caracteristici de ascultare. Unele dintre acestea chiar folosesc forma de stealth (ascuns), iar unele dintre ele ar putea fi numite chiar rootkit-uri. Marile corporații folosesc, de asemenea, tehnologia rootkit pentru a monitoriza și a pune in aplicare pe calculatoarele lor, regulamentele interne.

Rootkit-urile sunt o invenție relativ recentă, dar spionii sunt la fel de vechi ca și războiul. Oamenii vor să vadă sau să controleze ceea ce fac alți oameni. Cu o dependență uriașă și în creștere, privind utilizarea calculatorului de către agentul uman, calculatoarele devin ținte naturale.

Rootkit-urile sunt utile doar dacă doriți să mențineți accesul la un sistem. Dar dacă tot il folosiți și vreți să furați ceva, nu este indicat sa-l lăsați pe acel sistem deoarece există riscul de a fi detectat. Pentru a șterge urmele „curățați” și sistemul pe care l-ați furat.

Rootkit-urile oferă două funcții principale: comanda și controlul de la distanță precum și software-ul de spionaj.

Comanda și controlul de la distanță (sau pur și simplu „telecomanda”) pot include controlul asupra fișierelor, provocand repornirea sistemului sau apariția erorii Blue Screen și accesarea comenzilor shell (care sunt cmd.exe sau /bin/sh).

Mai jos este prezentat meniul de comenzi al unui rootkit:

Win2K Rootkit by the team rootkit.com

Version 0.4 alpha

––––––––––––––

command descriere

ps afiseaza lista de procese

help acestea sunt date

buffertest iesirea debug

hidedir ascunde prefixul fisierelor sau al directoarelor

hideproc ascunde prefixul proceselor

debugint (BSOD)fire int3

sniffkeys initializeaza sniffer

echo <string> echo the given string

*"(BSOD)" inseamna Blue Screen of Death

if a kernel debugger is not present!

*"prefixed" inseamna proces sau numele unui fisier

starts with the letters '_root_'.

*"sniffer" inseamna soft de monitorizare si ascultare.

Software-ul de spionaj, programele pentru „tragerea cu urechea” sau vizionarea a ceea ce fac utilizatorii sistemului sunt soft-uri care fac sniffing de pachete, interceptarea intrărilor de la tastatură (keylogger) și citirea email-urilor. Un atacator poate folosi aceste tehnici pentru a captura parole și fișiere decriptate sau chiar chei criptate.

Așa cum am făcut aluzie deja, rootkit-urile pot fi folosite și în scopuri legitime. De exemplu, pot fi folosite de către poliție pentru a colecta probe în orice operațiune în care se folosește calculatorul, cum ar fi: fraude bancare, pirateria, pornografia infantilă etc.

4.1 Scandaluri celebre în care au fost folosite rootkit-urile

Sony BMG- scandalul copiilor de protecție cu rootkit:

În 2005, Sony BMG a lansat CD-uri cu protecție la copiere și un produs software de gestionare a drepturilor digitale, numit protecție la copierea extinsă, creat de First 4 Internet. Sotfware-ul includea un player audio, dar instala în tăcere și un rootkit prin care limita drepturile utilizatorului de a accesa CD-ul .

Inginerul software Mark Russinovich, care a creat instrumentul de detecție a rootkit-urilor RootkitRevealer, a descoperit rootkit-ul pe unul dintre calculatoarele sale. Scandalul ce a urmat a ridicat interesul publicului asupra rootkit-urilor. La scurt timp după raportul lui Russinovich, au apărut atacuri malware care au profitat de vulnerabilitatea sistemelor afectate. Un analist BBC a numit acest eveniment ca fiind un coșmar pentru cumpărătorii acestor CD-uri. Ca urmare Sony BMG a lansat patch-uri pentru dezinstalarea rootkit-ului, dar a expus utilizatorii la vulnerabilități mai grave. În SUA a fost intentat un proces împotriva Sony BMG din această cauză [7].

Cazul grecesc de interceptare a telefoanelor:

Cazul Greciei de interceptare a telefoanelor din 2004-2005 implică interceptarea ilegală a mai mult de 100 de telefoane mobile din rețeaua Vodafone Grecia, care aparțineau în mare parte membrilor guvernului elen și a unor funcționari de rang înalt. Interceptările au avut loc la începutul lunii august din anul 2004 și au fost eliminate în martie 2005, fără a se descoperi identitatea făptuitorilor.

Pentru a efectua aceste interceptări intrușii au instalat un rootkit care a vizat Ericson AXE. Conform IEEE Spectrum, aceasta a fost „prima dată când un rootkit este observat pe un sistem cu destinație specializată, o centrală telefonică Ericson”. Rootkit-ul a fost conceput pentru a schimba zona de memorie, în timp ce aceasta era utilizată, activând astfel interceptarea, în timp ce dezactiva logările audio. Acesta mai folosea un backdoor ce avea statut de adiministrator sau root, care putea dezactiva jurnalul de schimb al tranzacțiilor și al alarmelor, precum și comenzile de la accesul de supraveghere. Rootkit-ul a fost descoperit după ce intrușii au încercat să instaleze o actualizare, dar aceasta a început să trimită sms-uri necontrolat. În urma acestui fapt defectuos, au fost chemați inginerii de la Ericson pentru a investiga eroarea, iar în urma investigării acesteia, au descoperit blocuri de date conținând lista numerelor de telefon care erau ascultate, precum și rootkit-ul împreună cu software-ul de monitorizare care au fost instalate [8].

4.2 Rootkit: Darkfire

În continuare voi prezenta două astfel de rootkit-uri, și modul în care operează. Primul este DarkFire, un rootkit scris în limbajul de programare C# (C sharp), prezentat în patru exemple. Rootkit-ul este de fapt un dll (dynamic link library), care se adaugă într-un proiect realizat în Visual Studio unde este apelat [6].

Toate exemplele prezentate mai jos se află într-un program de prezentare realizat în Visual Studio:

Figura 4.1 – Se deschide directorul DarkFire – Exemple.

Figura 4.2- Urmămăm calea de mai sus pentru a ajunge în directorul Debug, apoi dublu click pe DarFire- Exemple.exe.

Figura 4.3- Aplicația DarkFire rulează, iar prin apăsarea celor 4 butoane, se va afișa o nouă formă cu descrierea exemplului și un buton de rulare a acestuia.

Exemplul 1: Primul exemplu ascunde un proces din Task Manager după PID-ul acestuia (id-ul procesului) făcându-l practic nedetectabil pentru sistemul de operare și antivirus:

Figura 4.4- Modul în care se adaugă DLL-ul DarkFire în proiectul C# din Visual Studio 2010.

Figura 4.5- Este rulat primul rootkit și se observă că este introdus PID-ul procesului BitTorrent.exe.

Figura 4.6- Este afișat Task Manager-ul din Windows, în care este marcat procesul BitTorrent.exe cu PID-ul 584, si numărul de procese care este 35.

Figura 4.7- Rootkit-ul este executat, iar din Task Manager dispare procesul BitTorrent.exe, însă apare un nou proces Exemplul 1.exe.

Figura 4.8 – După închiderea rootkit-ului, el rămane pornit in Task Manager pentru o perioada nedeterminată de timp, iar dacă se încearcă oprirea lui prin apăsarea butonului End Process, sistemul de operare va genera o eroare ca cea ilustrată mai sus.

Concluzie: acest exemplu de rootkit, poate ascunde un proces din Windows după PID-ul său, fără ca sistemul de operare să-l poată detecta. Un astfel de rootkit poate fi folosit de persoane rău voitoare, la ascunderea unor viruși în sistemul de operare, prin intermediul cărora se pot obține ce informați doresc de pe calculatorul țintă. O atribuire pozitivă a acestui tip de rootkit poate fi folosirea sa de către anumite organe abilitate la combaterea anumitor infracțiuni informatice [6].

Exemplul 2: Următorul rootkit afișează de pe calculatorul țintă, dacă acesta folosește la momentul atacului WireShark sau o versiune a Sandboxie.

Wireshark este aplicație open-source care monitorizează pachete de date. Este utilizată pentru soluționarea problemelor în rețea, pentru analiza traficului, dezvoltarea produselor software și a protocoalelor de comunicare, în scopuri educaționale. Inițial, aplicația se numea Ethereal, dar în mai 2006 proiectul a fost redenumit Wireshark din cauza problemelor legate de marca comercială [4].

Sandboxie este un program sandbox pentru Windows. Un sandbox este un loc protejat de interferențe exterioare, unde programele pot funcționa, însă fișierele sistemului nu pot fi afectate. Sandboxie monitorizează programele care sunt deschise în sandbox și deviază accesul la fișiere, către un sistem virtual. Toate modificările făcute se realizează doar în sandbox. Fișierele reale de pe hard disk rămân nemodificate [5].

Figura 4.9- Rularea programului Sandboxie și adăugarea a Windows Explorer în el, pentru a fi executat.

Figura 4.10- Windows Explorer rulează în Sandboxie.

Figura 4.11- Se observă că toate aplicațiile rulează, iar rootkit-ul afișează cele două programe în execuție.

Concluzie: rootkit-ul prezentat poate fi folosit pentru a afișa dacă pe calculatorul țintă sunt rulate următoarele programe: Sandboxie, Norman Sandboxie, Sunbelt Sandboxie, Anubis Sandboxie, CW Sandboxie, Wireshark. Prezența acestora (valoarea trebuie sa fie True) poate pune în pericol utilizarea rootkitului, deoarece acesta poate fi detectat.

Exemplul 3: Acest rootkit dezactivează procesele după nume. Prin simpla introducere a numelui unui proces, ca de exemplu explorer, acesta va fi dezactivat, iar activarea lui se poate realiza doar după ce aplicația ce conține rootkit-ul este închisă [6].

Figura 4.12- Oprirea procesului explorer prin intermediul unui rootkit (fereastra din stânga). Procesul explorer nu mai este afișat în Task Manager (fereastra din dreapta).

Figura 4.13 – Procesul oprit cu acest rootkit, mai poate fi pornit numai după ce acesta nu mai este rulat de către sistemul de operare.

Concluzie: folosirea îndelungată asupra unui calculator țintă duce la deteriorarea sistemului de operare. Rootkit-ul poate fi folosit pentru a defecta sistemul de operare de pe calculatorul care este atacat. Dacă este folosit cu intenții rele, el poate dezactiva antivirusul de pe sistemul de operare, făcând mai ușoară folosirea altor rootkit-uri pe sistemul de operare.

Exemplul 4: Acest rootkit dezactivează conexiunea la Internet, introducând o adresă IP, un host, sau un port. Conexiunea se dezactivează local, dacă se introduce o adresă host, de exemplu www.google.ro. Aceasta nu va mai fi funcțională la accesarea ei. În schimb, dacă se introduce adresa IP a calculatorului țintă, acestuia i se va intrerupe conexiunea la internet, neputând accesa nici o pagină web. Efectul acestui rootkit este valabil doar atâta timp cat el este rulat [6].

Figura 4.14- Din Local Area Connection Status, luam adresa IP a calculatorului pe care se află rootkit-ul (acesta se poate afla și din cmd prin comanda ipconfig).

Figura 4.15- Se observă că după introducerea IP-ului, Windows-ul afișează cum conexiunea la internet este efectuată.

Figura 4.16- La accesarea unei pagini web, browser-ul va afișa că pagina nu este disponibilă.

Figura 4.17- După închiderea rootkit-ului, conexiunea la internet este reluată, ca și cum nimic nu s-ar fi întâmplat.

Concluzie: rootkit-ul prezentat poate fi folosit la întreruperea conexiunii la Internet de pe un calculator țintă sau chiar de pe un server, lucru are ar afecta compania care deține acel server. Poate fi folosit si de administratori de rețele, pentru a întrerupe conexiunea la Internet a unor utilizatori care devin dubioși pe rețea, prin diferitele lor activități (distribuirea ilegală de anumite fișiere piratate, pornografie infantilă etc.).

4.3 Rootkit: .Net Sploit 1.0

.Net Sploit își propune a fi un instrument general de manipulare pentru ansamblurile .Net Framework. Acest instrument permite schimbarea clasei de execuție și injectarea de cod în fișierele de tip DLL (dynamic link library) ale .Net Framework-ului dezvoltat de cei de la Microsoft. Acesta este ușor de utilizat pentru a realiza noi injecții de cod, folosind anumite funcții externe. Aceste module pot fi utilizate prin crearea unui nou fișier și folosirea funcțiilor din modulele deja instalate [3].

Abilitățile acestui rootkit sunt următoarele:

DLL-ul țintă este extras din GAC (Global Assembly Cache);

Efectuează modificarea codului;

Decompilează și recompilează roundtrip (dus-întors);

Oferă cod de injectare;

Renumerotează liniile de cod MSIL (Microsoft Intermediate Language);

Recalculează dimensiunea stivei.

Utilizarea principală a .Net Sploit este aceea de-a crea și modifica DLL-uri prin folosirea descrierii, a modificării unui fișier XML, numit element. Un element conține toate informațiile necesare pentru a efectua crearea unui DLL modificat [2].

Scenariul principal după care poate fi descrisă folosirea acestui rootkit este următorul:

Încărcați un fișier utilizând .Net Sploit;

Faceți click pe Start (generează modificarea fișierului DLL și a deployer.bat) utilizând .Net Sploit;

Rulați deployer.bat pe calculatorul țintă.

Rootkit-ul utilizează un fișier deployer.bat pentru a face mai ușoară implementarea pe calculatorul țintă. [2]

Pașii care trebuie urmați pentru a folosi .Net Sploit sunt descriși în cele ce urmează:

Pasul 1: Încărcarea unui fișier (File -> Load Item)

Încărcați un element;

Obervație: unele setări ale sistemului de operare trebuie să fie configurate corect înainte de utilizare (adresa IP, portul ReverseShell etc.). Acum rootkit-ul va analiza și va strânge informații cu privire la modificarea DLL-ului.

Pasul 2: Pornește modificarea (File-> Start! )

Copiați DLL-ul („AssemblyName”) din locația GAC („AssemblyLocation”) în directorul de lucru Workspace;

Decompilează DLL-ul în directorul Decompiler;

Injectează referințe;

Injectează metode;

Injectează sarcini utile;

Recompilează DLL-ul modificat în directorul Output;

Generează lotul de instalatori (deployers) și setează NGEN-ul (Native Image Generator).

Deploy.bat poate fi folosit pentru a implementa un nou DLL în GAC, iar Undeploy.bat poate fi folosit pentru a restabili în forma lui originală un DLL din GAC.

Se poate observa stadiul actual din fereastra Progress:

După ce DLL-ul este generat cu succes, veți primi următorul mesaj:

Acum avem un DLL modificat care se află în directorul Workdir\Output.

Pentru a genera deployer.bat apăsați butonul Yes.

Pasul 3: Rulează deployer.bat pe calculatorul țintă

Deploy.bat si Undeploy.bat sunt separate în mod intenționat de .Net Sploit, ele fiind concepute pentru a fi folosite pe calculatorul care se vrea a fi atacat;

Daca se dorește să se utilizeze DLL-ul pe un calculator țintă, este nevoie doar de fișierele DLL și Deploy.bat (asigurați-vă că directoarele sunt stabilite în mod corespunzător) [3];

Testarea are nevoie de o cerere de tester, care va apela metoda modificată. De exemplu, pentru a testa „Print WriteLine twice.item” avem nevoie de o cerere de test cum ar fi:

class HelloWorld

{

static void Main(string[] args)

{

Console.WriteLine("Hello (crazy) World!");

}

}

După rularea fișierului deployer.bat și implementarea corectă ar trebui ca șirul afișat să apară de două ori:

Pentru a configura .Net Sploit, avem fișierul Config.xml în care putem modifica calea, numele fișierelor și opțiunile de compilare. Asigurați-vă că este setată corect calea către ildasm, ilasm și NGEN înainte de al utiliza [2].

Utilizarea acestui rootkit necesită un sistem cu 512 memorie RAM și un spațiu de stocare de 100 MB. Un program care face rularea posibilă pe sistemul de operare Windows ce trebuie instalat este ildasm.exe / .NET Framework 2.0 SDK.

Modulele rootkit-ului .Net Sploit sunt următoarele:

Funcțiile – o nouă metodă de a prelungi un DLL specificat;

Sarcinile – cod care este injectat în metoda specificată;

Referințe – referire la alte DLL-uri (dacă este necesar);

Elemente – compoziția de bază într-un fișier XML care să cuprindă toate modulele descrise mai sus.

Un element este bazat pe module și poate conține mai multe funcții și sarcini utile, permițând utilizatorului sa modifice un DLL prin injectare, folosind o singură trecere cu un singur element.

Modulul funcție: modulul funcție este utilizat pentru extinderea și adăugarea de noi funcții într-o clasă. Acesta este un fișier ce conține codul MSIL și numerele de linii.

Crearea de noi funcții: se salvează în directorul Modules\Functions. O modalitate simplă de a crea funcții este să se scrie cod in C# și apoi să fie separat în MSIL.

Modulul de sarcină utilă: modulul de sarcină utilă este folosit pentru a introduce noi linii de cod în program. Codul sarcină utilă poate apela, de asemenea, funcții care realizează injectarea. Fiecare fișier cu sarcină utilă trebuie să se termine cu un cod.

Crearea de noi sarcini utile: se salvează în directorul Modules\Playload.

Modulul de elemente: modulul de elemente conține informații cu privire la sarcina utilă și funțiile pentru injectarea anumitor DLL-uri. Un element poate conține mai multe sarcini utile și funcții [2].

Mai jos sunt descrise principalele secțiuni dintr-un element XML:

Description – descrierea pentru acest element;

AssemblyName – numele DLL-ului țintă;

AssemblyLocation – calea către DLL-ul țintă;

AssemblyRef – un fișier care conține o referință către DLL-ul ce urmează a fi atacat;

AssemblyFunc – o nouă funcține (metodă) ce urmează a fi injectată;

AssemblyCode – sarcinile utile care urmează să fie injectate.

Crearea de noi elemente: se salvează în directorul Modules\Items.

Pentru a crea un nou element se procedează astfel:

Implementarea necesită adăugarea codului în metoda WriteLine ca sarcină utilă. Prin urmare avem nevoie de un fișier care să fie sarcina utilă (WriteLine_Twice.playload), care conține:

IL_0000: clasa de apel System.Console System.IO.TextWriter :: get_Out ()

     IL_0005: ldarg.0

     IL_0006: apelarea de exemplu a System.IO.TextWriter nule :: WriteLine (string)

     IL_000b: ret

Această sarcină utilă trebuie să fie injectată în WriteLine, de aceea nu trebuie să uităm declararea metodei: method public hidebysig static void WriteLine(string 'value') cil managed

Următorul fișier care conține elementul (WriteLine_Twice.item), cuprinde informațiile necesare pentru a efectua acestă injectare:

<CodeChangeItem name="Write every string twice">

     <Description>The specified code will change WriteLine(string s) in such a way that each time it is called the   

                           string s will be printed twice

     </Description>

     <AssemblyName>mscorlib.dll</AssemblyName> 

     <AssemblyLocation>c:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089

     </AssemblyLocation>

     <NativeImageLocation>c:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib

     </NativeImageLocation>

     <AssemblyCode>

        <FileName>writeline_twice.payload</FileName>

        <Location><![CDATA[.method public hidebysig static void  WriteLine(string 'value') cil   

                          managed]]>

        </Location>

        <StackSize>8</StackSize>

     </AssemblyCode>

</CodeChangeItem>

Acesta conține:

Descrierea;

Numele ansamblului țintă (mscorlib.dll);

Locația nativă a imaginii GAC;

Detaliile sarcinii utile (AssemblyCode);

Numele fișierului cu sarcină utilă (WriteLine_Twice.payload);

Metoda de semnatură pentru a căuta și injecta cod în interior;

Dimensiunea stivei- 8 (aceeași ca în metoda originală).

Exemplul practic de utilizare a rootkit-ului .Net Sploit 1.0:

Figura 4.19 – Accesăm directorul .NetSploit, apoi urmăm calea până în directorul Debug de unde rulăm aplicația .NET-Sploit.exe .

Figura 4.20 – După ce am rulat aplicația ne deplasăm cu săgeata mouse-lui pe meniul File, după care selectăm Load Item.

Figura 4.21- Din directorul Items, selectăm ce item (componentă) dorim, apoi apăsăm buton Open.

Figura 4.22 – Încărcarea componentei din directorul Items s-a realizat cu succes, după care accesăm din nou meniul File, și apăsăm butonul Start!.

Figura 4.23 – După rularea programului, ne sunt afișate doua casete de tip Message Box. În una dintre ele ni se arată că DLL-ul a fost modificat, iar în cealaltă ne intreabă dacă dorim să ni se genereze fișierul deployer.bat .

Figura 4.24 – În urma rulării aplicației, se va merge în directorul Debug, iar apoi se va porni deploy.bat.

Figura 4.25 – Se va accesa bara de Start a sistemului de operare Windows, după care va fi lansat în execuție SDK Command Prompt.

Figura 4.26 – În cele din urmă se va da calea directorului TestApplications, director ce este inclus in .Net Sploit, după care se rulează programele Hello.exe și HelloWorld.exe. Se observă că DLL-ul modificat nu afișează mesajul Hello World, în locul acestuia apărând un spațiu gol.

5. Concluzii

Din studiu efectuat în această lucrare putem trage următoarele concluzii referitoare la rootkit-uri și probleme de securitate pe care le poate genera aceste programe malware:

Viteza de propagare cu care se efectuează infecțiile cu rootkit-uri a crescut mult. Timpul necesar ca un astfel de instrument să poată fi detectat este practic nedeterminat, deoarece el este greu de detectat.

Rootkit-urile sunt utilizate mai ales pentru a obține date de pe calculatoarele atacate.

Utilizarea lor nu este neapărat o amințare dacă sunt folosite de cine trebuie.

Detecția rootkit-urilor se face greu deoarece ele pot fi detectate la nivelul regiștrilor din sistemul de operare, iar un utilizator fără prea multă experiență nu știe cum să facă asta.

Curățarea unui rootkit de pe un sistem de operare Windows infectat, este aproape imposibilă. Pentru a scăpa de el este de preferat reinstalarea sistemului de operare.

Securitatea operațională ajută utilizatorul să se ferească de astfel de amenințări.

Prin utilizarea unui test de securitate complet se pot ocoli problemele de securitate, cum ar fi, în cazul nostru, infectarea cu rootkit-uri.

Rootkit-urile nu sunt neapărat niște soft-uri rău intenționate, deoarece folosirea lor de către anumite organe abilitate ale statului, poate duce la scăderea infracționalității informatice.

6. Bibliografie

[1] OSSTMM 3 – The Open Source Security Testing Methodology Manual http://www.isecom.org/mirror/OSSTMM.3.pdf

[2] .Net Sploit 1.0, https://appsec-labs.com/NET-Framework-Rootkits

[3] .NET-Sploit 1.0 user guide

[4] Wireshark, http://ro.wikipedia.org/wiki/Wireshark

[5] Securitatea PC: sandbox, http://ro.pokerstrategy.com/strategy/others/1520/1/

[6] DarkFire Rootkit, http://www.secret-zone.net/f124/darkfire-rootkit-1-0-a-2650/

[7] Sony BMG- scandalul copiilor de protecție cu rootkit, http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal

http://blogs.technet.com/b/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx

http://news.bbc.co.uk/2/hi/technology/4456970.stm

[8] Cazul grecesc de interceptare a telefoanelor , http://en.wikipedia.org/wiki/Rootkit#Greek_wiretapping_case_2004.E2.80.9305

[9] Windows Rootkit Overview

[10] Rootkit, http://en.wikipedia.org/wiki/Rootkit

. Bibliografie

[1] OSSTMM 3 – The Open Source Security Testing Methodology Manual http://www.isecom.org/mirror/OSSTMM.3.pdf

[2] .Net Sploit 1.0, https://appsec-labs.com/NET-Framework-Rootkits

[3] .NET-Sploit 1.0 user guide

[4] Wireshark, http://ro.wikipedia.org/wiki/Wireshark

[5] Securitatea PC: sandbox, http://ro.pokerstrategy.com/strategy/others/1520/1/

[6] DarkFire Rootkit, http://www.secret-zone.net/f124/darkfire-rootkit-1-0-a-2650/

[7] Sony BMG- scandalul copiilor de protecție cu rootkit, http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal

http://blogs.technet.com/b/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx

http://news.bbc.co.uk/2/hi/technology/4456970.stm

[8] Cazul grecesc de interceptare a telefoanelor , http://en.wikipedia.org/wiki/Rootkit#Greek_wiretapping_case_2004.E2.80.9305

[9] Windows Rootkit Overview

[10] Rootkit, http://en.wikipedia.org/wiki/Rootkit