Ads 468x60px

keskiviikko 25. heinäkuuta 2012

Katsaus jatkuvuuden hallinnan standardiin – BS ISO 22301

Loppukeväästä, tarkemmin sanottuna 16. toukokuuta, julkaistiin jälleen uusi ISO –standardi. Tällä kertaa kyseessä oli ensimmäinen kansainvälinen standardi organisaatioiden jatkuvuudenhallintaan nimeltään ”BS ISO 22301 - Societal security — Business continuity management systems — Requirements”. Standardin julkaisu sivuutettiin niin tässä kuin monissa muissa tietoturvablogeissa. Joidenkin huhujen mukaan [1], kuitenkin tulevan ISO 27002 (tietoturvallisuuden hallinta) standardin päivityksen myötä, myös ISO 27002 standardi jatkossa viittaisi jatkuvuudenhallinnan osalta BS ISO 22301 standardiin ja näin erottaisi osuuden omaksi kokonaisuudeksi. Tästä johtuen myös BS ISO 22301 tulisi olla osa tietoturvapäällikköjen työkalupakkia ja osaamisaluetta.

Standardi pohjautuu vahvasti 2006 julkaistuun British Standard Instituten BS 25999 –standardiin. Nyt ISO adoptoi standardin omiin nimiinsä pienin muutoksin, vastaavaan tapaan kuten ISO 27002 standardin tapauksessa (pohjautuu vanhaan BS 7799 –standardiin).

Standardin ajatuksena on tukea organisaatioita jatkuvuuden hallintajärjestelmän luomisessa. Tarkkoja ”tee näin ja sitten näin” ohjeita on siis turha standardista lähteä kaivamaan.Vaatimukset keskittyvät pääosin hallintajärjestelmän vaatimien prosessien ja dokumenttien olemassaoloon niiden sisällön sijaan. Tämä on yleensä väistämätön lopputulos siitä kun luodaan viitekehys, jonka tulee sopia niin pienien kuin suurten organisaatioiden käyttöön, toimialasta riippumatta. Ajatus on, että organisaatio itse määrittää prosessien ja dokumentaation sisällön toimintaympäristön ja johdon tavoitteiden mukaisesti, niin että lopputuloksena on hallintajärjestelmä joka istuu kontekstiin. Myös ajatus hallintajärjestelmästä organisaation jatkuvuuteen liittyen on monille uutta (hallintajärjestelmä ajatus oli jo tosin mukana BS 25999 – standardissa). Standardin luojien mielestä, samoin kuin useiden organisaatioiden jatkuvuuteen keskittyneiden ammattilaisten mielestä, aikaisempi suunnittelu lähestyminen ei ole riittävä. Tässä tehdään ero jatkuvuussuunnittelun ja jatkuvuudenhallinnan välillä; jatkuvuussuunnittelu on osa jatkuvuudenhallintaa mutta ei synonyymi. Siinä missä jatkuvuussuunnittelu on ollut luonteeltaan kovin dokumentti keskeistä ja usein jäänyt kerta rutistukseksi, jonka aikana kasa dokumentteja on luotu hyllyyn pölyttymään, jatkuvuudenhallinta pyrkii saamaan organisaation jatkuvuuden turvaamisen sisällytettyä osaksi organisaatiota ja sen kehittämisestä jatkuvaa.

Huomioitavaa standardissa on myös standardiperhe, johon uusi standardi kuuluu. Toisin kuin ISO 27000-standardit, jotka ovat ”Information technology” standardeja, on BS ISO 22301 osa ”Societal security” perhettä. Yhtenä ajatuksena BS ISO 22301 standardissa onkin juuri yhteiskunnan jatkuvuuden, tai ”kimmoisuuden” (eng. resilience) lisääminen. Yhteiskunnan toimivuus nojaa suurelta osin eri julkshallinnon sekä yksityisen sektorin tuottamien palveluiden toimivuuteen. Kohentamalla organisaatioiden jatkuvuudenhallintaa, koko yhteiskunnan ongelmien sietokyky kohenee. Tulevaisuus näyttää miten hyvin suomalaiset organisaatiot tulevat standardin omaksumaan ja mikä sen rooli tulee olemaan yhteiskunnan sietokyvyn kohentamisessa. Perustuen ensimmäisten kuukausien aikana tulleisiin tarjouspyyntöihin, ainakin osa asiakkaista on julkaisun huomanneet ja kokeneet hyödylliseksi...


Marko

[1] http://www.infosecisland.com/blogview/18345-ISO-27002--What-Will-the-Next-Revision-Bring.html

perjantai 13. heinäkuuta 2012

Tietoturvaa ja arkkitehtuureja

Toteutin hiljattain tietoturva-auditoinnin asiakkaan pyynnöstä heidän uudelle käyttöönotetulle teknologialle, jonka tarkoitus oli helpottaa käyttäjien arkea mahdollistamalla ajasta ja paikasta riippumaton työskentely. Auditoinnissa löydettiin liki 50 havaintoa kohdistuen käyttäjien ohjeistukseen, palveluprosesseihin ja teknisiin alustoihin. Kullekin havainnolle annamme aina riskiarvion ja suosituksen mitä auditoinnin tilaajan kannattaisi tehdä korjatakseen ongelman. Asiakas luultavasti tilaa palveluidensa toimittajalta korjaukset suositustemme mukaisesti ja korjaa ongelmat. Kaikki tyytyväisiä?
Kyseinen toimintatapa on varsin yleinen:

  1. Organisaatiossa päätetään ottaa käyttöön jotain uutta teknologiaa tai uusi toimintatapa
  2. Organisaatio tilaa työn palveluiden toimittajalta, joka toteuttaa Tilaajan idean, eli implementoi jotain avain uutta muuttaen organisaation teknologiasalkkua ja toimintatapoja 
  3. Uudet palvelut otetaan käyttöön laajamittaisesti ja organisaation tietoturvapäällikkö saa kuulla niistä
  4. Tietoturvapäällikkö tekee auditoinnin tai tilaa sellaisen varmistaakseen uuden palvelun turvallisuuden 
  5. Auditoinnissa löydetään läjä ongelmia 
  6. Organisaatio tilaa palvelutoimittajaltaan korjaukset toteutettuihin palveluihin ja suunnittelee miten käyttöönotetuissa palveluissa voidaan tehdä muutos koko käyttäjäkunnalle 
  7. Viikkojen tai kuukausien jälkeen osa ongelmista on korjattu, mutta merkittävimmät havainnot jää korjaamatta 
Kuulostaako tutulta? Mitä jos ongelmaa olisikin lähestytty hieman toisin? 
  1. Organisaatiossa keksitään jotain uutta
  2. Uusi idea viedään arkkitehtuuriryhmään keskusteltavaksi, joka arvioi miten uusi asia vaikuttaa organisaation strategisiin ja taktisiin suunnitelmiin toiminnan, tietojärjestelmien ja teknologian kannalta
  3. Arkkitehtuuriryhmä toteaa, että ajatus on hyvä ja uuden asian suunnittelu voi alkaa sillä ehdolla, että mukana on tietoturva-arkkitehti, joka varmistaa ettei merkittäviä organisaatiolle muodostu merkittäviä riskejä 
  4. Palvelutoimittaja, projektiryhmä ja tietoturva-arkkitehti suunnittelevat ja toteuttavat uudet palvelut ja huolehtii että organisaation arkkitehtuuriryhmä on aina tietoinen siitä miten palvelut vaikuttavat organisaation kokonaisarkkitehtuuriin 
  5. Palvelukokonaisuudelle tilataan auditointi, jolla varmistetaan implementoinnin onnistuminen 
  6. Auditoinnissa löydetään alle kourallinen pieniä konfiguraaitio virheitä, jotka korjataan välittömästi 
Omien havaintojeni mukaan jälkimmäistä toimintatapaa opetellaan edelleen suomalaisissa organisaatioissa. Jostain syystä sekä arkkitehdit, että tietoturva-asiantuntijat nähdään ongelmallisina kavereina, jotka joko istuvat norsunluutorneissa tai näsäviisastelevat toteutetuista asioista. 

Pihvinä ja porkkanana kuitenkin voidaan kertoa, että jälkimmäisellä toimintatavalla saadaan kustannussäästöjä, huolehditaan organisaation toiminnan tehokkuudesta ja luodaan edellytykset ketterille muutoksille, joita organisaatio tarvitsee selviäkseen. 

Me tietoturva-arkkitehdit olemme leppoisia kavereita, jotka tulevat mielellään auttamaan uusien toimintatapojen kehittämisessä, tietojärjestelmäsuunnittelussa ja teknologia valinnoissa. Toimimme organisaation kaikilla tasoilla (kyllä, yritysjohdosta koodareihin asti) tukien projekteja arkkitehtuurin keinoin!

Hyvää kesää! 


keskiviikko 11. heinäkuuta 2012

Heinäkuun linkkikokoelma - osa 2



Jatkoa eiliseen linkkilistaan...

Oppaat

Metasploit exploit development tutorial

Basic Metasploit exploit creation tutorial

Shellcode tutorials

Powershell security tutorials

Decrypting SSL packet dumps using Chrome and Wireshark

Cisco has produced an internetworking technology handbook

Cool article on bypassing ASLR and DEP in Adobe Reader X

Haittaohjelmat / poikkeamanhallinta

Security guy attempts to debug some malware, and the developer starts a conversation through the malware!

Evidence of intrusions cheat sheet

An analysis of rootkit technologies

Mobiili

Android hacking applications

Android Malware and reverse engineering

Android network analysis

Run Android apps on a Mac

Web-sovellukset

Interesting article on ARP poisoning (and burp)

BeEf in a real-world pentest

SQL Injection Obfuscation

tiistai 10. heinäkuuta 2012

Heinäkuun linkkikokoelma - osa 1

Seuraavassa KPMG:n Pentest-yhteisön keräämiä linkkejä hiljaisten toimistopäivien täytteeksi tai ajan hermolla pysyttelevän lomailijan kesälukemistoksi.

Kesäterveisin, Samuel Korpi.

Yleiset

Super list of all security conference videos
https://www.phx2600.org/forum/viewtopic.php?f=31&t=1531

UK Government social media guidance document

It seems the Kindle contains scriptable plugins would could allow any website to execute shell commands
http://www.mobileread.com/forums/showthread.php?t=175368

Get paid for your exploits (Nice site)

Smartmeter attack and assessment framework

Seems BMWs are now being targeted via their ODB

Työkalut

Cool NMAP script to screenshot web services

Script to get the low hanging fruit from Nessus scans

Generate hashes of all different types

Metasploit post module for finding files

Minikatz has a crypto module for exporting “non-exportable” certificates

Metasploit post exploitation – Outlook credentials

USB device emulation for fuzzing

MWR have released their IPv6 toolbox

perjantai 6. heinäkuuta 2012

Saisinko saman kirjallisena, kiitos.

Tarkkaavaisempi lukija saattoi otsikon lukiessaan kurtistaa kulmakarvojaan ja miettiä miksei pisteen tilalla ollut kysymysmerkkiä. Tilanne kuvastaa kuitenkin sitä tilannetta, mitä monet organisaatiot joutuvat erilaisissa auditoinneissa kokemaan. Kun kyseessä on kolmannen osapuolen, viranomaisen tai muun tahon velvoittama tarkastus, ei ystävällisinkään auditoija voi sivuuttaa vaadittujen dokumenttien katselmointia. Usein tilanne saattaa olla hieman turhauttava molempien osapuolten kannalta, sillä organisaatio saattaa toimia lähes esimerkillisesti jonkin asian suhteen, mutta ilo päättyy lyhyeen auditoijan kysyessä esimerkiksi standardin velvoittamana: ”Saisinko nähdä saman vielä kirjallisena, kiitos.”

Organisaatiolta vaadittavat dokumentit ovat yleensä osa suurempaa kokonaisuutta, joka juontaa organisaatiota ja sen toimintaympäristöä koskevista vaatimuksista, säädöksistä ja laeista. Kaikki lähtee siis ensisijaisesti näiden eri lähteiden tunnistamisesta, minkä pitäisi olla yksinkertaisesti ajateltuna lähes päivänselvä asia. Aina näin ei kuitenkaan ole. Melko yleistä on myös se, että edellä mainitut lähteet on tunnistettu, mutta niiden oikeaoppinen tulkitseminen sekä organisaation toimintaa hyödyttävä soveltaminen käytäntöön on puutteellista. Tällaisissa tilanteissa vaatimusten täyttämisestä saattaa olla organisaatiolle käytännössä jopa enemmän haittaa kuin hyötyä. Resurssit keskitetään vääriin asioihin, aikaa ja rahaa palaa, keskitytään epäolennaiseen eikä toiminta ole liiketoimintalähtöistä.

Pahimmillaan dokumentaatiosuo saattaa siis aiheuttaa hyvinkin harmaita hiuksia, ellei jopa täyttä kaljuuntumista. Entä parhaimmillaan?

Hyvä dokumentaatio ei ole tehty auditointeja varten, vaan se on hallittu ja ajantasainen kokoelma dokumentteja, jotka tukevat organisaation toimintaa sen tavoitteiden mukaisesti, ohjaavat toimintaa arjessa ja ovat pelastava enkeli paniikkitilanteissa. Hyvä dokumentaatio on yksi organisaation peruspilareista. Hyvästä dokumentaatiosta ja sen ylläpidosta on paljon enemmän hyötyä kuin vaivaa. Hyvässä dokumentaatiossa on kaikki oleellinen, mutta ei mitään ylimääräistä. Hyvä dokumentaatio on työntekijöiden tiedossa ja helposti saatavilla.

Mikäli näin ei ole, jokin on vialla.

Samat dokumentaatiorakenteet ja –kokonaisuudet eivät sovi jokaiselle organisaatiolle, vaan yleensä organisaation tarvitsee luoda ne omiin tarpeisiinsa ja oman näköisikseen. Tämä ei ole aina helppoa, ja jos jokin tuntuukin olevan vialla, ei kohtalotovereita tarvitse etsiä kaukaa. Yhä useampi organisaatio onkin alkanut käyttää ulkopuolista apua tunnistaessaan tarpeet, laatiessaan dokumentaatiohierarkian sekä itse dokumenttien tuottamiseen ja jalkauttamiseen osaksi organisaation jatkuvaa toimintaa. Pelkästään ulkopuoliseen apuun ei toki voida nojata, sillä sisällön räätälöimiseen tarvitaan myös organisaation sisäistä tietämystä. Konsultti voi kuitenkin auttaa hahmottamaan tarpeet, tukea dokumentoinnissa ja muun avun lisäksi tarjota esimerkiksi tarvittavat mallipohjat. Yleisiä dokumentaatiokokonaisuuksia ovat esimerkiksi jatkuvuudenhallinta, tietoturvapolitiikat, ohjeistukset ja säännöt sekä järjestelmädokumentaatiot.

Kuten todettiin, osa dokumenteista on hyvin tarpeellisia tai lähes välttämättömiä. Kannattaa kuitenkin myös pitää mielessä, että osaa organisaation dokumenteista ei päinvastoin välttämättä saisi enää säilyttää. Monet säädökset koskettavat myös tiedon elinkaarta ja tuhoamista. Näin kesälomien kynnyksellä organisaatioissa voitaisiinkin pitää erityiset dokumentaatiotalkoot, jossa nykyisiä ja vanhentuneita dokumentteja (niin digitaalisia kuin paperimuotoisia) käydään läpi sekä tarvittaessa tuhotaan turvallisesti. Samalla on mahdollisuus muistuttaa työntekijöitä (ja kesätyöntekijöitä) vaikkapa turvallisesta tiedon säilytyksestä. Kesän jälkeen voikin rentoutuneena miettiä oman organisaation dokumentaation yleistilaa sekä pitää mielessä esimerkiksi mahdolliset syksyllä tulevat auditoinnit. Hyvällä valmistautumisella voi yllättää auditoijan positiivisesti ja vilauttaa aiheeseen liittyvää dokumenttia jo ennen kuin korvissa kaikuu sanat: ”Kirjallisena, kiitos.”

Tätä ennen toivotan kuitenkin jokaiselle aurinkoista ja äärimmäisen dokumenttivapaata kesää!