Software patching strategy...

There's much controversy about security flaw found in Windows XP and published by Google's researcher. You can read about it across the Internet, but here's one story. Short version is this: after the researcher found the flaw he gave Microsoft five days to react. But, Microsoft has something called 'patch Tuesday' which means it is delivering patches every Tuesday. I agree that this brings predictability to IT departments, but this is only true if the number of patches is high. So in the end, Microsoft didn't react in the given timeframe and the researcher published exploit. As I sad in one comment, I don't believe that Microsoft didn't react on purpose. It is more likely that they didn't know how to react and/or their procedures are not up to the task. Some are criticizing the researcher's approach, while the others are not. And it is true that this brought some IT managers, CISOs and who knows who else into very dangerous situation. But then, something like this should be made equal to impossible by a responsible company that is producing such a critical piece of a software like OS.

Contrast this researcher's behavior with some cracker that happened to find the same flaw. He could either sell it or devise exploit himself. In either case the exploit would be used at some point and the software producer wouldn't be notified about the flaw. By the time it is clear that there is a flaw, five days to react is huge time frame!

What is my point? The point is that in present times, and in future even more so, it is luxury to react in more than a day, maybe even in more than a few hours. Patches and workarounds have to be available immediately. Of course, someone could comment now that in the complex software it is hard to devise patch in a such short time frame. But, actually, I think it is possible with few changes in how software is developed.

First, software has to be clearly modularized. Each module has to have capability to be disabled or enabled. Obviously, when a flaw is found in a module, the first reaction would be to disable the module. Of course, there are two problems with this. The first one is that there are modules that are absolutely critical for a functional system. For example, in Linux kernel it is not possible to disable kernel locks because kernel can not function without them. But such a critical software should be made small and controllable so that it can be fixed in a matter of hour. The second problem is that some modules are not critical for the system itself, but are critical for the environment in which they are working. For example, driver for a network card. It can be disable, and the system itself will be functional, but it will also be useless. This case should be handled in such way that each user can use predefined functionality definitions and alter them or create a new ones. To return to an example with a driver for a network card. In this case it is common wisdom that no system today can work without network card. So, some profile will define network card as critical and as such it will not be disabled without explicit confirmation from the administrator. But, such modules have to be developed with principles somewhere in between the absolutely necessary modules and modules that aren't necessary at all (like Help system that is the cause of the problem with Windows XP that started this blog entry).

Nokia N900

Note: This post has been transferred from my old home page on January 4th, 2020 and the date of the publication is only approximate.

At the end of the January 2010 I bougth new Nokia N900 tablet. On this page I'll write about my experiences with this phone. You'll also find pointers and tips&tricks I gathered on the Internet.

Options to connect to the Internet

WLAN

Bluetooth

USB

N900 USB networking
I had a problem with no dummy network appearing in the connection list. After applying gconftool-2 commands from this thread and killing icd2 daemon, the connection appeared in the list.

Linux related stuff

Rebooting device from command line

The shutdown command isn't working at the time I write this. There is alternative method described in this post.

Links

Kako izabrati Web stranice za tvrtku?

Već neko vrijeme si razmišljam kako bi mogao započeti pisati nekakvu vrstu konzultantske miniserije, tj. upute što napraviti u određenim nabavkama i modernizacijama IT infrastrukture. Ideja ne nedostaje, primjerice VoIP, Web stranice, VPN, DMS, poslužiteljska infrastruktura, itd. Kod svih ovih nabavki karakteristika je da tvrtka dobavljač/izvođač u općem slučaju ima kao svoj cilj maksimizirati profit i minimizirati količinu utrošenih resursa, uz naravno, cilj da baš ona dobije posao. To se u praksi manifestira u nekoliko oblika:

1. neće Vam spominjati alternative, ili ako ih spominju uglavnom će ih ocrnjivati,
2. pokušat će vam prodati svoja vlastita rješenja umjesto nekih standardiziranih,
3. pokušat će Vas vezati uz sebe u smislu da će pristajati na sve prije nego što donesete odluku, dok kad jednom pristanete uzeti njihovo rješenje više nemate mogućnosti promjene i sve odjednom postaje puno teže ili nemoguće.
   

Jasno, ove tri manifestacije variraju u ovisnosti o mnoštvu parametara. Otežavajuća činjenica je i da svaka tvrtka ima svoje posebnosti zbog čega je bilo kakvo uopćavanje u pravilu nezahvalno. Iz tog razloga ove tekstove treba shvatiti više kao smjernice nego kao algoritam koji treba provesti kako bi se došlo do konačnog rješenja.
U ovom prvom tekstu pozabavit ću se Web stranicama, tj. situacijom kada nekakva tvrtka odlučuje da treba Web stranice radi promidžbe, bilo da postojeće više nisu dovoljne ili uopće do sada nije bilo Web stranica. Poanta je da se radi kompletna promjena što je situacija u kojoj je najlakše pratiti različite opcije.
Web stranice su specifične zbog toga što su direktno izložena na cijelom Internetu te su najčešća meta napada. Primjerice, na stranici http://www.zone-h.org/ nalazi se arhiva uspješno napadnutih Web stranica zajedno sa kopijom napadnute stranice. Nije potrebno objašnjavati koji je to problem za javnu sliku (image) tvrtke ako se nešto loše desi. Pogotovo je to problem ako se putem Weba može doći do osjetljivih informacija koje nisu namjenjene svima (zaštićene su nekakvim lozinkama i slično). Zbog toga treba pažljivo birati rješenje kako bi se minimizirala mogućnost takvih problema. Ovom prilikom treba istaknuti i da Vam nitko ne može jamčiti 100% sigurnost, tj. ako netko tvrdi da sigurno nitko neće provaliti tada Vam laže. Mogućnost provale uvijek postoji!

Statične ili dinamične Web stranice
Dakle, prvo pitanje na koje treba dobiti odgovor je Kako često se namjerava mijenjati sadržaj stranice?. Naime, ako je to rijetko, primjerice nekoliko puta godišnje, ili još rjeđe, onda u načelu nije potrebno uzimati dinamične Web stranice (Web aplikacije) već se sve može riješiti statičnim Web stranicama. Prednosti tog pristupa su:

1. drastično ste smanjili mogućnost napada na stranice,
2. cijena izrade Web stranica, ali i njihovog smještaja, u takvim situacijama trebala bi biti značajno niža,
3. jednostavno je promijeniti tvrtku izvođača.
   

Nedostatak je da za svaku promjenu morate kontaktirati tvrtku koja Vam je napravila stranice što je u slučaju malog broja promjena zanemarivo, ali kako broj promjena raste tako to postaje sve veći problem (u smislu vremena potrebnog za izmjenu a slijedno tome i troška).
U svakom slučaju, ako ste se odlučili za statične Web stranice tada je na redu traženje izvođača što bi trebao biti rutinski posao te veći dio preostalog teksta ni ne morate čitati, tj. možete odmah preskočiti na poglavlje o održavanju.
Za kraj ovog poglavlja još ću pokušati ukratko objasniti što su statične Web stranice i koja je razlika u odnosu na dinamične Web stranice.  U suštini, svaka Web stranica koje gledate, uključivši i ovu, je u stvari tekst dokument koji opisuje kako će Vaš preglednik prikazati informacije na stranici. Možete vrlo jednostavno vidjeti sadržaj te datoteke tako pogledate njen izvorni kod (u Firefoxu to je Ctrl+U). U stvarnosti taj jedan tekst dokument referencira druge dokumente, i slike, ali to za nas u ovom trenutku nije bitno. Ono što je bitno je kako nastaje taj tekst dokument i to je ono po čemu se razlikuju statične i dinamične Web stranice. Ako je tekst dokument napravljen tijekom izrade cijelog Weba te potom pohranjen na disku i ne mijenja se bez intervencije čvojeka (koji će ga promijeniti i ponovo zapisati), tada govorimo o statičnim Web stranicama. Međutim, ako taj tekst dokument ne postoji na disku već se kreira u letu kada korisnik zatraži Web stranicu, tada govorimo o dinamičnim Web stranicama. To keiranje u letu obavlja program koji se naziva Web aplikacija, odnosno u ovom tekstu ćemo skraćeno govoriti i samo aplikacija.

Dinamične Web stranice
Dinamičke Web stranice, kao što je već rečeno, imaju veće mogućnosti ali zahtijevaju i više resursa za redovno održavanje. U prijevodu, više koštaju. Kao prvi korak u utvrđivanju odgovarajućeg rješenja trebali bi napraviti popis zahtijeva. Primjer nekih pitanja koja mogu pomoći u tom procesu su:

1. kome su sve namjenjene informacije koje će biti dostupne na Webu,
2. kakve sve informacije namjeravate objavljivati te da li ih namjeravate grupirati,
3. tko sve i kakva prava pristupa ima,
4. da li namjeravate obaviti povezivanje s internim bazama
   

U načelu, s popisom zahtijeva (uključivši i dizajn koji se ovdje ne spominje eksplicitno, ali se podrazumijeva) trebali bi sastaviti zahtijev za ponudama. Ponude koje pristignu grupirati ću u sljedeće kategorije:

1. Rješenja temeljena na aplikaciji iz vlastitog razvoja.
2. Rješenja temeljena na aplikaciji iz nečijeg tuđeg razvoja, ali bez dostupnog koda.
3. Rješenja temeljena na aplikaciji otvorenog koda.
4. Rješenja koja ne spominju koja aplikacija se koristi.
   

Iako bih u određenim situacijama podržao i 1. varijantu budući da sam pobornik razvoja a ne trgovine, ipak bih osobno preporučio varijantu 3 kao najbolju u gotovo svim slučajevima kada su Web aplikacije u pitanju. U nastavku ću pokušati obrazložiti zašto tu varijantu smatram najboljom:

1. Kvalitetan kod
   Aplikacije otvorenog koda su sigurno kvalitetnije pisane nego zatvorene aplikacije čiji kod ne možete vidjeti. Razlog je što kod otvorenih aplikacija mnoštvo ljudi stalno pregledava iz različitih motiva. Neki kako bi pronašli pogreške koje bi potom iskoristili za napade, drugi kako poboljšali kod, itd. Za razliku od otvorenog koda, kod zatvorenog koda česta karakteristika je da se moraju zadovoljiti neki (nerealni) rokovi zbog čega se u kod ugrađuje funkcionalnost koja nije dovoljno ispitana.
   
2. Kontinuirani razvoj
   Ako odaberete neku od aplikacija otvorenog koda (primjerice Mambo, Joomla, Plone, Drupal) možete biti sigurni da se te aplikacije stalno unaprijeđuju i dorađuju. Inače, Drupal se koristi i na whitehouse.gov stranicama.
   
3. Proširivost i mnoštvo mogućnosti
   Većina Web aplikacija napravljena je na takav način da je omogućeno proširivanje putem dodataka (plugins). Velika je vjerojatnost da za većinu potreba (čak i sve) već postoji razvijeno rješenje.
   
4. Niste ovisni o dobavljaču
   Ako niste zadovoljni s jednim dobavljačem jednostavno nađete novog dobavljača. Kod zatvorenih aplikacija to je puno teže budući da je potrebno prebacivati podatke iz jedne aplikacije u drugu, nekompatibilnu, aplikaciju pri čemu dobavljač od kojega odlazite ne mora biti nužno kooperativan.
   
5. Razvoj nije od nule
   Razvoj je skup, a pogotovo kvalitetan razvoj. U ta rješenja uložene su velike količine resursa i bilo koja tvrtka koja bi odlučila raditi alternativno rješenje (dakle, od nule) jednostavno nema nikakve šanse konkurirati postojećim proizvodima u pitanju kvalitete i podržanih mogućnosti.
   
6. Sigurnost
   Kod ovih aplikacija možete biti sigurni da ste dobro osigurani ako ste dobro riješili/dogovorili održavanje.

Dakle, sada možete postaviti pitanje zbog čega će uopće vanjska tvrtka kad već postoji gotovo rješenje. Vanjska tvrtka Vam je potrebna iz sljedećih razloga:

1. Prilagodba izgleda (design customization).
   Vrlo vjerojatno ponuđeni izgled Web aplikacije, kao i postojeće varijacije, neće zadovoljavati potrebe Vaše tvrtke te je Web aplikaciju potrebno uklopiti u vlastiti izgled. Za ovo je potrebno imati dizajnerskih vještina, ali moguće i programerskih.
2. Izrada novih dodataka.
   Određeni specifični zahtijevi možda nisu pokriveni postojećim dodacima (plugins) te u tom slučaju tražite tvrtku izvođača da vam razvije taj dodatak. Preporučio bih, ako je ikako moguće, da razvijeni kod opet bude otvorenog koda te da ga pošaljete za uključivanje u Web aplikaciju. S tim jamčite kvalitetu koda (neće biti uključen ako kvaliteta koda nije zadovoljavajuća), a kako se mijenja Web aplikacija drugi će se brinuti da Vaš dodatak i dalje radi! Ipak, ako to ne može biti javno objavljeno (jer je preosjetljivo ili neinteresantno drugima) tada barem osigurajte da ste vi vlasnik dodatka, a ne tvrtka koja ga je izradila!
3. Održavanje.
   Ovom temom se detaljnije bavim u idućem poglavlju.
   

Jasno kako postoje tvrtke koje imaju vlastite resurse s kojima mogu pokriti sva tri zahtijeva, ali takve tvrtke su vjerojatno vrlo rijetke i slobodno mogu zaključiti kako Vam je ipak potrebna vanjska tvrtka. Dodatni argument za vanjsku tvrtku je njeno iskustvo zbog čega će posao biti daleko brže i kvalitetnije odrađen.

Održavanje
Za kraj pozabavit ćemo se i s vrlo bitnom stavkom održavanja! Održavanje uključuje sljedeće elemente:

1. Smještaj stranica.
2. Održavanje Web aplikacije te operacijskog sustava i njegovih komponenti na kojima se izvršava aplikacija.
3. Sigurnosne kopije.
   

Smještaj stranica može biti na vlastitim poslužiteljima ili ih tvrtka koja Vam ih je napravila može negdje smjestiti. U principu, to je nebitno, iako, možda laganu prednost ima vlastito smještanje stranica budući da ste onda još nezavisniji od tvrtke dobavljača. Eventualno možete obratiti pozornost na sigurnost vanjskog poslužitelja na kojemu se smještaju stranice.
Održavanje uključuje sigurnosne nadogradnje te nadogradnje na novije verzije. To dvoje treba biti zasebno specificirano. Sigurnosne nadogradnje moraju se hitno izvoditi i uglavnom su minornog karaktera. Dakle, to bih svrstao u standardno održavanje. Promjena na novu verziju je posebna priča budući da se može desiti da su stara i nova verzija dovoljno različite da prijelaz nije trivijalan. U svakom slučaju, preporučio bih da se to svakako definira budući da svaka aplikacija ima ograničen vijek održavanja (bez obzira koliko dug) i nakon tog vremena više nema sigurnosnih nadogradnji što vas čini ranjivim!
Konačno, izrada sigurnosnih kopija (backups) je također bitna i to iz dva razloga. Prvi je u slučaju da se desi nekakva katastrofalna greška na poslužitelju možete ostati bez podataka. Drugi je da u slučaju promjene izvođača možete iz sigurnosnih kopija rekreirati sve Web stranice na novom poslužitelju.

Umjesto zaključka
Za kraj, preporučio bih da na vlastitim stranicama koristite Google Analytics, ili sličan alat. Naime, on Vam omogućava praćenje posjeta na Vaše stranice te na temelju njega možete otkriti što ljudi traže i što ih zanima kada su došli do Vas.