Hankija täiendav seisukoht

Lp Ulvi Reimets Teie: 10.01.2025 Riigihangete vaidlustuskomisjon Tartu mnt 85, 10115 Tallinn Meie: 15.01.2025 nr 1.2-1/74-4 E-post: [email protected] Hankija: sihtasutus Põhja-Eesti Regionaalhaigla Registrikood 90006399 J. Sütiste tee 19, 13419 Tallinn Tel 617 1300 E-post [email protected] Hankija volitatud esindaja: Liisa Saamot Tel 617 3126 E-post [email protected] Vaidlustaja: ByteLife Solutions OÜ Registrikood 11179901 Toompuiestee 35, 10149 Tallinn Vaidlustaja esindaja: Vandeadvokaat Mart Parind Advokaadibüroo NOVE E-post [email protected] Kolmas isik: Security Software OÜ Registrikood 11924368 Veskiposti tn 2, 10138 Tallinn E-post: [email protected] Täiendav vastus vaidlustusele riigihankes "Küberturbeteenused ja platvorm 2" (viitenumber 271909) 1. Asjaolud 1.1. 21.06.2024 avaldas sihtasutus Põhja-Eesti Regionaalhaigla (edaspidi hankija) piiratud hankemenetlusena läbi viidava riigihanke „Küberturbeteenused ja platvorm 2“ viitenumbriga 271909 (edaspidi riigihange) hanketeate ja riigihanke alusdokumendid (edaspidi RHAD). 1.2. 30.12.2024 esitas vaidlustaja riigihangete vaidlustuskomisjonile (edaspidi VAKO) vaidlustuse hankija otsustele lükata tagasi vaidlustaja pakkumus, tunnistada edukaks 1/9  kolmanda isiku pakkumus ning kvalifitseerida ja jätta kõrvaldamata kolmanda isiku pakkumus (edaspidi vaidlustus). 1.3. Hankija edastas vaidlustaja vaidlustusele 06.01.2025 vastuse. 1.4. Vaidlustaja esitas 10.01.2025 hankija 06.01.2025 vastusele oma täiendavad seisukohad (edaspidi vaidlustaja täiendavad seisukohad), millele hankija esitab omakorda tähtaegselt vastuse. 1.5. Kuivõrd hankija vastus sisaldab vaidlustaja ärisaladust, siis vormistas hankija oma vastusest taas kaks versiooni – üks versioon on mõeldud VAKO-le ning vaidlustajale ja teine versioon kolmandale isikule. VAKO-le ning vaidlustajale mõeldud versioonis vastusest on ärisaladus märgitud sinise taustaga, kolmandale isikule mõeldud versioonis on ärisaladust sisaldavad kohad märgistatud tärnidega sinisel taustal ***. 2. Hankija täiendavad seisukohad 2.1. Tutvudes vaidlustaja täiendavate seisukohtadega, on hankija veendunud, et vaidlustaja, tuvastades, et ta on hankijale esitatud pakkumuses teinud kahetsusväärseid ning pöördumatuid vigu, püüab nüüd endale vaidlustuses meelepärase tulemuse saavutamiseks VAKO-t eksitada luues väära kuvandi justkui oleks riigihanke alusdokumendid hankija poolt niivõrd keeruliselt sõnastatud, et nii hankija ise kui ka teised pakkujad ei saanud aru, mida ja kuidas hankija hankida soovib. 2.2. Hankija lükkas vaidlustaja pakkumuse tagasi üksnes põhjendusel, et see ei vastanud riigihanke alusdokumentides kehtestatud nõuetele. Hankija eelistuste või soovidega mingi konkreetse hangitava platvormi osas ei ole vaidlustaja pakkumuse tagasilükkamine seotud. Samuti puudub vaidlustaja pakkumuse tagasi lükkamisel seos antud riigihanke „track record’iga“. 2.3. Riigihanke alusdokumendid on üheselt arusaadavad 2.3.1. Nagu vaidlustaja oma täiendavate seisukohtade p-s 12 õigesti viitas, nõuab RHS § 87 lg 1, et riigihanke tehniline kirjeldus peab hankelepingu eseme kirjeldamiseks vastavas valdkonnas tegutsevatele isikutele arusaadavat terminoloogiat ja täpsusastet kasutades määratlema asjade või teenuste hankelepingu esemeks olevate asjade või teenuste omaduste ja neile esitatavate nõuete loetelu. 2.3.2. Hankija poolt koostatud riigihanke tehniline kirjeldus vastab täielikult RHS § 87 lg-s 1 toodud nõudele. Kaks teist pakkujat peale vaidlustaja ehk vastavas valdkonnas tegutsevad isikud said hankija poolt riigihanke tehnilises kirjelduses toodud terminoloogiast ja täpsusastmest üheselt aru ning esitasid hankijale RHAD-ile vastavad pakkumused. Seega ei ole asjakohane vaidlustaja väide, mille kohaselt on hankija justkui üksnes enda eelisõiguse kohaselt riigihanke alusdokumente tõlgendanud (vt vaidlustaja täiendavate seisukohtade p-i 14). 2.3.3. Hankemenetluses lasub vaidlustajal kui pakkujal kõrgendatud hoolsuskohustus, mille realiseerimiseks pidi vaidlustaja enne pakkumuse esitamist veenduma, kas kõik riigihanke tehnilises kirjelduses esitatud mõisted ja nõuded on temale arusaadavad. Kui vaidlustaja leidis, et riigihanke tehniline kirjeldus on mõnes osas segadust tekitav, oleks vaidlustaja pidanud hankijalt küsima selgitusi segadust tekitava tingimuse ja/või mõiste kohta. Kui vaidlustaja otsustas seda mitte teha, siis ei vastuta hankija vaidlustaja poolse hoolsuskohustuse mittetäitmise eest. 2.3.4. Vaidlustaja suurendab teadlikult ning VAKO-t eksitada püüdvalt probleemi RHAD-is toodud mõistetega. Hankija ei õigusta siinjuures kuidagi hankija enda poolt 2/9  tehtud inimlikku eksimust, mis seisneb asjaolus, et hankija on tehnilise kirjelduse p-s 6.1. ekslikult küberturbe platvormi asemel nimetanud sõnapaari „inforturbe platvorm“. Küll aga ei saa sellest ühest inimlikust eksimusest tuletada vaidlustaja poolt tuletatud ebaõiget järeldust, justkui oleks hankija kogu riigihanke tehnilises kirjelduses pidanud silmas infoturbe platvormi küberturbe platvormi asemel. Tehnilises kirjelduses on kokku kahekümne kaheksal korral viidatud selgesõnaliselt mõistele „küberturbe platvorm“ või lihtsustatult „platvorm“ ning sellele esitatavatele tehnilistele nõuetele ja hinnastamispoliitikale – vt nt tehnilise kirjelduse tabel 2 ning tehnilise kirjelduse p-te 5, 6 ja 7. Teisisõnu, ühest inimliku eksitusena kasutatud mõistest „infoturbe platvorm“ ei saa teha ennatlikke ja mitte millelegi tuginevaid järeldusi kogu tehnilise kirjelduse ja ülejäänud RHAD-i osas. 2.4. Küberturbe platvorm ja häirekeskuse teenus 2.4.1. Hankija jääb täielikult oma 06.01.2025 toodud vastuses toodu juurde ning ei hakka oma seisukohti täies ulatuses kordama. Hankija peab vajalikuks enda poolt koostatud joonise näitel (lisa 1) ka illustreerivalt välja tuua, mida on hankija küberturbe platvormi ning häirekeskuse teenuse all riigihanke tehnilises kirjelduses kui ka tehnilises ettepanekus silmas pidanud ning millisel viisil soovib hankija neid RHAD-i kohaselt hankida. 2.4.2. Põhimõtteliselt saab küberturbe platvormi hankida mitmel viisil (sh ka täielikult pilveteenusena), kuid RHAD-i süvenedes saab vastava valdkonna spetsialist aru, kuidas on hange üles ehitatud ning millisel viisil soovis hankija küberturbe platvormi ning häirekeskuse teenust hankida. 2.4.3. Nii tehnilises kirjelduses kui ka tehnilises ettepanekus on küberturbe platvormina kirjeldatud üksnes XDR, EDR ning EPP komponente. Käesoleva vastuse lisas 1 toodud joonisel on küberturbe platvormi komponendid toodud esimeses kastis, mis on pealkirjastatud „TE-s1 kirjeldatud küberturbeplatvorm ja TK-s2 kirjeldatud PLATVORMINA“. Hankija selgitab veelkord, et küberturbe platvorm paigaldatakse hankija arvutitesse, osaliselt serveritesse ning küberturbe platvormi keskhaldust hangib hankija pilveteenusena (vt tehnilise ettepaneku p 4.1.). Hankija 06.01.2025 vastuse p-des 2.3., 2.4. ning 2.5. ja nende alapunktides on toodud konkreetsed viited tehnilises kirjelduses ning tehnilises ettepanekus toodud punktidele, mis kinnitavad hankija seisukohti, mille kohaselt hankija poolt hangitava küberturbe platvormi alla kuuluvad üksnes XDR, EDR ning EPP komponendid.3 2.4.4. Rahustuseks vaidlustaja täiendavate seisukohtade p-s 18 toodud vihjele võimaliku suunatud hanketingimuste osas selgitab hankija, et hankija poolt tehnilises kirjelduses ning tehnilises ettepanekus küberturbe platvormile kehtestatud XDR, EDR ning EPP nõuded on minimaalsed tingimused, mis pidid pakkujate poolt pakutaval küberturbe platvormil olema. Tegelikkuses võib erinevate ettevõtete poolt pakutavate küberturbe platvormide juurde kuuluvatel XDR, EDR ning EPP komponentidel olla väga palju teisi funktsionaalsusi, mida hankija ei pidanud vajalikuks pakkujatelt nõuda, et võimalikult paljud pakkujad saaksid pakkumuse esitada. Seetõttu on hankija tehnilises ettepanekus esitatud 1 tehnilises ettepanekus 2 tehnilises kirjelduses 3 *** 3/9  76-st XDR-i, EDR-i ning EPP-d komponente puudutavatest funktsionaalsuse nõuetest teinud pakkujatele kohustuslikuks vaid 27 (tehnilises ettepanekus märgitud „Tase I funktsionaalsus“, mille pakkujad pidid kindlasti täitma. 2.4.5. Tehnilise ettepaneku p-s 3 on sätestatud, et „Pakutav toode peab vähemalt vastama Tase I funktsionaalsusele. Hankija ei tunnista vastavaks pakkumust, mis ei vasta vähemalt Hankija märgitud Tase I funktsionaalsusele (tabelis tähistatud „*Tase I“).“ 2.4.6. Tehnilise ettepaneku p 2 sätestab, et: „Pakkuja täidab tabeli 1. märkides ära iga funktsionaalsuse litsenseerimise taseme.“ Kuivõrd tabelis 1 on „*Tase I“ litsenseerimise tasemed märgitud kohustuslikuks nii XDR-i, EDR-i kui ka EPP’d puudutavate komponentide osas, siis on ilmne, et nii XDR, EDR kui ka EPP komponendid peavad kuuluma vaidlustaja poolt pakutava küberturbe platvormi juurde, mis paigaldatakse hankija arvutitesse ning osaliselt serveritesse (välja arvatud küberturbe platvormi keskhaldus), kuivõrd vastasel juhul ei vajaks hankija XDR-i, EDR- ning EPP litsentside tasemeid. Küberturbe platvormi hinnastamine on kujundatud justnimelt litsentside tasemete hinna järgi (vt tehnilise kirjelduse p-i 5 ning selle alapunkte). Lisaks eeltoodule tuleneb tehnilise ettepaneku p-dest 4.1. ning 4.2. kohustuslike nõuetena, et küberturbe platvormi keskhaldus peab olema veebipõhine ja töötama SaaS mudelil /…/ („*Tase I“), mis tähendab seda, et vaidlustaja ei saa kuidagi väita, et *** on tema poolt pakutav primaarne platvorm. Hankija ei ole SIEM lahenduse osas nõudnud mingisugust konkreetset lahendust/platvormi ega nõudnud selle lahenduse litsentside tasemeid. 2.4.7. Kui küberturbe platvormi soovib hankija hankida hankija arvutitesse ning osaliselt serveritesse paigaldatavana (välja arvatud küberturbe platvormi keskhaldus), siis häirekeskuse teenust soovib hankija tehnilisest kirjeldusest nähtuvalt tervikuna teenusena. Hankija 06.01.2025 vastuse p-des 2.3., 2.4. ning 2.5. ja nende alapunktides on toodud konkreetsed viited tehnilises kirjelduses toodud punktidele, mis kinnitavad hankija seisukohti ning mille kohaselt soovis hankija häirekeskuse teenust (mille alla kuulub seireteenus, küberintsidentide vasteteenus ning kriitilise intsidendi lahendamise teenus) tervikuna hankida teenusena. Seireteenuse alla pidi pakkuja poolt teenusena kuuluma ka tehnilise kirjelduse p 2.4. kohaselt muu hulgas ka turbe teabe ja sündmuste haldus (edaspidi SIEM) teenusena (SaaS). 2.4.8. Käesolevale vastusele lisatud lisas 1 toodud joonisel on kõik hankija poolt riigihankes teenusena hangitavad komponendid toodud teises kastis, mis on pealkirjastatud „TK kirjeldatud teenusena“. Hankija ei ole tehnilises kirjelduses ega mujal RHAD-is esitanud mitte ühtegi nõuet selle kohta, milliste lahenduste või konkreetsete platvormidena pakkujad häirekeskuse teenust peavad pakkuma. Järelikult ei ole hankija jaoks oluline, milliste lahenduste või platvormidena pakkujad vastavat teenust pakuvad. Oluline oli hankija jaoks vaid see, et pakkujate poolt pakutavad lahendused vastaksid tehnilises kirjelduses häirekeskuse teenusele seatud nõuetele. Häirekeskuse teenuse hinnastamine on tehnilise kirjelduse p-s 5 toodu kohaselt kuupõhine, mitte litsentsipõhine nagu küberturbe platvormi puhul, sealhulgas häirekeskuse teenuse alla kuuluvat SIEM teenuse maksumust hinnastatakse veel eraldi logiallikate suuruse järgi. 2.4.9. Käesolevale vastusele lisatud lisas 1 toodud joonise kolmandas kastis, mis on pealkirjastatud „Vaidlustaja poolt riigihankes pakutud komponendid TK-s 4/9  kirjeldatud (TK-s punkt 2.4.) TEENUSE Vaidlustaja poolt riigihankes pakutud komponendid TK-s kirjeldatud (TK punkt 2.4.) TEENUSE osutamiseks, millele kehtivad muu hulgas TK punktides 2.5-2.13. toodud tingimused“ on toodud kõik vaidlustaja poolt häirekeskuse teenuse osutamiseks mõeldud komponendid, sh *** ning ***. Sellest järeldub, et vaidlustaja ei saanud kuidagi järeldada, et SIEM teenuse lahendusena vaidlustaja poolt pakutav *** täidab RHAD-i tähenduses küberturbe platvormi rolli. Seda enam, et vaidlustaja kinnitas tehnilise ettepaneku p-s 4.1., et tema poolt pakutav küberturbe platvormiks on ***. 2.5. Vaidlustaja poolt pakutud küberturbe platvormil *** puuduvad RHAD-is nõutud funktsionaalsused 2.5.1. Vaidlustaja poolt väidetu, mille kohaselt olevat hankija poolt *** müügijuhilt esitatud küsimused kontekstist välja rebitud, on asjakohatud. Nagu hankija poolt 06.01.2025 esitatud vastuse lisast 1 nähtub, soovis hankija ***’i müügijuhilt selgesõnaliselt vastuseid sellele, kas ***’i tootel on teatud funktsionaalsused olemas või mitte. 2.5.2. Vaidlust ei ole selles, et vaidlustaja tehnilise ettepaneku p-s 4.1. on vaidlustaja küberturbe platvormina nimetanud „***“. Hankija kontrollis justnimelt küberturbe platvormi „***“ vastavust RHAD-is esitatud nõuetele, kuivõrd vaidlustaja ei olnud küberturbe platvormina nimetanud lisaks ***’ile mingit muud lahendust, millega koostoimes täitnuks vaidlustaja hankes nõutud tingimused. Kui selline teadmine, et *** kui vaidlustaja poolt pakutav küberturbe platvorm täidab mõned tehnilises ettepanekus nõutud tingimused üksnes koostoimes mingisuguse teise vaidlustaja poolt pakutava lahendusega, eksisteeris vaid vaidlustaja enda peas, siis ei saanud hankija sellisest teadmisest kuidagi lähtuda. 2.5.3. Hankija on seisukohal, et vaidlustajal ei ole õigust vaidlustusmenetluse käigus esitada ***’i poolselt kinnitust, mis kinnitab, et vaidlustaja on ***’i toodete ametlik edasimüüja Eestis. Vaidlustaja soovib sisuliselt oma pakkumuses esitatud dokumente täiendada täiesti uute andmetega, mitte parandada või selgitada olemasolevaid. Kuivõrd tegemist ei olnud olukorraga, kus hankijal pidi tekkima põhjendatud kahtlus, et vaidlustaja poolt pakkumuses esitatud andmed on ebaselged või ebapiisavad (vt täiendavalt käesoleva vastuse p-i 2.5.2.),4 siis on tegemist vaidlustaja enda hoolsuskohustuse rikkumisega ning mistõttu kannab sellega seonduvat riski ja kaasnevaid tagajärgi vaidlustaja, mitte hankija. 2.5.4. Hankemenetluses lasub pakkujal kõrgendatud hoolsuskohustus, mille realiseerimiseks pidi vaidlustaja veenduma, kas kõik esitamisele kuulunud dokumendid said ka tegelikkuses esitatud ning kas nendes esitatud andmed vastavad RHAD-is nõutud tingimustele. Kui vaidustajale jäi mõni RHAD-is toodud tingimus ebaselgeks, pidanuks ta vajadusel hankijalt selgitusi küsima, seda vaidlustaja teinud ei ole. 2.5.5. Lisaks eeltoodule seab hankija kahtluse alla vaidlustaja täiendavate seisukohtade lisa 2 autentsuse, kuivõrd esitatud dokumendist ei selgu, millal ja kelle poolt see on allkirjastatud. Kui avada digitaalse allkirja „DocuSign“ detailandmete vaade, siis nähtub sealt, et „The signer’s identity is unknown.“ (eesti keeles: „Allkirjastaja isik on teadmata“ ning „The signing time is from the clock on the signer’s computer.“ (eesti keeles: „Allkirjastamise kellaaeg on sama mis 4 07.04.2014 Tallinna Halduskohtu otsus nr 3-14-50312, p 15 5/9  allkirjastaja arvutis olnud kellaaeg“), kuid allkirjastamise tegelikku kellaaega sealt ei nähtu. Eeltoodust tulenevalt palub hankija VAKO-l täiendavate seisukohtade lisa 2 tõendina mitte aktsepteerida. 2.5.6. Hankija seab samal põhjendusel kahtluse alla ka vaidlustaja täiendavate seisukohtade lisa 1 autentsuse, kuivõrd ka sellest dokumendist ei selgu, millal ja kelle poolt see on allkirjastatud. Kui avada digitaalse allkirja „DocuSign“ detailandmete vaade, siis nähtub sealt, et „The signer’s identity is unknown.“ (eesti keeles: „Allkirjastaja isik on teadmata“ ning „The signing time is from the clock on the signer’s computer.“ (eesti keeles: „Allkirjastamise kellaaeg on sama mis allkirjastaja arvutis olnud kellaaeg“), kuid allkirjastamise tegelikku kellaaega sealt ei nähtu. Eeltoodust tulenevalt palub hankija VAKO-l täiendavate seisukohtade lisa 1 tõendina mitte aktsepteerida. 2.5.7. Isegi, kui lähtuda eeldusest, et vaidlustaja täiendavate seisukohtade lisa 1 on autentne, millega hankija ei nõustu, ning vaidlustaja oleks tehnilises ettepanekus toonud lisaks ***’i küberturbe platvormile lisaks välja mingi muu lahenduse või platvormi, millega koostoimes täidaks ***’i küberturbe platvorm tehnilises ettepanekus esitatud nõuded, mida vaidlustaja faktiliselt teinud ei ole, siis ei vastaks ka vaidlustaja täiendavate seisukohtade lisana 1 esitatud täiendavate selgituste alusel tehnilise ettepaneku p-d 2.11., 2.12., 2.13., 2.20. ning 2.30. tehnilises ettepanekus toodud nõuetele ning seda järgmistel põhjendustel. 2.5.8. Pakkumuse tehnilise ettepanku vormi tabelis Tase I funktsionaalsustena märgitud punktis 2.11. „Analüüsitavate failide maksimaalset suurust on võimalik konfigureerida“. Vaidlustaja täiendavate seisukohtade lisas 1 toodud selgituste tõlge p 2.11. osas: „2.11 Lahendus võimaldab seadistada analüüsi maksimaalset failisuurust. –> Jah* *EDR-agendil on failisuuruse interaktsioonile pilveanalüütikaga seatud kindel ülempiir, mis on 4 GB. See katab enamiku klientide vajadustest, ohustamata ülejäänud EDR-platvormi tehisintellekti põhiseid ohuanalüüsi tegevusi.“ Hankija seisukoht: Vaidlustaja esitatud täiendavast selgitusest tuleb selgelt ja ühemõtteliselt välja, et vaidlustaja poolt pakutaval lahendusel on maksimaalne kindel ülempiir 4GB, mis tähendab, et analüüsitavate failide mahtu ei saa suurendada vastavalt hankijal tekkivatele tegelikele vajadustele, vaid analüüsitavate failide maksimaalne suurus on fikseeritud kindlale ülempiirile. Sellest järeldub, et tehnilise ettepaneku p-s 2.11. toodud nõue ei ole faktiliselt täidetud. 2.5.9. Pakkumuse tehnilise ettepanku vormi tabelis Tase I funktsionaalsustena märgitud punktis 2.12. „Arhiivifailide (pakitud, zip, rar jne) analüüsimine.“ Vaidlustaja täiendavate seisukohtade lisas 1 toodud selgituste tõlge p 2.12. osas: „2.12 Arhiivifailide (kokkupakitud ZIP, RAR jne) analüüs. –> Ei kohaldu - Jah alternatiivse meetodi abil* *Kaasaegsed EDR/XDR lahendused keskenduvad nii kasutajate identiteetide kui ka käivitatava koodi käitumismustritele. Staatilised, mitteaktiivsed andmed (näiteks arhiivifailides olevad andmed) loetakse vananenud andmesisenditeks, mida skannitakse vajadusel nõudmisel. Kui arhiivifailide sisu lahti pakitakse ja käivitatakse, analüüsitakse seda käivitamise ajal vastavalt rakendatud ennetuspoliitikale. Kokku pakitud failide sisu uurimist enne nende lahti pakkimist saab teha *** toodet kasutades. *** toetab arhiivifailide analüüsi kuni 7 tasandi 6/9  rekursiooniga. MDR-teenuse osana viib ***, sõltuvalt intsidendi tüübile ja asjakohastest artefaktidest, arhiivifailide analüüsi läbi teenuse osana vastavalt kokkulepitud tegevusreeglitele ja SLA-dele.“ Hankija seisukoht: Nagu *** enda selgitustest võib välja lugeda, konstateeritakse fakti, et *** ei skaneeri arhiivifaile ning ta skaneerib nende sisu faile vaid juhul, kui arhiiv lahti pakitakse ning arhiivi sees olev fail käivitatakse. Arhiivifailide skaneerimiseks on vajalik lisatoodet, milleks on ***. Tehnilises ettepanekus pidi vaidlustaja vastama “Jah” või “Ei” vastustega ehk antud juhul, kas vaidlustaja poolt pakutud küberturbe platvormil on arhiivifailide analüüsimise funktsioon või mitte. On fakt, et vaidlustaja poolt tehnilise ettepaneku p-s 1 küberturbe platvormina märgitud *** ei täida tehnilise ettepaneku p-s 2.12. toodud nõuet arhiivifailide analüüsimiseks. Kui vaidlustaja nägi ette täiendavate tarkvarade või lahenduste pakkumist, mille kaudu ta soovis kõiki küberturbe platvormi funktsionaalsuseid täita, siis oleks pidanud kõik need lahendused, tarkvarad või platvormid tehnilise ettepaneku punktis 1 lisaks ***’ile üles loetlema. 2.5.10. Pakkumuse tehnilise ettepanku vormi tabelis Tase I funktsionaalsustena märgitud punktis 2.13. „Arhiivifailidele on võimalik määrata pakkimistasemete piirang.“ Vaidlustaja täiendavate seisukohtade lisas 1 toodud selgituste tõlge p 2.13. osas: „2.13 On võimalik seadistada arhiivifailide pakkimistaseme piiranguid.“ Hankija seisukoht: *** ei täida nõuet pakkimistasemete piirangute seadmisel, kuna tal puudub arhiivifailide skaneerimise funktsioon (vt käesoleva vastuse p-i 2.5.9.). 2.5.11. Pakkumuse tehnilise ettepanku vormi tabelis Tase I funktsionaalsustena märgitud punktis 2.20. „Tulemüüril on võimekus tuvastada ja blokeerida skanneeringuid (OS fingerprinting, null scan, SYN FIN scan, port scan jne).“ Vaidlustaja täiendavate seisukohtade lisas 1 toodud selgituste tõlge p 2.20. osas: „2.20 Tulemüür suudab tuvastada ja blokeerida skaneeringuid (OS-i tuvastamine, null-skaneering, SYN, FIN skaneering, pordiskaneering jne). –> JAH. *** kasutab operatsioonisüsteemi sisseehitatud tulemüüri, mistõttu on sellel samad võimalused kui vastaval tarkvaratulemüüri versioonil, mis töötab hostarvutis (Windows, Mac või Linux). See hõlmab ka skaneeringute tuvastamise võimet. Lisaks sisaldavad dünaamiliselt uuendatavad Threat Hunting’i käsiraamatud tulemüüri telemeetriat, mis on sensori standardfunktsioonina saadaval. *** võib soovitada spetsiaalset riistvaralist võrgu turvaseadet, mis paigaldatakse perimeetrisse ja kaitseb vastavat võrku süvapakettide inspekteerimise (Deep Packet Inspection) tehnoloogiate abil ning pakub tulemüüriteenuseid OSI-mudeli füüsilisest kihist (kiht 1) kuni andmekihini (kiht 7).”. Hankija seisukoht: Vaidlustaja täiendavate seisukohtade lisast 1 selgub, et tema poolt pakutaval *** küberturbe platvormil endal ei ole tulemüüri funktsionaalsust, vaid see küberturbe platvorm kasutab hankijal olemasolevaid operatsioonisüsteemi sisseehitatud tulemüüri funktsionaalsusi tulemüüri funktsioonide täitmiseks, kui need on olemas. Hankija ei ole tehnilises ettepanekus küsinud hankijal olemasoleva võimaliku operatsioonisüsteemi tulemüüri halduse funktsionaalsust, vaid tulemüüri olemasolu pakutaval küberturbe platvormil. Tulemüüri halduse funktsionaalsus tähendab, et küberturbe platvormil on eeldus, et kõikides operatsioonisüsteemides, mida hankija kasutab, on olemas ja on 7/9  võimalik operatsioonisüsteemi sisene tulemüür aktiveerida. Kuna hankija kõikides operatsioonisüsteemides ei pruugi olla võimalik hankijal olemasolevat tulemüüri sisse lülitada, on hankija just seetõttu kehtestanud nõude, et pakutaval küberturbe platvormil endal peab olema tulemüüri funktsionaalsus. Sellest järeldub, et tehnilise ettepaneku p-s 2.20. toodud nõue ei ole täidetud. 2.5.12. Pakkumuse tehnilise ettepanku vormi tabelis Tase I funktsionaalsustena märgitud punktis 2.30. „Lahendus võimaldab teostada toetatud operatsioonisüsteemides käivitatavate (executable) failide rakenduskontrolli, /…/“. Vaidlustaja täiendavate seisukohtade lisas 1 toodud selgituste tõlge p 2.30. osas: „2.30 Lahendus võimaldab käivitatavate failide rakenduste juhtimist toetatud operatsioonisüsteemides, sealhulgas: –> JAH*  luua käivitatavate failide valge- ja mustanimekirju –> ennetuspoliitikate raames (oob).  lubada rakenduste juhtimist õppimisrežiimis, mille käigus lahendus koostab ja soovitab automaatset valgenimekirja –> tehisintellekti analüüsi mudeli raames, mis määratleb, millised rakendused võivad olla haavatavad, kooskõlas poliitikate piirangutega.  seadistada rakenduste juhtimist tsentraalselt ja programmeeritava liidese (API) kaudu –> JAH, vastavalt *** tingimustele.  Faile saab lisada valge- või musta nimekirja järgmiste kriteeriumide alusel: räsi, faili nimi, faili asukoht või tarkvara digitaalselt allkirjastatud sertifikaat. –> JAH  Alternatiivselt, kui on vajalik sisseehitatud rakenduste juhtimine, pakub *** teenuste lisandmoodul (millel on ühesuunaline integreerimine *** juhtpaneeliga) vertikaalset rakenduste juhtimise lahendust. See lisaosa annab täiendavad selgitused konkreetsete hanke nõuete kohta, tagades selge arusaama sellest, kuidas pakutud lahendus vastab esitatud nõuetele.”. Hankija seisukoht: Nagu nõudes kirjas kehtib nõue kõikide käivitatavate failide osas sh inglise keeles “native application” juhtimiseks, mitte ainult tuvastatud pahavara failide blokeerimist. Kõikide käivitatavate failide osas peab olema võimalik luua valg- ja mustnimistu. Ennetuspoliitika rakendamine ei käsitle kõiki käivitatavaid faile, vaid ainult neid, mis on varasemalt ohtlikuna tuvastatud või märgitud. Ennetuspoliitika kasutamisel ei saa kasutada valgnimistu poliitikat, kus kõik käivitatavad failid, mis pole spetsiaalselt lubatud, on vaikimisi blokeeritud. *** enda selgitustes on kirjas, et kõikide käivitatavate failide ehk hankija nõutud tasemel rakenduskontrolli on võimalik teostada, kuid selleks on vaja kolmanda osapoole tarkvara “ ***” mida vaidlustaja ei ole oma pakkumuses nimetanud. Sellest järeldub, et tehnilise ettepaneku p-s 2.30. toodud nõue ei ole täidetud, tehnilise ettepaneku punktis 2.30. nõutud funktsionaalsuste täitmiseks peab *** platvormile lisaks olema ka *** platvorm, mida vaidlustaja hankes ei pakkunud ega lisanud ka ühtegi viidet, mille kaudu hankijal oleks võimalik olnud tuvastada, et vaidlustaja pakub lisaks ka *** platvormi. 2.6. Osutatava teenuse töökeel 2.6.1. Tehnilise kirjelduse punktide 2.1., 3.5. ja 4.1. kohaselt peab pakkuja osutama teenuseid 24/7 (kaasa arvatud nädalavahetused ja riigipühad). Kui lähtuda eeldusest, et ühes aastas on 365 päeva, siis peab pakkuja olema valmis osutama 8/9  teenust kokku ühes aastas vähemalt 8760 tundi. 2.6.2. Hankija soovib oma vastust täiendada asjaoluga, et vaidlustaja vaidlustuses (vt järgmist punkti) esitatud seisukoht ei ole realistlik ainuüksi seetõttu, et kui lähtuda Eesti Vabariigis kehtivast töölepingu seadusest, siis üks inimene võib ühes aastas töötada orienteeruvalt 1952 tundi, kaks inimest seega orienteeruvalt 3904 tundi. Kahe inimese ühe aasta jooksul lubatud töötundide suurus ei kata ära isegi 50% nende tundide arvust, mida pakkuja peab olema valmis hankijale ühe aasta jooksul minimaalselt osutama. 2.6.3. Vaidlustaja väidab nimelt vaidlustuses, et kaks isikut, s.o *** ja ***, kelle emakeeleks on eesti keel, katavad ära suurema kui mitte kogu eestikeelse suhtluse vajaduse ning et ülejäänud tiimiliikmed on mõeldud peaasjalikult tegelema tehniliste raportite ja sündmuste teavitusega. Lugupidamisega /allkirjastatud digitaalselt/ Liisa Saamot hankija volitatud esindaja Lisa: 1) *** 9/9