Įsilaužimų ir saugumo testavimas
Išanalizuota
VšĮ Jonavos ligoninė (PV)
16 239,67 €
Atviras konkursasCPV: 72000000 - IT paslaugos: konsultavimas, programinės įrangos kūrimas, internetas ir aptarnavimo paslaugos
ID: 66538372026-02-25 17:29
Atidaryti CVP ISAprašymas
Perkančioji organizacija siekia įsigyti nepriklausomo saugumo testavimo (įsilaužimų testavimo) paslaugas. Šios paslaugos skirtos dviem naujai kuriamiems informacinių sistemų moduliams – elektroninių sutikimų formų sistemai ir dirbtinio intelekto konsultantui, diegiamiems trijose ligoninėse. Testavimo tikslas yra identifikuoti saugumo spragas ir konfigūracijos trūkumus, siekiant užtikrinti asmens sveikatos duomenų apsaugą prieš sistemų eksploatavimą.
Kvalifikaciniai reikalavimai
Kvalifikacinių reikalavimų nerasta
Techniniai reikalavimai
Paslaugų teikimo eiga
- 1Pasirengimo etapas pradedamas po Sutarties pasirašymo ir Perkančiajai organizacijai informavus Tiekėją, kad sistemos moduliai yra paruošti testavimui.
- 2Perkančioji organizacija (arba jos įgalioti sistemų kūrėjai) pateikia Tiekėjui: Mobiliosios aplikacijos diegimo failą (.apk) arba prieigą prie jos atsisiuntimo šaltinio, DI konsultanto internetinį adresą (URL), Testinių vartotojų prisijungimo duomenis (skirtingoms rolėms), Techninę dokumentaciją (API aprašus, sistemų architektūros schemas).
- 3Pilnas įsilaužimų testavimas atliekamas TIK VIENOJE pasirinktoje aplinkoje (pvz., Jonavos ligoninės sistemoje).
- 4Kitose dviejose aplinkose (Kretingos ir Biržų) atliekamas tik konfigūracijos auditas ir automatinis skenavimas.
- 5Testavimo metu aptikus kritinio lygio (Critical) spragą, Tiekėjas privalo nedelsiant (per 8 darbo valandas) informuoti Perkančiąją organizaciją.
- 6Pasibaigus aktyviajai testavimo fazei, Tiekėjas privalo pašalinti visus testavimo metu sukurtus artefaktus ir užtikrinti, kad sistemoje neliko jokių paliktų prieigų.
- 7Užbaigus testavimą, Tiekėjas parengia ir pateikia Pirminę saugumo vertinimo ataskaitą.
- 8Sistemų kūrėjams ištaisius klaidas, Tiekėjas privalo atlikti pakartotinį patikrinimą (Re-test), kurio tikslas – įsitikinti, kad anksčiau identifikuotos spragos yra tinkamai ištaisytos ir kad taisymo metu neatsirado naujų akivaizdžių saugumo problemų.
API sąsajų testavimas
- 1Abiejų modulių programų sąsajos (API) turi būti tikrinamos pagal OWASP API Security Top 10 sąrašą.
- 2Ypatingas dėmesys skiriamas duomenų atskleidimui per klaidų pranešimus, masiniam priskyrimui (angl. Mass Assignment) ir netinkamam vartotojų teisių valdymui.
Ataskaitų reikalavimai
- 1Tiekėjas privalo pateikti Pirminę saugumo vertinimo ataskaitą, kuri susidaro iš Vadovo santraukos (skirtos ne techniniam personalui) ir Detalios techninės dalies (skirtos programuotojams ir sistemų administratoriams).
- 2Vadovo santraukoje turi būti bendra sistemų saugumo būklės apžvalga, identifikuotų rizikų santrauka ir strateginės rekomendacijos saugumo gerinimui.
- 3Detali techninė dalis turi pateikti kiekvienam rastam pažeidžiamumui: pavadinimą ir tipą, kritiškumo lygį pagal CVSS v3.1 arba v4.0 balų sistemą, vietą, įrodymą (PoC), poveikį ir rekomendaciją (Remediation).
- 4Tiekėjas privalo pateikti Galutinę saugumo vertinimo ataskaitą, kurioje fiksuojamas faktinis saugumo lygis.
- 5Galutinėje ataskaitoje turi būti galutinė saugumo išvada ir spragų šalinimo statusas (pvz., „Ištaisyta“, „Dalinai ištaisyta“, „Neištaisyta“, „Rizika priimta“).
Pirkimo objekto aprašymas
- 1Perkančioji organizacija siekia įsigyti nepriklausomo saugumo testavimo (įsilaužimų testavimo / Penetration Testing) paslaugas dviem naujai kuriamiems informacinių sistemų moduliams.
- 2Paslaugų tikslas – identifikuoti saugumo spragas, konfigūracijos trūkumus bei verslo logikos klaidas ir pateikti rekomendacijas joms pašalinti, siekiant užtikrinti aukščiausią asmens sveikatos duomenų apsaugos lygį prieš pradedant eksploatuoti sistemas.
- 3Saugumo vertinimas atliekamas taikant „Pilkosios dėžės“ (Grey Box) metodą, vadovaujantis OWASP MASVS, OWASP Top 10 for LLM ir kitais nustatytais standartais.
- 4Paslaugų suteikimo laikotarpis turi būti ne ilgesnis kaip iki 2026-04-30.
Reikalavimai testavimo įrankiams
- 1Tiekėjas paslaugų teikimui privalo naudoti savo turimą techninę ir programinę įrangą.
- 2Naudojami įrankiai turi būti pripažinti rinkoje kaip industrijos standartas (komerciniai arba atviro kodo sprendimai, kurie yra reguliariai atnaujinami ir palaikomi).
- 3Privaloma naudoti statinės kodo analizės (SAST) įrankius (mobiliam moduliui), pvz.: Coverity, HCL AppScan Source, Checkmarx, SonarQube, MobSF arba lygiaverčius.
- 4Privaloma naudoti dinaminės analizės (DAST) ir perėmimo (Proxy) įrankius, pvz.: Netsparker (Invicti), Acunetix, HCL AppScan Standard, Burp Suite Professional arba lygiaverčius.
- 5Privaloma naudoti mobiliosios aplikacijos instrumentavimo įrankius, pvz.: Frida, Objection arba lygiaverčius.
- 6Privaloma naudoti DI (LLM) saugumo testavimo įrankius, pvz.: Giskard, Microsoft Counterfit, OWASP LLM AI Security & Governance Checklist priemonės arba lygiaverčius.
- 7Privaloma naudoti rankinius metodus verslo logikos klaidoms tikrinti.
Testavimo metodika ir apribojimai
- 1Testavimo metodas: „Pilkosios dėžės“ (angl. Grey Box).
- 2Testavimas privalo apimti tiek automatizuotą pažeidžiamumų skenavimą specializuotais įrankiais, tiek ekspertinį rankinį testavimą (angl. Manual Pentesting).
- 3Į paslaugos apimtį neįeina: Socialinės inžinerijos (angl. Phishing) atakos prieš įstaigų darbuotojus.
- 4Į paslaugos apimtį neįeina: Destruktyvios paslaugos trikdymo (DDoS) atakos, kurios galėtų ilgam sustabdyti ligoninės veiklą (leidžiamas tik aplikacijos atsparumo apkrovai tikrinimas kontroliuojamu būdu).
- 5Į paslaugos apimtį neįeina: Bandymai įsilaužti į kitas tame pačiame tinkle ar serverių infrastruktūroje esančias sistemas („kaimyninius“ serverius), kurios nėra tiesiogiai susijusios su testuojamais moduliais (Lateral Movement).
- 6Į paslaugos apimtį neįeina: Fizinis įsibrovimas į ligoninės patalpas.
Modulis B: Dirbtinio intelekto (DI) sprendimas
- 1Diegimo architektūra: Sprendimas diegiamas trijose atskirose aplinkose (po vieną kiekvienai ligoninei: Jonava, Kretinga, Biržai).
- 2Komponentai: Paciento sąsaja (viešas DI asistentas su VIISP autentifikacija) ir Personalo įrankis (integruotas modulis vidinėse ligoninių sistemose, skirtas realaus laiko vertimui balsu ir raštu).
- 3Administravimo posistemė: Atskira kiekvienai įstaigai.
- 4Pilnas saugumo testavimas atliekamas vienoje pasirinktoje instancijoje, o kitose dviejose atliekamas tik konfigūracijos auditas ir automatinis skenavimas.
DI konsultanto (Modulio B) testavimo reikalavimai
- 1Testavimas atliekamas atsižvelgiant į specifines dirbtinio intelekto sistemų rizikas, vadovaujantis OWASP Top 10 for LLM (Large Language Models) metodika.
- 2Manipuliacinės užklausos (angl. Prompt Injection): bandyti „apgauti“ DI modelį, naudojant specialiai suformuotas užklausas, siekiant priversti jį atskleisti sistemines instrukcijas, ignoruoti saugumo filtrus arba generuoti netinkamą turinį.
- 3Duomenų izoliacija ir nutekėjimas: patikrinti, ar DI modelis, naudodamas vidinius dokumentus (RAG metodas), neatskleidžia vienam vartotojui skirtos informacijos kitam vartotojui.
- 4Autorizacijos spragos (angl. IDOR): prisijungus su vieno paciento teisėmis (per VIISP), bandyti pasiekti kito paciento receptus, siuntimus ar asmens duomenis, manipuliuojant API užklausų parametrais.
- 5Paslaugos trikdymas (angl. DoS): įvertinti sistemos atsparumą resursams imlioms užklausoms, kurios galėtų sutrikdyti DI modelio veikimą ar išeikvoti nustatytus limitus.
- 6Garso ir vertimo saugumas: testuoti API sąsajas, perduodančias garso ir teksto duomenis vertimo varikliams, užtikrinant, kad duomenys nebuvo perimti ar modifikuoti (Man-in-the-Middle atakų simuliacija).
- 7SSRF per vertimo funkcijas: patikrinti, ar per personalo įrankį (kuris veikia vidiniame tinkle) neįmanoma pasiekti kitų vidinio tinklo resursų.
- 8Konfigūracijos palyginamumas (Configuration Review): įsitikinti, kad visos trys sistemos instancijos yra sukonfigūruotos identiškai saugiai.
Mobiliosios aplikacijos (Modulio A) testavimo reikalavimai
- 1Testavimas atliekamas vadovaujantis OWASP MASVS (Mobile Application Security Verification Standard) standarto reikalavimais, siekiant užtikrinti L1 (standartinis saugumas) ir R (atsparumas) lygius.
- 2Patikrinti, ar aplikacija nesaugo jautrių duomenų (biometrinių parašų, asmens kodų) atviru tekstu įrenginio failų sistemoje, duomenų bazėse ar žurnaluose.
- 3Įvertinti, ar biometriniai duomenys yra tinkamai šifruojami (naudojant asimetrinį šifravimą) ir ar privatūs raktai yra saugomi saugioje talpykloje (Android Keystore System).
- 4Patikrinti, ar aplikacija aptinka veikimą nesaugioje aplinkoje (pvz., „Root“ teisės, emuliatoriai) ir ar taiko priemones (angl. Tamper Detection), užkertančias kelią kodo modifikavimui.
- 5Patikrinti, ar sesijos tinkamai nutraukiamos vartotojui atsijungus arba pasibaigus laikui, ir ar nėra galimybės perimti sesiją.
Modulis A: Elektroninių sutikimų formų skaitmenizavimo ir pasirašymo sistema (ESFSPS)
- 1Sistemos tipas: Mobili aplikacija, skirta „Android“ operacinei sistemai, diegiama į planšetinius kompiuterius.
- 2Duomenų apdorojimas: Sistema renka ir apdoroja biometrinius parašo duomenis (spaudimo jėgą, greitį, koordinates), kurie turi būti šifruojami įrenginyje.
- 3Saugos priemonės: Aplikacijoje numatytas asimetrinis šifravimas bei apsaugos nuo veikimo „nulaužtuose“ (angl. rooted) įrenginiuose mechanizmai.
- 4Integracijos: Duomenų mainai vyksta su SPĮ IS („Varis“/ESIS) per REST/SOAP API sąsajas.
tendis.lt · Sukurta recodin.lt