Alice si Bob

Experienţă structurală

În ultimele două săptămâni am avut ocazia de a trăi două experienţe structural. De fiecare dată un dezvoltator, integrator, furnizor de soluţii sau numeşte-l cm doreşti, a afirmat ceva de genul: “Deci, acum, în această situaţie vom dezvolta o structură, care, ulterior, va putea fi pur şi simplu convertit într-o altă strucutră, într-adevăr nu e mare lucru”, sau “într-adevăr, în sistem poate fi dezvoltată o structură oarecare.”
În astfel de cazuri povestesc de fiecare dată că într-un anume moment al vieţii mele mi-am câştigat şi eu existenţa ca dezvoltator, şi ştiu exact care este diferenţa între SE POATE FACE şi ESTE FĂCUT. Mai mult de atât, de fapt, putem privi programarea ca şi crearea de structuri, este dată unealta de dezvoltare, limbajul de programare, iar programatorul nu face altceva decât foloseşte toate acestea pentru a crea structuri (sistem).
Deci, în ceea ce mă priveşte, folosirea cuvântului structură în ceea ce priveşte o anumită activitate de programare, poate însemna două lucruri. Sau programatorul nu înţelege deloc necesităţile de business, deoarece businessul nu se gândeşte la necesităţile proprii ca la nişte structuri. Să ne gândim puţin: shoppin cart = structura antetului + a componentelor?! Asta niciodată nu înseamnă ceva bun. Sau programatorul nu are nici o idée despre ce are de făcut, şi în acest caz formulează un adevăr universal: va construe structuri.
Eu am aceeaşi reacţie în ambele cazuri. Îi atrag atenţia, să vorbească deschis, să lase textele. În aceste cazuri, de fiecare dată îmi amintesc că la locul de muncă anterior, cu mai mult de 15 ani în urmă (câţi ani au trecut de atunci...) analizam medii de dezvoltare 4GL, deoarece atunci acestea erau la modă, era un mediu de dezvoltare uşor de utilizat şi eficient. Am analizat produsele a mai multor companii, şi fiecare prezentare din acele vremuri transmitea mesajul că sistemul este universal, că poate fi folosit la rezolvarea multor probleme, dar nimeni nu afirma niciodată câtă muncă era necesară pentru efectuarea acestora.
Este interesant, că de multe ori nici programatorii nu înţeleg (sau nu consideră important) diferenţa. Deşi, ei chiar ar trebui să ştie câtă muncă este necesară pentru efectuarea unei activităţi aparent simple (să nu uităm, că şi marea presupunere a lui Fermat este uşor de înţeles, şi totuşi omenirea a petrecut mult timp cu demonstraţia acesteia, să nu mai menţionăm, că chiar şi acum, foarte puţini oameni o înţeleg).
Eu propun, ca după descrierea fiecărui feature, prezentarea unui produs, afirmarea unei promisiuni să puneţi şi întrebarea “câtă muncă efectivă este necesară?”. Pe mine m-a ajutat de cele mai multe ori să ajung mai aproape de esenţa lucrurilor.
Experienţa structurală pentru mine este asemănătoare cu o întoarcere în timp în anii 90. Ar trebui să însemne déjà altceva.
Aţi avut déjà experienţe structurale?

Lumea dinaintea internetului

Îmi aduc aminte, că am decis să învăţ să programez în C la vârsta de 16 ani, deoarece la o întrunire familială m-am întâlnit cu un student, care făcuse programare înainte şi mi-a povestit ce tare e să faci asta (nu a avut dreptate). Deoarece nu trăiam într-un mediu de programatori, am făcut singurul lucru care părea logic la momentul respectiv, m-am dus la biblioteca judeţeană şi am căutat carte despre programarea în C.
Toate cărţile lor referitoare la IT erau puse pe o poliţă construită în jurul unui stâlp de susţinere. Erau vreo 20. Şi spre surprinderea şi bucuria mea, erau acolo clasicii lui Kerninghan şi Richie. Bucuria mea a ţinut pănâ când am citit câteva rânduri din cărţi, deoarece mi-am dat seama că este prea mult pentru mine (şi nu aveam nici translator pentru aşa ceva), cauză din care am rămas la programarea C+4 basic şi assembly.
Dar, mi-am amintit de toate acestea, deoarece una din aminitirile semnificative ale copilăriei mele a fost aceea că se putea ajunge la informaţii foarte greu. Bilbioteci, cunoştinţe, prieteni, rude, şcoală – au fost singurele surse. Tocmai de aceea, astăzi, când am în mână telefonul mobil, şi cu un singur click pot accesa orice conţinut, mă fascinează cât de mult s-a schimbat lumea. Tot ceea ce fiind copil, cu câţiva ani în urmă, era neimaginabil de departe, astăzi, mot-a-mot este în buzunarul nostru.
E fascinant.
Lumea s-a schimbat enorm, dar observ, că noi oamenii ne-am schimbat într-o măsură mult mai mică. Sau, poate această afirmaţie nici nu este adevărată, deoarece copii care au crescut, cresc cu Internetul, vor fi diferiţi. Dar noi, cei care am crescut înaintea Internetului, nu ne-am dat seama că noua lume necesită o abordare diferită a informaţiei.
Dacă în trecut întrebarea era de fapt dacă poţi ajunge la o anumită informaţie, asta astăzi a devenit o certitudine. Orice cantitate de informaţie în orice domeniu este la dispoziţia noastră. În trecut întrebarea era ce anume poţi citi, astăzi întrebarea este dacă vrei sau nu să citeşti. În trecut puteai să ai o singură sursă de informaţie, astăzi google îţi oferă milioane de surse.
Omul dinaintea internetului adună pe DVD cărţile descărcate de pe torenţi, copiază tone de filme, mp3-uri. Aşa face, ca bunicii noştri, gândind că nu se aruncă nimic, putând fi folosit cândva în viitor la ceva. Aşa cm noi la rândul nostru zâmbeam când auzeam astfel de explicaţii, deoarece în lumea produselor de retail şi a produselor de unică folosinţă un cui îndreptat sau o şosetă cusută pare non-sens, probabil la fel vor zâmbii (sau zâmbesc déjà) oamenii care au crescut cu internet.
Dacă în trecut obsesiile bătrânilor noştri contribuiau doar la creşterea cantităţii nimicurilor depozitate în poduri, obsesiile noastre costă bani, ne costă pe noi, vă costă pe voi, îi costă pe toţi. Orice regulament inutil, orice pagină inutilă este scrisă de cineva, este controlat de cineva, plătit de cineva, necitit de altcineva – ne consumă timpul.

Oare de ce trebuie să adunăm datele şi informaţiile în documente fără sfârşit şi fără vre-un scop concret? Şi să le atichetăm? Doar pentru că printarea este ieftină? Pentru că copy-paste e gratuit?
Credeţi-mă, dacă am vrea, am putea scrie oricât în orice formă de reglementare. Dar nu vrem. De ce să o facem? Cu ce scop? Producerea de hârtie nu poate fi un scop.
Eu sunt satisfăcut, dacă reuşesc să predau informaţia folosind cât mai puţine caractere. Pentru mine regulamentele şi specificaţiile lungi nu sunt un merit, cu o greşeală. Orice poveste inutilă, orice formalitate, orice abstracţie existentă pentru ea însăşi, orice repetiţie reprezintă o insultă.
Reprezintă abuz asupra timpului meu, deoarece omului care a crescut déjà cu internetul, valoarea nu o reprezintă informaţia, ci timpul!

http://www.businesscover.ro/17-01-2012-securitatea-datelor-%E2%80%9Eplimbate-prin-stick-uri-usb-o-problema-tot-mai-mare-pentru-companii/?utm_source=Newsletter+Business+Cover&utm_campaign=b12e3f29bc-RSS_EMAIL_CAMPAIGN&utm_medium=email

Securitatea datelor „plimbate” prin stick-uri USB, o problemă tot mai mare pentru companii

Ethical Hacking vs. Pe*******on Testing

Sunt interesante aceste concept, le folosim aproape zilnic, dar sunt corecte? De fapt ce este considerat „corect”? Cine spune care din aceste concepte când poate sau nu poate fi folosit? Nu e totuna de fapt? Ooooooooo..., ba da, sau nu.
De o vreme a început şi acasă un fel de evanghelizare în vederea clarificării acestor concepte, unul din promotorii cei mai mari ai acesteia fiind prietenul meu Pánczél Zoli, aşa că am decis că folosind mijloacele modeste personale (şi desigur ale Alice & Bob) îl voi ajuta în postura lui de misionar. De ce? Deoarece cred că înţelegerea corectă a acestor două concepte contribuie semnificativ la înţelegerea corectă a conţinutului auditului de securitate IT. Este deosebit de important ca aceste lucruri să fie înţelese şi de client, deoarece dacă Clientul ştie despre ce este vorba şi îşi poate defini singur ce anume doreşte, care sunt aşteptările sale, atunci este mult mai mare probabilitatea unui proiect de succes, decât în cazul în care pur şi simplu ghicim unii gândurile celuilalt. Deci să vedem ce sunt aceste concepte. În prealabil aş vrea să adaug că aceste definiţii printre altele sunt folosite şi de SANS.
Să începem cu Ethical Hacking-ul (EH). Scopul unui proiect de EH este ca într-un cadru de timp definit auditorul să găsească cele mai multe vulnerabilităţi. Dacă de exemplu vorbim despre o pagină de web, atunci scopul EH-ului este să analizeze “toate” vulnerabilităţile de web, cât de securizată este pagina de noi. Auditorul nu se va opri la prima greşeală, ci va căuta şi altele. Putem spune că asta este o analiză orizontală, rămânând la exemplul paginii de web, se referă doar la nivelele de web, dar la acestea la toată paleta. Adică, de exemplu, nu va fi analizat ca ajungând la server prin acea greşeală de SQL injection este sau nu posibilă obţinerea unui acces de domain admin, deoarece aceasta analiză nu face obiectul contractului.
În schimb, în cazul unui proiect de Pe*******on testing (PT) scopul este ca “hacker”-ul să ajungă cât mai departe. Asta este mai mult o analiză vertical, deoarece aici întrebarea este de fapt cât de adânc se poate merge. Rămânând la exemplul anterior, este oare posibil, ca prin greşeala găsită pe respectiva pagină de web să obţinem un acces de domain admin. În acest caz auditorul nu va căuta toate greşelile de pe pagina de web, va căuta doar până va găsi una prin care poate pătrunde mai adânc. De exmeplu spargerea unui upload sau un sql injection. În cazul în care a găsit greşeala cu care poate rula o comandă OS nu va mai căuta alte greşeli (XSS, info leakage, etc.), ci va pătrunde cu un nivel mai adânc, va încerca să obţină drepturi de admin pe acel server, dacă le obţine, merge mai departe, va încerca să acceseze cât mai multe calculatoare. De multe ori, în cazul acestor proiecte Clientul defineşte un scop tangibil (un anumit fişier sau scrisoare, o parolă, etc.)
La ce este folositor unul şi la ce anume celălalt? Am fost déjà întrebat ce rost are un proiect de PT? Deoarece de fapt Clientul nu primeşte o listă completă de greşeli, doar finalizarea unui singur mod de atac. Este acest lucru bun pentru Client? Da, în primul rând din prisma faptului că PT de fapt simulează un atac de hacking, iar un hacker va proceda la fel, va căuta drumul cel mai simplu şi îl va urma până la capăt. În cazul unei analize EH dacă se găseşte o singură greşeală pe pagina de web, este de fapt un rezultat bun, dar un PT poate arăta ce se poate face cu acea singură greşeală (de ex. citirea corespondenţei directorului general).
În cazul introducerii unui system nou poate fi oportun EH, deoarece în acest caz Clientul este de obicei curios cât de bine şi-au făcut munca dezvoltatorii, cât de securizată este aplicaţia, pentru asta fiind evident necesară identificarea numărului maxim de vulnerabilităţi. Cu toate acestea, în urma unui PT se poate constata ca în cazul în care infrastructura IT este privită ca un system global, cât de bine poate acest sistem să reziste împotriva unui atac de hackeri. Desigur, ambele audituri au justificarea proprie, nu se poate afirma că una ar fi mai “bună” decât cealaltă, deoarece merele nu pot fi comparate cu pere. Clientul trebuie să fie conştient ce anume doreşte, ce anume doreşte să testeze şi conform acestora să definiteze o solicitare de EH sau de PT.
(Desigur, se poate întâmpla ca cele două să fie amestecate, sau de fapt să fie solicitate concomitant. Şi noi am avut déjà proiect de EH al unei pagini web, dar în acelaşi timp Clientul era curios până unde se poate ajunge cu greşeala identificată).