Viss sākās ar to, ka atnākot 5dien mājās atvēru pārlūkā savu blogu un tur man priekšā sagaidīja šāda bilde:

No sākuma cerēju, ka tas ir kaut kāds gļuks (naivi ne?) un atvēru administrēšanas paneli, bet tur tiešām kā pēdējais raksts rādījās “Hacked by n2n”.

Jocīgi bija arī tas, ka visi raksti kopš 2009. gada bija ievietoti “Trash”.

Pieņemu, ka nedarbs pastrādāts un brīnumdaris licis mani mierā, lēnā garā mēģinu saprast kas un kā.

Bet, kas tev deva- pēc aptuveni 1. minūtes pienāk epasts no wordpress- admin lietotājam nomainīts epasts un pieprasīta jauna parole.

Skaidrs tagad džekiņš jau mēģina tikt pie wordpress admin konsoles. Neko darīt- jābloķē viņam pieeja

No teorijas- ja vari kontrolēt ko tieši brīnumdaris (hacker) dara tavā lapā, serverī, utt, tas neapdraud draudu konfidencialitāti, integritāti, pieejamību, un ja tas palīdzēs viņu noķert, tad pieeju var riskēt saglabāt.

Ātri ielogojos hostera config panelī un aizliedzu piekļūt visam saturam (izņemot no manas IP).

Darīts- jāsāk skatīties kapēc tas varēja notikt-

Sāku tāpat, kā iepriekšējā rakstā par testa vides problēmām ar webalizer un awstat analīzi.

Skatos references:

pēdējā un svaigākā no pods.lv

Atveru pods.lv- tiešām pie pēdējiem komentāriem “Hacked by n2n”:

Cik sapratu, tas ir plugins, kas attēlo saistītos rakstus un tiklīdz manam rakstam nomainījās nosaukums, tas attēlojās iekš pods.lv.

Viltus trauksme ejam tālāk.

Kas mums ir ar apmeklējumu?

1 apmeklētās apskatījis- 408 lapas un uztaisījis 1507 hitus- uztaisītu noteikti vairāk, ja nepiegrieztu pieeju

Skatāmies, ko viņš ir vēris vaļā:

Tātad ievainojamība bija šajā failā.

Skatāmies vai varam sazīmēt ļauno IP adresi- varam 41.99.45.23. Google piedāvā izsmalcināti info par to.

Atveru wordpres.org un skatos vai nav konstatēta kļūda šinī failā un 2.9.2(pēdējā aktuālā uz to brīdi)- viss kārtībā, kļūda ir bet par to publika vēl nezin

Vairākos forumos (piemēram šinī) ir arī konstatēta šāda problēma, bet pagaidām bez atrisinājuma.

Atveru googli un mēģinu kaut ko sagooglēt.

Martā vienā lapā ir publicēts skaners, kas mēģina exploitēt arī šo failu.

Iespējams, ka pret mani tika pielietots tieši šis Vēlāk biju domājis paeksperimentēt ko viņš tieši dara, kā strādā un kādus rezultātus var iegūt, bet kaut kā vēl līdz šai dienai nav sanācis laiks.

Atšķirībā no iepriekšējā raksta “Hackeri uzbrūk“- šoreiz ir pieejami apache access logs.

Sākumā ar lielu entuziasmu, bet pēc tam ar apnicību gāju tam cauri. Tomēr neko sakarīgu atrast neizdevās.

Visu laiku viens un tas pats-

1) admin-ajax.php failam tiek veikts POST pieprasījums- ļoti žēļ, ka apacis nelogo POST pieprasījumus, tas uzreiz atviegloto manu darbu un dotu skaidru atbildi- ko īsti brīnumdaris tur darīja.

Pats nepārbaudīju, bet uz ātro atradu pamācību, kā iemācīt apacim logot POST datus. Daudzi cepjās- logs augs nejēgā un to visu saglabāt nebūs iespējams, protams, bet ir jau alternatīvas- glabājam īsāku laiku, kopējam uz citurieni, utt. Viss ir atkarīgs vai no šādas info ir jēga- uzlaušanas gadījumā ir.

2) atgriezts rezultāts, pēc tam tiek veikts mistisks GET- cik sapratu atkarībā no POST pieprasījuma rezultāta.

Kas tad beigās tika izdarīts?

• Veidojot mistiskos pieprasījumus http://dll.lv/wp-admin/admin-ajax.php failam brīnumdaris bija izdevies pārvietot lielu daļu rakstu uz trash.
• Viņa posts “Hacked by n2n”, nebija izveidots no jauna, bet vienam rakstam no 2009, gada tika nomainīts saturs un virsraksts.
• Tika izdzēsti visi tagi
• Beigās izdevās nomainīt admin lietotāja epastu un tādā veidā iegūstot admina paroli.

!!!AAA tiko ienāca prātā- vai tikai nebija ievietojis kādā no rakstiem javascript, kas nostrādāja, kad biju ielogojis admin sadaļā un tādā veidā nomainīja admin epasta adresi?

Par labu šai teorijai ir fakts, ka epastu nomainīja apmēram 2. minūtes pēc tam, kad mājās biju ielogojies administrēšanas sadaļā, kaut gan uzbrukums jau bija sācies 1h atpakaļ.

Varbūt sakritība. Bet pārbaudīt man to vairs neizdosies, jo visu iepriekšējo saturu jau esmu izdzēsis.

Secinājumi:

Kārtējo reizi apstiprinās- uzstādod pēdējo “drošo” versiju, neviens nav pasargāts tik un tā.

Uzhakos ne tikai Windows, bet arī ar wordpress..

Backup- tas ir spēks

Manas darbības pēc tam?

Viss kā pēc grāmatas-

Lādējam no wordpres.org wordpress un pluginus no jauna (jo pastāv iespēja, ka esošajā struktūrā ir izveidoti backdoor),

Izveidojam jaunu datubāzi

No rezerves kopijas paceļam pēdējo “drošo” DB versiju (izvēlējos nedēļu pirms uzbrukuma, jo man tā pat pa vidu bija tikai 1 posts.)

Šoreiz nevis vienkārši admin lietotājam uzstādam sarežģītu paroli, bet to izdzēšam.

Uzstādam jaunas paroles.

Meklējam rakstus par wordpress drošību (izrādās viņu ir pa pilno, piemēram šāds) un izpildām to norādījumus

Uzstādam wordpress plugin (http://wordpress.org/extend/plugins/wp-secure-by-sitesecuritymonitorcom/), kas palielina drošību.

Uzstādam plugin (http://wordpress.org/extend/plugins/threat-scan-plugin/) , kas pārbauda vai sistēmā nav kaut kas ieperinājies.

Esam nemitīgā stresā

Tā kā esmu jau aizmirsi, kas man tikai nestāv atveru FTP klientu, lai paskatītos direktoriju saturu.

Identificēju trīs izstrādes lapas, kuras jau ir nodotas un tātad tās var dzēst ārā. Tā kā miglaini atceros, kuras tās bija, tad ar lielu interesi ievadu pirmo:

http://dll.lv/test

Un mani sagaida brīnums

Neliels pārsteigums…

Pārējās lapās izmaiņas nav konstatētas un tās tiek izdzēstas

Gribu saprasta kas un kā.

Skatos failu struktūra vietā, bet ir parādījies jauns fails index.html (faila izveidošanas datums 17.03.2010- tāda vairāk kā mēnesi atpakaļ ), lai tas netraucētu gaisu pārsaucu par index.html1.

Skatāmies, kas notiek ar pašu joomla: Izskatās, ka arī datubāzi izdzēsis- atveru phpmyadmin un tiešām:

Paskatos joomla config failu:

Tas atbild uz jautājumu, kāpēc nav izdzēst viss pārējais- katrai testa sistēmai veidoju vienu  datubāzi un vienu lietotāju, kuram pieeja ir tikai konkrētai datubāzei. Izskatās, ka tas mani ir arī paglābis un brīnumdaris nenonesa pilnīgi visu.

Nav miera un gribu paskatīties dziļāk:

• Joomla logs izdzēsts ar visu datubāzi
• Skatos Apache access log-  ieraksti ir pieejami tikai par pēdējo mēnesi, un līdz 17. maijam vairs nesniedzas. Izmainu konfigurāciju, lai turpmāk visus vecos log failus saarhivē un saglabā (iespējams noderēs, bet ceru ka nē ).
• Skatos error_log- arī nekā.

Hosters piedāvā webalizer un awstat:

• No webalizer kādu sakarīgu info izdabūt neizdodas.
• Awstat-

1. no sākuma intresē, kā viņš ir mani uzgājis- pārbaudu meklētājos izmantotos keywords un keyphrases, par februāri un martu, bet nekā aizdomīga neatradu. Sagaidīju atrast kaut ko līdzīgu “joomla include “”", vai ko tamlīdzīgu.
2. Skatos, ko mēs varam sazīmēt saistībā ar IP adresēm- iegūstu IP adrešu sarakstu par martu un februāri, tomēr šis saraksts neuzrāda apmeklējuma dienu, līdz ar to nav īpaši noderīgs, ja vien netaisos pārbaudīt katru IP atsevišķi- ko es noteikti nedarīšu, jo tas ir pārāk laikietilpīgi (bet ja būtu noticis kas nozīmīgs, iespējams, arī būtu sācis pārbaudi).
3. Skatos apmeklētās lapas par februāri un martu- ir apmeklēta tikai http://dll.lv/test/, bet http://dll.lv/test/administrator nav apmeklēta. Dīvaini- jo biju izvirzījis hipotēzi, ka uzlaušana notika, jo administratora parole testa videi bija triviāla, bet ja administrēšanas lapa netika apmeklēta šis pieņēmums neapstiprinās.
4. Meklētās lapas, kuras netika atrastas vai atgrieza kļūdas paziņojumu- nekas interesants saistībā ar testa vidi, bet skatoties atklājās, ka kāds ir meklējis arī ievainojamības pašā blogā. Uz to norāda, piemēram šādi ieraksti:

///administrator/components/com_virtuemart/export.php
/wp-content%20%C2%BB%3Ca%20href=
/guestbook/public/paypal.fr/webscrcmd=_login-run/cgi-bin/login/Confirm.php
/_vti_bin/owssvr.dll
//path/authentication/phpbb3/phpbb3.functions.php
utt.

5. Skatos ārējos refferers un starp tiem aizdomīga ir tikai http://www.sa-hacker.com/vb/showthread.php.

Izskatās, ka esmu kaut ko uzķēris un droši veru lapu vaļā, bet ir aplauziens- viss ir arābu valodā un lai arī kaut ko redzētu ir nepieciešams reģistrēties. Reģistrācijai palīdz google tulkotājs, jo no tiem ķeburiem neko saprast nevar (ja kādam ir intrese par turieni paložņāt- user: zumzum, pass:zumzumzum, email:zumzum@spam.la). Izmeklējos par forumu, bet tomēr neko sakarīgu neatradu.

Kāds tad ir sausais atlikums?

Pēc analīzes secinu, ka ir izdzēsta datubāze, izveidots viens jauns fails, bet pārējā failu struktūra nav mainīta vai dzēsta.

Diemžēl nesanāca atklāt kādā veidā šis brīnums tika pastrādāts un līdz ar to neko prātīgu ieteikt neizdodas (iespējams bija novecojusi un bug -aina joomla vai tās komponente (tas gan mazticams, jo webalizer neuzrādīja apmeklētas kādas lapas, piemēram: dll.lv/test/component/crack.php?upload…) versija).

No šiem meistariem neesam pasargāti, bet, lai mazinātu to ietekmi:

• taisām backup
• katrai sistēmai izdalām savu DB un atsevišķu lietotāju, kuram nav piekļuve citām datubāzēm.
• saglabājam auditācijas pierakstus ilgāk..
• vienmēr uzstādam pēdējos drošības ielāpus
• ja ir iespēja uzstādīt papildus perimetra aizsardzību, piemēram, revers proxy
• ja gadījies kāds incidents, tad to iespēju robežās izmeklējam un izdarām secinājumus, nevis ignorējam un ceram, ka tas neatkārtosies.

PS.
Tagad laikam ir īstais brīdis pateikt ko es domāju par šiem brīnumdariem- neko labu.

Manās acīs tie ir visādi mūdži, kuri nodarbojas tikai ar savu ģenitāliju staipīšanu.
Cita lieta ir drošības speciālisti, kuri atklāj, konsultē un palīdz novērst (par naudu- protams) drošības ievainojamības vai ari hackeri, kuri iegūto informāciju izmanto ekonomisku labumu gūšanai, piemēram, izpirkuma maksas pieprasīšanai vai citas informācijas iegūšanai, ar kuru pēc tam operējot var uztaisīt skanošo- piemēram, kā ukraiņu hakers.

Bet vienkārši atrast lapu ar konkrētu ievainojamību, to izdzēst, nemaz neiedziļinoties kam tā pieder un kam tā kalpo?? Tas, manuprāt, ir zem jebkāda goda, kaut palasot pievienotās rindiņas index failam- šim cilvēkam no Palestīnas tāda nemaz nav bijis kopš dzimšanas:

I aM: A FrEe PaLeStIn!aN’s HaCK3eR

I DoN’t ApPeAr InTelLeGaNcE, BuT I AiM To DeStRoY InTeLlEgAnT

DoN’t ChAlLeNg A PeRsOn WhO HaS N0N To LoSe

PlAyInG WiTh Ch!LdReN DoSeN’t EnTeRtA!N Me

AdM!n DoN’t CrY….. CrY!Ng Is N0T A MaN’s ShArM

Diemžēl (kas mai vairāk intresē) netiek ziņots kādā veidā viņam izdevies tās iegūt.

Raksts no ABCnews.com

Want a great deal on a Facebook account? A Russian hacker who calls himself “kirllos” claims he can sell you 1,000 unsuspecting users’ login credentials for just $25, or $45 if the accounts have more than 10 friends each.
The hacker is believed to have stolen the IDs of 1.5 million Facebook users. If accurate, that means one out of every 300 Facebook users may have been victimized. Kirllos is selling the information on an underground hacker website, according to VeriSign’s iDefense Labs. The cybersecurity company estimates that kirllos has sold around 700,000 accounts so far, but VeriSign was unable to verify if any of the accounts are legitimate accounts belonging to real Facebook users.

Kirllos’ prices are incredibly cheap compared to other scams for sale. E-mail usernames and passwords usually fetch between $1 to $20 each, according to Symantec’s latest Internet Security Threat Report. In contrast, Kirllos is claiming he will sell accounts for as little as 25 cents each.

Raksts no DB.lv

Hakeris no Krievijas vārdā Kirllos ir nozadzis 1,5 milj. pasaules lielākā sociālā tīkla Facebook lietotāju paroļu, ziņo ABC News.

Tas nozīmē, ka par hakera upuri kļūs katrs trīssimtais Facebook lietotājs. Kopumā šajā sociālajā tīklā ir reģistrējušies vairāk nekā 400 milj. lietotāju.
Savukārt pēc Verisign’s idefense Labs informācijas, hakeris pārdod informāciju pagrīdes hakeru saitiem, un viņam jau esot izdevies pārdot aptuveni 700 tūkstošus paroļu.

Kirllos piedāvā paroles par zemāku cenu nekā citi. Šādi dati parasti maksā no viena līdz divdesmit ASV dolāriem, bet Kirllos tos piedāvājot par 25 centiem gabalā, taču paroles jāpērk vairumā.

Tomēr šodien izlasīju par vienu interesantu faktu, ka paralēli uzlauztiem epastiem tika nozagts arī googles lolojums Gaia, kas nodrošināja lietotāju autentifikāciju starp vairākiem googles projektiem (programmām).

Interesants šajā stāstā ir kādā veidā notika ielaušanās (zagšana)- Googles Ķīnas darbiniekam uz Microsoft Messenger tika atsūtīts links no ievainotas WEB vietas, uzklikšķinot uz tās tika nodrošināta hakeriem pieeja viņa un pēc tam arī citu googles koderu datoriem un pēc tam….

Par laimi (vismaz tā apgalvo), netika nozagtas pašas paroles, bet tikai mehānisms. Google gan pēc tam veica papildus uzlabojumus Gaia, lai nodrošinātu tā lielāku efektivitāti un stiprinātu drošību, bet tomēr iegūstot izejas kodu pastāv liela varbūtība, ka urķi tajā atradīs to, par ko programmētāji nebija padomājuši un tad….

Ko mēs no tā visa varam mācīties?

1. Kārtējo reizi apstiprinās, ka lielas kompānijas nav pasargātas no urķiem. Un milzīgi ieguldījumi drošībā- to negarantē (protams, samazina risku), jo vienmēr pastāvēs varbūtība, ka tā tiks uzlauzta 3 pušu ražotāja kļūdas pēc, piemēram Microsoft vai darbinieku glupības
2. Jāsāk nopietni uzmanīties ar googles pieejas parolēm un to drošību, jo izmantojot googles SSO (Gaia) risinājumam tikai ar vienu lietotāju un paroli var piekļūti visiem resursiem (google docs, gmail, analytics, adsense utt.)- kas arī man ir kļuvuši vitāli svarīgi.

Tai skaitā nepiekrītu apgalvojumam- ka uzlaužams ir viss- ja tā būtu tad mēs ne mūžam neuzticētos elektroniskām sistēmām un ibankas jau sen būtu vēsture. Tas, ka ik pa laikam izstrādātāji (programmētāji, analītiķi, utt) kaut ko neparedz vai aizmirst ir  jau ir cits jautājums..

Raksts no tvnet, kur gandrīz nav pateikts nekas, bet vismaz bija atsauce uz NY Times un raksta datumu, kur viss ir sīkāk aprakstīts.

http://www.tvnet.lv/tehnologijas/internets/327729-google_nozagta_parolu_sistema
Pagājušā gada decembra kiberuzbrukumos interneta giganta “Google” sistēmai nozagta lietotāju paroļu sistēma, otrdien ziņo “New York Times”.

“Līdz šim “Google” ir klusējusi par to, kas un cik daudz nozagts decembra kiberuzbrukumos,” atsaucoties uz anonīmu izmeklēšanā iesaistītu personu, raksta avīze.
Reklāma

Kompānijai nozagta viena no tās lielākajām vērtībām – paroļu sistēma, kas miljoniem lietotāju pasaulē ļauj piekļūt gandrīz visiem tīkla pakalpojumiem, arī elektroniskajam pastam un darījumu programmām, laikrakstam apgalvo anonīmā persona.

“Google” izstrādātā programma “Gaia”, kas nosaukta sengrieķu mitoloģijas zemes dievietes vārdā, ļāva tās lietotājiem ar vienu paroli piekļūt veselai virknei sistēmas piedāvāto pakalpojumu.

Pagājušā gada decembrī divas dienas pret “Google” sistēmu tika vērsti hakeru uzbrukumi. Pēc atklātās ielaušanās kompānija īstenojusi pasākumus sistēmas drošības uzlabošanai.

Hakeri nav nozaguši “Gmail” lietotāju paroles, piebilst laikraksts.

NY Times raksts

http://www.nytimes.com/2010/04/20/technology/20google.html?src=mv&ref=technology

Cyberattack on Google Said to Hit Password System
Ever since Google disclosed in January that Internet intruders had stolen information from its computers, the exact nature and extent of the theft has been a closely guarded company secret. But a person with direct knowledge of the investigation now says that the losses included one of Google’s crown jewels, a password system that controls access by millions of users worldwide to almost all of the company’s Web services, including e-mail and business applications.
The program, code named Gaia for the Greek goddess of the earth, was attacked in a lightning raid taking less than two days last December, the person said. Described publicly only once at a technical conference four years ago, the software is intended to enable users and employees to sign in with their password just once to operate a range of services.

The intruders do not appear to have stolen passwords of Gmail users, and the company quickly started making significant changes to the security of its networks after the intrusions. But the theft leaves open the possibility, however faint, that the intruders may find weaknesses that Google might not even be aware of, independent computer experts said.

The new details seem likely to increase the debate about the security and privacy of vast computing systems such as Google’s that now centralize the personal information of millions of individuals and businesses. Because vast amounts of digital information are stored in a cluster of computers, popularly referred to as “cloud” computing, a single breach can lead to disastrous losses.

The theft began with an instant message sent to a Google employee in China who was using Microsoft’s Messenger program, according to the person with knowledge of the internal inquiry, who spoke on the condition that he not be identified.

By clicking on a link and connecting to a “poisoned” Web site, the employee inadvertently permitted the intruders to gain access to his (or her) personal computer and then to the computers of a critical group of software developers at Google’s headquarters in Mountain View, Calif. Ultimately, the intruders were able to gain control of a software repository used by the development team.

The details surrounding the theft of the software have been a closely guarded secret by the company. Google first publicly disclosed the theft in a Jan. 12 posting on the company’s Web site, which stated that the company was changing its policy toward China in the wake of the theft of unidentified “intellectual property” and the apparent compromise of the e-mail accounts of two human rights advocates in China.

The accusations became a significant source of tension between the United States and China, leading Secretary of State Hillary Rodham Clinton to urge China to conduct a “transparent” inquiry into the attack. In March, after difficult discussions with the Chinese government, Google said it would move its mainland Chinese-language Web site and begin rerouting search queries to its Hong Kong-based site.

Company executives on Monday declined to comment about the new details of the case, saying they had dealt with the security issues raised by the theft of the company’s intellectual property in their initial statement in January.

Google executives have also said privately that the company had been far more transparent about the intrusions than any of the more than two dozen other companies that were compromised, the vast majority of which have not acknowledged the attacks.

Google continues to use the Gaia system, now known as Single Sign-On. Hours after announcing the intrusions, Google said it would activate a new layer of encryption for Gmail service. The company also tightened the security of its data centers and further secured the communications links between its services and the computers of its users.

Several technical experts said that because Google had quickly learned of the theft of the software, it was unclear what the consequences of the theft had been. One of the most alarming possibilities is that the attackers might have intended to insert a Trojan horse — a secret back door — into the Gaia program and install it in dozens of Google’s global data centers to establish clandestine entry points. But the independent security specialists emphasized that such an undertaking would have been remarkably difficult, particularly because Google’s security specialists had been alerted to the theft of the program.

However, having access to the original programmer’s instructions, or source code, could also provide technically skilled hackers with knowledge about subtle security vulnerabilities in the Gaia code that may have eluded Google’s engineers.

“If you can get to the software repository where the bugs are housed before they are patched, that’s the pot of gold at the end of the rainbow,” said George Kurtz, chief technology officer for McAfee Inc., a software security company that was one of the companies that analyzed the illicit software used in the intrusions at Google and at other companies last year.

Rodney Joffe, a vice president at Neustar, a developer of Internet infrastructure services, said, “It’s obviously a real issue if you can understand how the system works.” Understanding the algorithms on which the software is based might be of great value to an attacker looking for weak points in the system, he said.

When Google first announced the thefts, the company said it had evidence that the intrusions had come from China. The attacks have been traced to computers at two campuses in China, but investigators acknowledge that the true origin may have been concealed, a quintessential problem of cyberattacks.

Several people involved in the investigation of break-ins at more than two dozen other technology firms said that while there were similarities between the attacks on the companies, there were also significant differences, like the use of different types of software in intrusions. At one high-profile Silicon Valley company, investigators found evidence of intrusions going back more than two years, according to the person involved in Google’s inquiry.

In Google’s case, the intruders seemed to have precise intelligence about the names of the Gaia software developers, and they first tried to access their work computers and then used a set of sophisticated techniques to gain access to the repositories where the source code for the program was stored.

They then transferred the stolen software to computers owned by Rackspace, a Texas company that offers Web-hosting services, which had no knowledge of the transaction. It is not known where the software was sent from there. The intruders had access to an internal Google corporate directory known as Moma, which holds information about the work activities of each Google employee, and they may have used it to find specific employees.

Daudziem ir zināma drūmā statika par to cik procentuāli daudz projektu izgāžas, neizdodas vai vienkārši nesasniedz savu sākotnējo mērķi.
Savā pieredzē arī esmu saskāries ar neveiksmīgiem projektiem, kurus vienoja divas būtiskas lietas.
Ps. Šeit nepieskaršos projektu vadīšanas procesam , jo tas ir atkarīgs no konkrētā projekta tipa, lieluma, utt.

Bet ir viena kopēja lieta- Projekta mērķis.

Pirmā problēma- nepareizi nodefinēts projekta mērķis:
Projekta mērķis ir automatizēt vai uzlabot kādu procesu, palielināt konkurētspēju, utt, bet cik sanācis runāt ar projektos iesaistītām personām, tās uzskata, ka projekta mērķis bieži ir tikai ieviest kādu “IT sistēmu”.
Šeit jau arī rodas viena no pirmajām un būtiskākām kļūdām- sistēmas ieviešana nevar būt projekta mērķis, bet tikai kā projekta izvirzīto mērķa sasniegšanas risinājums, jo ieviešot sistēmu “ieviešanas pēc” var ne tikai nesasniegt sākotnēji gaidīto rezultātu, bet vēl pasliktināt jau esošo procesu.
Šāda problēma tiek novērota gadījumos, kad lielākā uzmanība tiek veltīta pašas sistēmas darbībai (cik fīčaina, kruta, moderna, utt tā būs), nevis organizācijas procesiem (kā cilvēki strādās ar šo sistēmu, cik efektīvi tas būs, kādā kvalitāte, kādas priekšrocības būs, cik ātri varēs strādāt, utt).

Otra problēma ir vienota izpratne par projektu:
Projektā iesaistītiem cilvēkiem bieži nav vienots viedoklis par projekta mērķi un sasniedzamiem rezultātiem.
Tas manuprāt ir otrs lielākais klupšanas akmens, jo nav iespējams nonākt pie laba rezultāta, ja iesaistītām personām ir dažāds redzējums par sagaidāmo sistēmu, tās prasībām un ieguvumiem.

Kāpēc tā notiek?
Manuprāt galvenokārt tāpēc, ka projektu vadītāji skatās pārāk šauri, koncentrējoties tikai uz pašu sistēmu.

Ko es ar to gribēju pateikt?

Neko jaunu. To visu var atrast jebkurā projektu vadības teorijā, bet tai pašā laikā apbrīnoju cik bieži tas netiek ņemts vērā. Un ja kāds izlasot šīs rindiņas aizdomāsies- tad būšu jau sasniedzis sev nosprausto uzdevumu.

Ps. Manuprāt, izvirzot pareizus, izmērāmus un visiem komandas biedriem zināmus projekta mērķus izdotos sasniegt daudz labākus rezultātus un izpaliktu lielā vilšanās, ka sistēma ir ieviesta, bet tā nedod sākotnēji iecerēto atdevi.

No visa iznāca divas galvenās atziņas:

• Ja auditors tiek iesaistīts projekta sākumā, tad var skatīties izmantoto metodoloģiju projektu vadībā un analizēt visu projektu vadības gaitu. Nepieciešamības gadījumā var norādīt uz vadīšanas vai plānošanas nepilnībām. Salīdzināšanai var izmantot angļu projektu vadības standartu PRINCE2(salīdzinot vai tiek izpildīti visi veiksmīga projekta priekšnosacījumi- Izpētīti ieguvumi, draudi, utt).
• Ja auditors tiek iesaistīts projekta beigās, tad vērtīgākais, ko var pārbaudīt un salīdzināt ir projekta sākumā definētos Busines-case ieguvumus ar reāliem, kas ir pēc projekta, tādā veidā pārbaudot vai projekts sasniedza tam izvirzītos mērķus. Otrs variants ir pārbaudīt nodefinēto prasību atbilstību izstrādātajai sistēmai, lai pārliecinātos, ka visas prasības ir izstrādātas.

Papildus tam projektu konsultēšanas laikā var palīdzēt izstrādāt dažādus kritērijus, pēc kuriem vadīties projekta laikā, tādā veidāatvieglot projektu vadītājam pieņemt lēmumu. Piemēram, kritēriji, kuriem jāizpildās, lai sistēmu varētu ieviest produkcijā(tai jābūt notestētai, veiktie stres testiem, drošības testiem, saņemta dokumentācija, utt) vai arī saņemtās lietotāju dokumentācijas kvalitātes un atbilstības analīze(to var salīdzināt pret LV standartu- LVS 66:1996), utt

Cits jautājums, vai šī analīze pēc tam tiek ņemta vērā..

Sākumā skaitļi- ap 84% IT projektu neiekļautās projekta sākumā nospraustajos termiņos un 56% neiekļaujas budžetā.
Tādēļ izrietošais domugrauds-
Projekta pirmie 90% no projekta laika paņem 90% no laika un atlikušie 10% paņem otrus 90%. Tom Cargali.
Otrs domugrauds-
Tu vienmēr zini pareizi, kas ir jādara. Grūtākais ir to izdarīt. H. Norman Schwarzkopf.

Tipiskākās problēmas IT projektos:

1. Ekonomiskā ietekme.
Izstrādājamais projekts nerada nekādu labumu(tb. ļauj strādāt efektīvāk, nesamazina darba apjomu, utt).
Izstrādājot projektus, izstrādes laikā mainās apstākļi(tiek atklātas jaunas tehnoloģijas, jaunas iespējas, konkurentu ražojumi, likumdošana, utt), kas radikāli maina projekta gala ieguvumu, kā rezultātā tas vairs nav aktuāls vai arī neradīs sākumā tam paredzēto pievienoto vērtību. Tas ir normāls process, tomēr lielākoties gadījumu šādi projekti tiek pabeigti pabeigšanas pēc, kaut arī to izstrādi jau vajadzēja apturēt vai modernizēt tiklīdz ir konstatētas izmaiņas. Tas viss noved pie rezultāta, ka ir izstrādāts produkts, kas nevienam nav vajadzīgs.

Uz katru IT projektu vajag skatīties, kā uz parastu investīciju, piemēram, ja projekta izmaksas ir 100000$, tad jāatbild uz jautājumu- vai tā īstenošana dos tik pat lielu atdevi nākotnē? Un ja projekta ieguvums ir niecīgs, tad varbūt izdevīgāk to summu noguldīt depozītā un iegūtie % maksājumu ir lielāki kā projekta pievienotā vērtība?
Tādēļ plānojot projektu ir jāaprēķina patiesie ieguvumi no sistēmas darbības- TEI(Total Economic Impact). http://www.forrester.com/TEI

Ieguvumi ieviešot projektu varētu būt piemēram:
Darbinieku laika ieguvums;
Darbību automatizēšana;
Produktivitātes palielināšana;
Apstrādājamo datu kvalitāte;
Papildus kontroles ieviešana;
Klientu apmierinātība;
Jauns produkts, utt

Daudzus ieguvumus aprēķināt matemātiski ir grūti, bet tomēr izdarāms, kā rezultātā var redzēt kopējo ieguvumu no projekta.

IT projektu izmaksas- TCO(totla cost of ownership) sastāv no trim daļām:
Ieviešanas izmaksas- izmaksas, kas saistītas ar iepirkšanu(programmatūras izstrādi, licenču iegādi, serveru iegādi, iesaistīto darbinieku algu, utt) un ieviešanu.
Operatīvās izmaksas- kuras nepieciešamas, lai nodrošinātu sistēmas funkcionēšanu(darbinieki, programmatūras atbalsts, tehnisko resursu uzturēšana, utt).
Sistēmas pilnveidošanas un izmaiņas- izmaksas, kuras ietver jaunu funkciju ieviešanas un pielāgošanu mainīgajām biznesa prasībām.

TCO aprēķinu tabula, kuru vajadzētu aizpildīt plānojot izmaksas un kas palīdzētu aprēķināt kopējās izmaksas:

Papildus var apskatīties Business Case framework- http://isaca.org/valit/

Izmaksas, kuras lielākoties neaizmirst iekļaut projekta budžetā ir programmatūras iegāde un datortehnikas iegāde.

Izmaksas, kuras bieži neņem vērā:
Ieviešanas izmaksas, izmaksas, kas saistītas ar sistēmas darbību un izmaksas, kuras būs nepieciešamas, lai sistēmu uzlabotu.

Daudzi izstrādātāji apgalvo, ka produkts ir pilnīgs un tam uzlabošana nebūs nepieciešama, bet tas neatbilst patiesībai, jo jebkura sistēma ir jāuzlabo, pretējā gadījumā sistēmu var uzskatīt par mirušu.(jo mainās biznesa prasības, jauni produkti, jauna likumdošana, nodokļu aprēķini, utt).

Lielākas izmaksas no projekta veido tieši darbinieku izmaksas, vienalga tas ir uzņēmuma vai piegādātāja darbinieks.

Tiek pieņemts, ka :
Izmaksas līdz projekta nodošanai ir 70% no kopējām izmaksām un 30% veido programmatūras attīstības izmaksas.
WEB projektos 2 gadu laikā tiek investēts 100% no izstrādes izmaksām, jo WEB vide ir pārāk mainīga.
Stabilām un nemainīgām sistēmām attīstības izmaksas ir 10% no izstrādes izmaksām..

Links uz otru daļu: http://dll.lv/it-projektu-problemas-2/

2. Ieviešanas(izstrādes) problēmas

Galvenā problēma ir projekta plānošana, vadīšana un prasību definēšana.
Joprojām projekti tiek pasūtīti prasībās norādot vispārējas lietas, kuru realizācijas redzējums ļoti atšķiras starp pasūtītāju un izstrādātāju.

Biežāk izstrādē lietotās ir Agile un ūdenskrituma metodes.

Lielākā kļūda izstrādājot ir mēģināt apvienot abas izstrādes metodes un izgudrot kaut ko pa vidam, jo abās metodēs ir iestrādātas pilnīgi cita ideoloģija, kā rezultātā sistēma tiek izstrādāta pēc ūdenskrituma modeļa, bet ar nenodefinētu specifikāciju.

Galvenās atšķirības starp metodēm:
Agile variantā sistēmas prasības tiek definētas un precizētas projekta izstrādes laikā, kā rezultātā sākuma līgums tiek slēgts par sistēmas izstrādi nenodefinējot neko speciālāku. Šādos līgumos lielākoties tiek atrunātas izstrādātāju darba stundas izmaksas, kas tiek pareizinātas ar patērēto laiku, jo sākumā laiku paredzēt nav iespējams. Šis laiks ir atkarīgs no mainīgo prasību daudzuma un izstrādājamās funkcionalitātes. Šādi līgumi ir grūti izstrādājami no juridiskās puses (nav nodefējams gala rezultāts).
Šādiem projektiem ir grūti veikt plānošanu, jo nevar paredzēt, kas būs jādara.
Vēl viena liela problēma izmantojot šo metodi ir kulturālās problēmas, jo, piemēram, grāmatvedis nebūs ar mieru, ka izstrādātājs viņu visu laiku tramda, bet izmantojot šo metodi ļoti svarīgi, lai biznesa cilvēki un izstrādātāji pēc iespējas vairāk pavadītu laiku kopā un diskutētu.
Agile nav piemērota sistēmām, kurām ir ekskluzīvas prasības, piemēram, pret drošību vai sistēmas darbības nepārtrauktību, utt.

Rezumē- gala rezultātā iegūs to, ko vēlas pasūtītājs, tomēr izmaksas nav paredzamas, tās var būt lielākas, kā sākumā paredzēts un var būt arī mazākas.

Izmantojot ūdenskrituma modeli ir iespēja, ka iegūtā sistēma nebūs tā, kura nepieciešama, jo:
prasībās ir aizmirsts kaut kas nodefinēt;
baidoties kaut ko aizmirst ir iekļauts viss un daudz kas lieks, kuru nemaz nevajadzēs.

Kā rezultātā tiek izstrādāts BMW, kaut biznesam būtu pieticis ar Opel.

Ir aprēķināts, ka daudzās sistēmās tiek lietots tikai 30% no iestrādātās funkcionalitātes.
Otrs variants, ka lielajos projektos, kur izstrāde ilgs gadu un vairāk, vienkārši nav iespējams paredzēt visas vajadzīgās lietas, jo laika gaitā prasības sistēmai mainās.

Lielākā atšķirība starp abām metodēm ir projekta vadīšanas stils, Agile metodē lielākoties projekta vadītājs, dokumentētājs un izstrādātājs ir apvienots vienā personā(vai viens, kas ļoti labi parzin visas lietas un spēj sekmīgi iesaistīties visos procesos), lai varētu veiksmīgi paredzēt izmaiņas. Kā rezultātā šāda projekta vadītāja atalgojums ir lielāks. Ūdenskrituma modelī, katrā izstrādes fāzē var tik iesaistīti citi cilvēki- prasību definētājs, programmētājs un testētājs.

3. Prasību neatbilstība vajadzībām.

To izraisa:
Komunikācijas problēmas,
Prasības netiek pārskatītas no biznesa viedokļa,
Mainīgā biznesa un apkārtējā vide.

Lai šo atrisinātu ir nepieciešama prasību vadība, kura nosaka, kuras prasības ir vajadzīgas, kuras tiek izstrādātas un kuras nē. Vēl tas ir vajadzīgs, lai varētu novelk strīpu un pateikt, ka papildus prasības netiks izstrādātas šajā etapā un pārējās tiks ieviestas jau projektu uzlabojot. Tas nodrošinās, lai prasības visu laiku netiek papildinātas un projekta nodošana netiek atlikta.

4. Izstrādātā sistēma nestrādā atbilstoši sākotnējām iecerēm.

Lielākā problēma ir testēšanā:
Jo ir aprēķināts, ka normālai testēšanai vajadzētu aizņemt 30% no izstrādes laika, bet tai tiek atlicināts pēc iespējas mazāk un, ja projekta izstrāde tiek iekavēta, tad uz NEtestēšanas rēķina produkts tiek nodots laikā.

Otra problēma testēšanā ir tā, ka netiek testēti ievadāmo datu robežgadījumi(piem, ievadīti dati ar negatīvu zīmi vai ar komatu, utt), kā rezultātā algoritms var nestrādāt kā vajag.

Svarīgs faktors ir vai biznesa puse ir iesaistīta gala testēšanā.
Kā izgāšanās piemēri tika minēti Nasas projektu problēmas, piemēram Marsa zonde, kas izšķīda pret Marsa virsmu, jo programmētājam lika uzprogrammēt, lai nosēšanās mehānisms nostrādātu 30 metrus virs Marsa virsmas, bet tas uzstādīja 30 pēdas.(Nasa izmantoja metrus, bet pārējā Amerika izmanto pēdas un collas) Kā rezultātā 125M $ izšķīst pret Marsa virsmu. Tā kā šādās kritiskās sistēmas tiek piesaistīti labākie speciālisti, kas vien ir pieejami par naudu , tad diez vai jūsu projektos būs labāki speciālisti…

5. Neviens vai tika daži izmanto šo produktu.

Daudzi projekti netiek vienkārši lietoti, piemēram izstrādātās elektroniskās dokumentu aprites sistēmas valsts iestādēs, bet darbinieki tik un tā drukā dokumentus, kā rezultātā nekāds ieguvums no šīs sistēmas nav. Tādēļ daudzos gadījumos ir nepieciešama vadības iejaukšanās un piespiešana darboties ar sistēmu.

Ieviestās CRM sistēmas, kuras darbinieki nelieto, jo tajās ir jāreģistrē savi kontakti un pieejamā informācija par klientu, kā rezultātā pārdošanas darbinieki zaudē lielāko no savām priekšrocībām- privātos kontaktus.

Vai arī sistēma tiek lietota tikai dažos departamentos, kā rezultātā, lai sazinātos ar pārējiem tiek lietotas tradicionālā papīra pieeja, kā rezultātā atdeves no sistēmas nav.

Iniciatīvu šīs problēmas novēršanā ir jāuzņemas vadībai, kurai ir arī jārēķina darbinieku laiks un efektivitāte.