reede, 30. mai 2014

Tehnosotsiaalne sahkerdamine

Sotsiaalne sahkerdamine (Social engineering) on meetod, mille käigus kasutatakse infole või ressurssidele (nt IT-süsteemidele) omavolilise ligipääsu saamiseks erinevaid inimestega manipuleerimise tehnikaid. Oskusliku pettuse tõkestamine on üpriski keeruline, sest inimeste loomuses (ja sageli ka töökirjelduses) on olla abivalmis ja kuulekas. Seetõttu on isegi umbusklikul töötajal raske keelduda autoriteetse ja enesekindla häälega jagatud juhistest või hädasolija abipalvest. Mis see sotsiaalne sahkerdamine aga ikkagi täpsemalt on ja kuidas sellega kaasnevatest kurbadest tagajärgedest hoiduda?


Sotsiaalne mõjutamine

Teiste inimeste mõjutamine kui meetod oma eesmärkide saavutamiseks pärineb juba eelajaloolisest ajast, sest ilma üksteise mõjutamiseta on praktiliselt võimatu koostööd teha. Sotsiaalse sahkerdamise all on aga antud kontekstis mõeldud pigem omakasupüüdlikku manipulatsiooni, mis võimaldab saavutada vajaliku tulemuse lihtsa suhtluse abil. Küberturvalisuse kontekstis rõhutab social engineering võimalust inimeste manipuleerimise abil mööda hiilida tehnilistest turvameetmetest. Näiteks võib e-posti kontole ligipääsemiseks keeruka häkkimise asemel lihtsalt kasutajalt otse küsida. Kui õnnestub jätta mulje, et seda nõuab ülemus, politsei või keegi teine autoriteetne isik, siis ei ole sugugi välistatud, et kasutaja oma parooli näiteks telefonikõnes vabatahtlikult avaldab. Veel üks levinud võte personaalset informatsiooni välja petta on teenindava personali kaudu, kelle tööülesandeks on inimesi aidata. Hädasoleva kliendi või väidetava kolleegi aitamiseks võivad mitmed teenindajad kogemata manipulatiivsele ründajale konfidentsiaalset informatsiooni paljastada.

Tehnosotsiaalne sahkerdamine 

Eriti tõhus (ja seetõttu ohtlik) on sotsiaalne mõjutamine, kui seda kombineerida tehnilise küberrünnakuga. Näiteks võib rünnatav arvutikasutaja keelduda oma kasutajanime ja parooli telefoni teel avalikustamast, kuid installib kuulekalt väidetava IT-toe poolt saadetava turvauuenduse, mis võib tegelikult olla viirus, klahvinuhk (keylogger) või muu pahavara. Tänapäevaste vabalt Internetis levitavate häkkimisvahenditega on lihtne luua vajalikust veebilehest suhteliselt täpne koopia, mis salamisi külastajate arvutitest turvaauke püüab leida. Vahel pole isegi turvaauku vaja leida, kui õnnestub rünnatavat kasutajat veenda oma isiklikke andmeid vabatahtlikult sisestama.

Tehnilisi ja sotsiaalseid oskusi meisterlikult kasutades suutis Kevin Mitnick, üks tuntumaid sotsiaalseid sahkerdajaid, kolm aastat FBI-ga kassi-hiirt mängida. Kui FBI agendid (enda meelest) ootamatult Mitnick’i korterit külastasid, leidsid nad külmkapist paki sõõrikuid pilkava sildiga “FBI donuts.” Mitnicki enda sõnul tegeles ta inimeste tüssamisega peamiselt enda lõbuks, mitte rahalistel eesmärkidel.

Aina rohkem on aga küberkriminaalid hakanud inimeste lihtsameelust ja abivalmidust kurjalt ära kasutama just sooviga - kas siis otseselt (nt inimestelt raha või hinnalist infot välja pettes) või kaudselt (nt konkurendi mainet kahjustades) - rikastuda. Kuna sotsiaalne sahkerdamine on oma olemuselt väga lihtne, siis on seda ennetada üpris keeruline. Näiteks pommiähvardusega saab hakkama isegi algkooli õpilane ja tegelikku ähvardust võltsist eraldada on praktiliselt võimatu. Kuidas siis ikkagi vähendada riski tehnosotsiaalse sahkerdamise ohvriks sattuda?

Sahkerdamisvastased abinõud

Tehnosotsiaalse sahkerdamise vastu tegutsemist tasub organisatsioonides alustada uutest töötajatest, sest just nemad on oma ebakindluse ja kogenematusega libekeelsete ründajate lemmiksihtrühm. Võimalikult varakult tuleks veenduda, et kõik töötajad on kursis organisatsiooni eeskirjade ja tavadega. Lisaks tuleks kõigile töötajatele selgeks teha, kuidas potentsiaalseid pettureid ära tunda ja mida sel juhul teha.

Näiteks tasub eriti ettevaatlik olla tundmatute inimestega, kellel on väga kiire. Hädaolukorra (vähemalt näilik) loomine takistab rünnataval isikul selge pilguga olukorda hinnata ja suurendab tõenäosust, et tegutsetakse mõtlematult petturi abistamiseks. Peaaegu alati on võimalik korraks aeg maha võtta ja pakilist probleemi rahulikult lahata. Abiks oleks kindlasti ka täpsed eeskirjad, mida erinevate hädaolukordade puhul tuleks järgida.

Teine märk, mis peaks koheselt valvsust suurendama, on salasõna küsimine. Professionaalne IT-töötaja, koristaja, naaber alumiselt korruselt, teller pangas ega keegi teine ei tohiks huvi tunda kellegi teise isikliku salasõna või koodi vastu.

Valvsust peaks koheselt suurendama ka e-kirjas sisalduv viide või manustatud fail. Kui e-kiri pärineb tuttavalt inimeselt, kuid selle sisu on vähimalgi määral ebatavaline, siis tasub võimaluse korral saatjaga (näiteks telefoni teel) ühendust võtta ja kontrollida, et kiri tõepoolest pärineb väidetavalt isikult.

Lisaks tehnilistele tulemüüridele ja viirusekaitseprogrammidele tasuks üle vaadata ka arvuti füüsiline kaitse. Näiteks pole sugugi välistatud, et suuremates organisatsioonides saab enesekindla olekuga kurikael sületäie sülearvutitega tähtsal ilmel asutuse peauksest välja marssida ilma, et keegi midagi kahtlustaks. Töökohas oma arvuti tagant lahkudes tasub see kindlasti lukustada. ASA Quality Services kontoris on näiteks selline kord, et järelvalveta ning lukustamata jäetud arvuti omanik toob kolleegidele maiustamiseks koogi. Säärased meetmed tekitavad ka uutes töötajates kiirelt harjumuse laua tagant lahkudes oma arvuti eeskirjade kohaselt lukustada.

Turvalisuse mitu kihti

Erinevate inimmanipulatsioonide vältimisel ei maksa aga unustada ka tavapärast turvarutiini. Mitmeastmeline autentimine ja korralik paroolihaldus aitavad võimaliku infolekke levimist tõkestada ning tarkvarauuendused takistavad laialdaselt teadaolevate turvaaukude ärakasutamist. Nii nagu maja ehitamisel ja korras hoidmisel tuleb tähelepanu pöörata igale seinale (ning meeles pidada ka vundamenti ja katust kontrollida), nii tasub ka küberturvalisuse puhul tähelepanu pöörata lisaks arvutitevahelist suhtlust kirjeldava OSI mudeli seitsmele suhtlustasandile ka kaheksandale – inimfaktorit sisaldavale kihile. Kõige tõhusam kaitse küberrünnakute vastu on terviklik turvapoliitika: lisaks tehniliste rünnete vältimisele tuleks hoiduda ka sotsiaalse sahkerdamise eest.




Sten Mäses
ASA Quality Services

Piltide allikad: img.gawkerassets.com ja edugeeks.in

neljapäev, 29. mai 2014

Automaattestimine - mis see on?

Kõik infotehnoloogiaga tegelevad ettevõtted teavad, et testimine on vajalik, kuid tihti leitakse ka juba töötavas ehk live-süsteemis vigu. Mida siis tehakse valesti? Kas testimiseks kulutatakse liiga vähe aega? Puuduvad oskused testida või ei testita seda, mida vaja? Räägin järgnevalt ühest võimalikust lahendusest, mis võib muuta testimise protsessi oluliselt kiiremaks – nimelt automaattestimisest.

allikas: http://www.wallpele.com/robot-3d-hd-wallpaper/robot-3d-hd-wallpaper/

Mis siis ikkagi on automaattestimine? See on arvuti õpetamine, kuidas mingit infosüsteemi testida. Kirjutatakse valmis koodijupid, mille käivitamisel teeb arvuti läbi tegevused, mida muidu testija peaks käsitsi tegema. Manuaaltestimisest erinebki see selle poolest, et sisaldab endas koodikirjutamist. Testide automatiseerimine on aeganõudev tegevus, kuid tasub ära, kui testimisfaasis on tegevused, mida manuaaltestija peab mitmeid kordi kordama.

Automaattestimise kasutusjuhud

Millistel tingimustel on mõttekas testide automatiseerimist kasutada?

  • Kui tegemist on suure infosüsteemiga, mille käsitsitestimine võtab nii palju aega, et see muutub pudelikaelaks arendusprotsessis.
  • Kui osa süsteemist on juba valmis, kuid arendamine veel käib. Sellisel juhul on regressioonitestide* tegemine väga oluline. Enamasti automatiseeritakse just regressiooniteste.


Millistel tingimustel võiks selle mõtte välistada?

  • Kui testimiseks on väga vähe aega.
  • Kui planeeritud testimisringe on ainult mõni (näiteks üks või kaks).
  • Kui käsil on UAT (vastuvõtutestimise) faas.
  • Kui tegu on väikese süsteemiga, millele ei tule lisaarendusi.

Muidugi on olemas erandeid ja puudub 100% õige variant, kuidas süsteem saaks piisavalt testitud. Piisava testimise all ei mõtle ma täielikku testimist (exhaustive testing). Pidagem silmas, et täielik testimine pole otstarbekas ja on üsna võimatu. See on ajamahukam, kui infosüsteemi arendamine, ja võib isegi öelda, et nn kilplaslik tegevus. Piisava testimise all mõtlen ma seda, et kõik ärinõuded on kontrollitud, täidetud ning ärinõuete järgi arendatu töötab. Automaattestimine on üks võimalus, kuidas süsteemi testimise protsessi kiirendada. Seega aitab see ka etteantud ajapiirangu sees suuremat osa süsteemis olevat funktsionaalsust kontrollida võrreldes ainult käsitsitestimise kasutamisega.

Automatiseeritud testikomplektide haldamine 

Automaattestimist võib võrrelda programmeerimisega, sest selles protsessis kirjutatakse koodi ning kasutatakse erinevaid programme ja platvorme. Samuti on oluline versioonihaldus ehk kirjutatud koodijupid peavad olema korralikult organiseeritud ning loetavad. Harjumuspärane tegevus on ka testikomplektide hooldus, sest valmiskirjutatud skriptid võivad kergelt katki minna. Nagu näha – testide automatiseerimine sisaldab endas palju tööd.

Veel märkuseid

  • Kõiki teste pole mõttekas automatiseerida – alati tuleb mõned osad süsteemist käsitsi läbi testida, kuna masinat ei saa täielikult usaldada.
  • Testide automatiseerimine on kallis.
  • Automatiseerimiseks on väga palju erinevaid vahendeid ning enne automaattestide kirjutamist tuleks enda jaoks selgeks teha, milline neist on parim.
  • Automaattestimise eelduseks on korralik testianalüüs ehk peab olema välja selgitatud, mida automatiseerida. Kindlasti ei saa teha nii, et hakatakse eelneva planeerimiseta lihtsalt mingist süsteemiosast testilugudele automaatteste kirjutama, sest pärast on raske saada ülevaadet, millised osad on kaetud ja mis mitte.
  • OHT: ebarealistlikud ootused – levinuim viga, mille tõttu võib automatiseerimine läbi kukkuda. Sellised on näiteks ootused, et testimine muutub palju odavamaks või et leitakse kõik vead. 


Edulugusid

Tegelikkuses tasub automaattestimine end kuhjaga ära – seda tuleb vaid õiges kohas rakendada. Näiteid edukast automatiseerimisest on mitmeid. Näiteks Dorothy Grahami ja Mark Fewsteri raamatus „Experiences of Test Automation“ on mitmeid lugusid. Üks jutuke ses raamatus Randy Rice’i poolt räägib sellest, kuidas suures Wall Street’i ettevõttes kasutas ta seda võimalust. Nimelt - ühe õnnetu daami tööülesandeks oli iga päev 8 tundi järjest läbida samu testilugusid. Mees leidis, et peaks ressursse targemini ära kasutama ning võttis ühendust testide automatiseerimist pakkuva firmaga, kes automatiseeris kolme päevaga selle 8 tunni töö. Testilugude läbimiseks kulus nüüd daamil igal hommikul vaid 15 minutit ja ta sai kasutada oma aega uute funktsionaalsuste testimiseks.

Pilt: Shutterstock


Eduka automatiseerimise tulemuseks on ajaline ja ka rahaline võit. Sõna „edukas“ on suure kaaluga, sest nagu eelnevalt kirjutasin, on suur oht automatiseerimisest liiga palju oodata. Seda vales kohas kasutades võib see vaid kuluks osutuda.

Kokkuvõtteks

Loodan, et see postitus andis põgusa ülevaate ja arusaamise, millega tegemist on. Kui tekkis küsimusi või tahate hoopis vastu vaielda, ootan teid postitust kommenteerima.


Kristi Paakspuu
ASA Quality Services

*regressioonitestid – igasugused tarkvara testid, mis otsivad muudatuste käigus ilmnenud vigu eelnevalt korrektselt funktsioneerinud koodis. Selle eesmärgiks on leida ootamatuid vigu.

Kasutatud kirjandus:

  • Dorothy Graham, Mark Fewster „Experiences of Test Automation“, 2012



teisipäev, 6. mai 2014

IREB requirements engineeringu koolitus - täpsustatud kava

10. - 12. mail 2016 toimub IREBi nõuete ehitamise (Requirements Engineering) koolitus.

Tarkvara nõuete kogumisel ja kirjeldamisel tehtud vead tekivad varakult, jäävad leidmata ja ... nende parandamine on ülimalt kallis... Tahad teada, kuidas tarkvaranõudeid ehitada? Kas nõuetel on kohta agiilses tarkvaraarenduses? Kuidas vältida „tõlkes kadumaminemist“ tarkvaraprojektides? Kuidas tarkvaranõudeid testida? Kuidas tarkvaranõudeid vääriliselt hallata? Tule koolitusele! 
Millal? 17. - 19. mail 2017
Kus? Ehitajate tee 108, ASA koolitusklass
Kui palju maksab? märtsis 1440€ +KM (edaspidi 1600€+KM). Hind sisaldab elektroonilisi ja trükitud materjale ning kohvipause ja lõunasööki kolmel päeval. Alates kolmest inimesest ühest ettevõttest soodustused
Koolituse keel: inglise
Registreerumine ja küsimused: maili [at] asaquality.ee
Koolituse eesmärk: Anda põhiteadmised nõuete ehitamise (requirements engineering) põhilistest valdkondadest: süsteemi konteksti mõistmine, nõuete alusinfo kogumise tehnikad, korrektne ja üheseltmõistetav kirjapanemine, läbirääkimised vastuolude leidmiseks ning kõrvaldamiseks, nõuete haldamine ja abistavad tööriistad.
Koolituse läbinul on võimalik lisatasu eest (280€) sooritada CPRE-FL sertifikaadieksam, mida pakub  IT Koolituskeskuse OÜ (www.koolitus.ee).

Koolituse sihtrühm: Põhiline sihtgrupp on analüütikud (süsteemi- ja ärianalüütikud), kes nõuete ehitamisega igapäevaselt tegelevad. Laiemalt kõik rollid, kes peavad ära tundma, kas nõuded on kvaliteetselt kirjeldatud ja oskama öelda, mis vajab parandamist (näiteks kõrgema taseme testijad või testijuhid).

Koolitajad: Matthias Koch, Eduard Groen (Fraunhofer IESE, www.fraunhofer.de)

Matthias Koch studied computer science with a focus on software engineering. Since 2012, he is employed as engineer at Fraunhofer IESE and mainly addresses the topics of requirements engineering and business analysis. In this context, he was involved in research projects on the pre-project and requirements definition phase, case studies and product evaluations. In research as well as industry projects, he regularly acts as requirements responsible, conducts workshops with customers and provides consulting.

Eduard C. Groen received his Master of Science in Psychology, with a specialization in Engineering Psychology, from the University of Twente in the Netherlands. He furthermore has experience with quality and sustainability management. His fascination with the rapid rise of man-machine interfaces and other changes that affect society inspires him to contribute with technologies that optimally make use of the potential that these developments bring. This is why he leads the development of “Crowd-based Requirements Engineering” at Fraunhofer IESE, a tool-based approach to elicit and validate requirements with large online crowds. He furthermore provides trainings, and consults in projects on process management and variability management.

Päevakava (orienteeruv):
Day 1 (09:00-17:00)
Introduction & Basics - software requiremets
Defining the System Context
Requirements Elicitation (survey, creativity, observation and other techniques)
Requirements Specification and documentation
Exercises

Day 2 (09:00–17:00)
Repetition
Requirements Specification and documentation continues
Requirements Modeling (functional, data and behavioral models)
Exercises

Day 3(09:00–17:00)
Repetition
Requirements Validation & Negotiation
Quality attributes of requrements
Requirement testing methods
Resolving requirements conflicts

Requirements Management and versioning
Establishing requirements traceability
Prioritizing requirements
Requirements Tools overview
Wrap-up

Teemast loe lähemalt veel siit: http://asaquality.blogspot.com.ee/2014/04/alustame-ehitamist-vundamendist.html