ტენდერის აღწერილობა:

სს „ლიბერთი ბანკი“  აცხადებს ღია ელექტრონულ ტენდერს Endpoint უსაფრთხოების გადაწყვეტისშესაძენად, რომელიც უზრუნველყოფს Endpoint/Server დაცვის, აღმოჩენის, გამოძიებისა დარეაგირების (EDR) ფუნქციებს და საჭიროების შემთხვევაში EPP შესაძლებლობებს. გადაწყვეტაუნდა იყოს მასშტაბირებადი, მართვადი ერთიანი კონსოლიდან და თავსებადი ჩვენს გარემოსთან(Windows/Mac/Linux/კონტეინერები).

2) მოცულობა და ლიცენზირება:

• გადაწყვეტა უნდა მოიცავდეს ლიცენზიას მინ. 5500 აქტივის (endpoint + server) დასაცავად 1 წლის განმავლობაში (12 თვე).
• ლიცენზირების მოდელი უნდა იყოს მკაფიოდ აღწერილი (endpoint/server განსხვავება, აქტივების ტიპები, დამატებითი მოდულები, telemetry retention და სხვ.).
• სასურველია, რომ ფუნქციონალი (EDR/EPP) იყოს ერთიანი აგენტის ფარგლებში,

3) ბაზრის რეპუტაცია და დამოუკიდებელი შეფასებები (არასავალდებულო/სავალდებულო):

შენიშვნა: ქვემოთ ჩამოთვლილი პუნქტები მიზნად ისახავს გადაწყვეტილების ხარისხისდადასტურებას და არ უნდა ზღუდავდეს კონკურენციას კონკრეტულ ბრენდზე.

• სასურველია, რომ ვენდორი/პროდუქტი იყოს წარმოდგენილი დამოუკიდებელ ანალიტიკურანგარიშებში Endpoint Security მიმართულებით (მაგ.: Gartner, Forrester, IDC ან სხვაეკვივალენტური ავტორიტეტული წყარო).
• სასურველია, რომ გადაწყვეტა მონაწილეობდეს MITRE ATT&CK Evaluations (ან სხვაეკვივალენტურ საჯარო ტესტირებებში) და წარადგინოს შესაბამისი შედეგები/რეფერენსი.

4) არქიტექტურა, ადმინისტრირება და წვდომების მართვა:

• გადაწყვეტა უნდა უზრუნველყოფდეს RBAC (Role-Based Access Control) და მოქნილ როლების/უფლებების კონფიგურაციას (მათ შორის პერსონალიზებული როლები).
• ყველა ადმინისტრატორის/მომხმარებლისთვის უნდა იყოს მხარდაჭერილიმრავალფაქტორიანი ავთენტიკაცია (MFA/2FA).
• მართვის კონსოლში უნდა არსებობდეს მრავალდონიანი იერარქია/ტენანტური ან მრავალ-ორგანიზაციული ლოგიკა (მაგ.: global → region → group → subgroup) და პოლიტიკებისმემკვიდრეობითობა.
• მოწყობილობების დინამიური დაჯგუფება უნდა იყოს შესაძლებელი label/attribute-ებისმიხედვით (OS, ჰოსტ-ტიპი, ვერსია, IP, AD ატრიბუტები და სხვ.) Windows/Mac/Linux/კონტეინერებისთვის.
• პოლიტიკის ცვლილებების გავრცელება endpoint-ზე/ჯგუფზე უნდა ხდებოდეს ოპერატიულად(მაგ.: 60 წამამდე — სასურველია; ვენდორმა მიუთითოს SLA/რეალური პრაქტიკა).
• აგენტის გადატანა ერთ ჯგუფიდან/ჰიერარქიის დონიდან მეორეზე უნდა იყოს შესაძლებელიარაინსტალაციის/დეზინსტალაციის გარეშე (სასურველია).
• უნდა არსებობდეს შესაძლებლობა აგენტის გარკვეული ფუნქციონალის დროებით გამორთვის/შეჩერების კონსოლიდან თავსებადობის საკითხების გამოსასწორებლად (audit trail-ისშენარჩუნებით).

5) ლოგირება, აუდიტი და SIEM ინტეგრაცია:

• გადაწყვეტამ უნდა უზრუნველყოს ადმინისტრაციული ქმედებების აუდიტ-ლოგი (ვინ/რა/როდის) და მისი წაშლის/შეცვლის აკრძალვა (tamper-proof).
• უნდა არსებობდეს Syslog forwarding მოქნილი კონფიგურაციით (threat detection, response actions, remote sessions, configuration changes, audit logs და სხვ.).
• Syslog/ექსპორტის მხარდაჭერა სასურველია სტანდარტულ ფორმატებში, მათ შორის: CEF (ანეკვივალენტური), RFC-5424, და სხვა გავრცელებული ფორმატები.
• სასურველია - მხარდაჭერა ქონდეს  TLS/SSL დაშიფვრას და სერტიფიკატებითავთენტიკაციას
• ვენდორმა უნდა აღწეროს ინტეგრაცია SIEM-ებთან (მაგ.: Elastic, Splunk, QRadar, Sentinel ანსხვა), ასევე რა მონაცემები/ვერდიქტები გადის.

6) ინვენტარიზაცია, რეპორტინგი და ოპერაციული ფუნქციები:

• გადაწყვეტამ უნდა უზრუნველყოს აქტივების ინვენტარიზაცია მინიმუმ OS ტიპით დამოწყობილობის კატეგორიით. სასურველია - ასევე დაინახოს დაინსტალირებულიაპლიკაციები.
• უნდა იყოს მხარდაჭერილი ფილტრების/ქუერების შექმნა ჰოსტების სტატუსისვიზუალიზაციისთვის.
• რეპორტინგი: on-demand და scheduled რეპორტები PDF ან HTML ფორმატში; პერიოდებისარჩევა მინ. 1 თვემდე; რეპორტების გაგზავნა ელფოსტით.
• აგენტების განახლება უნდა ხდებოდეს დისტანციურად (on-demand ან დაგეგმილად).
• კონსოლმა უნდა შეძლოს „inactive agent“ პოლიტიკის მართვა (რამდენ ხანში ჩაითვალოსარააქტიურად, auto-cleanup/auto-delete წესები — სურვილისამებრ, კონფიგურირებადი).

7) პლატფორმების მხარდაჭერა (OS/კონტეინერები/პროქსი):

აუცილებელი მოთხოვნა: ვენდორმა უნდა დაადასტუროს მხარდაჭერა მინიმუმ:

• Windows (workstation და server) — ორგანიზაციაში გავრცელებული ვერსიებისთვის (ვენდორმაჩამოთვალოს ზუსტად მხარდაჭერილი ვერსიები/edition-ები).
• Legacy OS - მოძველებული ოპერაციული სისტემების მხარდაჭერა
• Linux — ძირითადი დისტრიბუციები (RHEL/Ubuntu/Debian/SUSE ან ეკვივალენტური) შესაბამისივერსიებით.
• macOS — ბოლო ვერსიები და ფართოდ გამოყენებადი წინა ვერსიები.
• Container/Kubernetes გარემო (Docker/Containerd/CRI-O; Kubernetes/OpenShift/Cloud managed K8s) — თუ არსებობს ასეთი გარემო.
• აგენტებმა უნდა შეძლონ მუშაობა proxy სერვერის გავლით ავთენტიკაციით (თუ ქსელურიპოლიტიკა მოითხოვს).

8) თავდასხმების პრევენცია და აღმოჩენა (EPP/EDR):

• გადაწყვეტამ უნდა უზრუნველყოს malware/unknown malware/ransomware/fileless/exploit/lateral movement ტიპის საფრთხეების აღმოჩენა და ბლოკირება.
• სასურველია behavior-based/ML მიდგომები და არა მხოლოდ სიგნატურებზე დაყრდნობით(ვანდორმა აღწეროს გამოყენებული მეთოდოლოგია).
• უნდა არსებობდეს თავდასხმის ტიპის ავტომატური კლასიფიკაცია (მაგ.: ransomware, trojan, stealer, backdoor და სხვ. — ეკვივალენტური).
• აგენტი უნდა ინარჩუნებდეს კრიტიკულ შესაძლებლობებს offline რეჟიმშიც (მინიმუმ: პრევენცია/აღმოჩენა/ლოგების ბუფერირება და კონსოლთან აღდგენის შემდეგ სინქრონიზაცია).
• უნდა არსებობდეს initial scan (სრული ან რეკომენდირებული) ინსტალაციის შემდეგ; ასევე on-demand scan endpoint user-ის ან ადმინისტრატორის მხრიდან (პოლიტიკით მართვადი).
• Incident Response actions მინიმუმ:
• Host isolation (network quarantine)
• Quarantine file / artifact
• Terminate process
• Artifact removal/remediation
• ყველა რეაგირების ქმედება უნდა აისახოს აუდიტში (ვინ/რა/როდის/შედეგი).
• remote shell/remote session შესაძლებლობა (PowerShell/Bash) უსაფრთხოების კონტროლებითადა დაშიფვრით (ვენდორმა აღწეროს კონტროლები, logging, approvals).

9) Telemetry, Threat Hunting და Retention:

• გადაწყვეტამ უნდა უზრუნველყოს Endpoint-ებიდან უსაფრთხოებისათვის მნიშვნელოვანი ტელემეტრიის შეგროვება, მათ შორის პროცესებთან, ფაილებთან, ქსელურ აქტივობასთან და სისტემურ ცვლილებებთან დაკავშირებული მოვლენები. 

• ვენდორმა წინადადებაში უნდა აღწეროს, რა ტიპის ტელემეტრია გროვდება და რა მოცულობით არის ხელმისაწვდომი ანალიზისა და ინციდენტებზე რეაგირებისთვის.უნდა არსებობდეს Threat hunting query engine, saved queries, query autocomplete/suggestions და შედეგების ფილტრაცია/აგრეგაცია.
• სასურველია MITRE ATT&CK-თან მიბმა (ტაქტიკა/ტექნიკა), attack narrative/summary დაშესაბამისი ბმულები/რეფერენსები.

10) Device Control და Host Firewall:

• USB/Thunderbolt/Bluetooth device control პოლიტიკები (block/allow list, approvals).
• სასურველია - აგენტში ჩაშენებული host firewall მართვის შესაძლებლობა (თუ გადაწყვეტა ამასუჭერს მხარს).

11) Asset Discovery (სასურველია):

• ქსელში unmanaged აქტივების აღმოჩენა (passive/active discovery), მინიმალური დამატებითიკომპონენტებით.
• უნდა იყოს აღწერილი აღმოჩენის მეთოდოლოგია, შეზღუდვები და საჭირო უფლებები.

12) უსაფრთხოება, შესაბამისობა და მონაცემთა დაცვა:

• ვენდორმა უნდა აღწეროს შესაბამისობა მინიმუმ: GDPR (თუ გამოიყენება), მონაცემთალოკაცია/რეზიდენცია, encryption at rest/in transit, key management.
• უნდა იყოს აღწერილი tamper protection, agent self-defense, uninstall protection.
• უნდა არსებობდეს API (სასურველია OpenAPI/Swagger დოკუმენტაციით) და მისიუსაფრთხოების კონტროლები. 

13) ვენდორის სტანდარტული მხარდაჭერა (Standard Product Support)

ვენდორმა უნდა უზრუნველყოს სტანდარტული პროდუქტის მხარდაჭერა მოქმედი ლიცენზიის ვადისგანმავლობაში.

მოთხოვნები:

• მხარდაჭერის მიწოდება მინიმუმ ელფოსტისა და Ticketing სისტემის საშუალებით.
• 24x7 მხარდაჭერა კრიტიკული ინციდენტებისთვის (Severity 1) ან მკაფიოდ განსაზღვრულიSLA რეაგირების დროებით.
• მკაფიო SLA რეაგირების დროების წარმოდგენა სევერიტების მიხედვით.
• პროდუქტის რეგულარული განახლებები (updates/upgrades/patches) ლიცენზიის ფარგლებშიდამატებითი საფასურის გარეშე.
• უსაფრთხოების კრიტიკული მოწყვლადობების შემთხვევაში დროული პაჩის/რეკომენდაციისმიწოდება.
• წვდომა ტექნიკურ დოკუმენტაციაზე, Knowledge Base-ზე და საუკეთესო პრაქტიკებზე.

ვენდორმა წინადადებაში უნდა აღწეროს მხარდაჭერის მოდელი, SLA პარამეტრები და Escalation პროცესი. 

14) ვენდორისგან მოთხოვნილი პასუხის ფორმა (Compliance Matrix):

ვენდორმა უნდა წარადგინოს Compliance Matrix შემდეგი ფორმატით თითოეულ მოთხოვნაზე:

• Supported / Partially supported / Not supported
• მოკლე აღწერა (როგორ/რით)
• საჭირო ლიცენზია/მოდული (თუ დამატებითია)
• შეზღუდვები/წინაპირობები
• რეფერენსი დოკუმენტაციაზე (ბმული ან დოკუმენტის თავი) 

პრეტენდენტის მიერ სავალდებული წარმოსადგენი დოკუმენტ(ებ)ი:

• სამეწარმეო ამონაწერი;
• კომპანიის მოკლე მიმოხილვა;
• სატენდერო წინადადება ფასების ცხრილის მიხედვით (დანართი #1);

პრეტენდენტის მიერ გამარჯვების შემდეგ, ხელშეკრულების გაფორმებამდე სავალდებული წარმოსადგენი დოკუმენტ(ებ)ი

• კლიენტების სია, რეკომენდაციები;
• განიხილება კომპანიები, რომლებიც მინიმუმ 2 ორი) წელიწადია დაფუძნებული;
• კომპანიის სერტიფიკატები (ასეთის არსებობის შემთხვევაში);
• ინფორმაცია წარსულში ანალოგიური გამოცდილების შესახებ;
• ცნობა საგადასახადოდან დავალიანების არ არსებობის შესახებ;

შესყიდვის ობიექტის მიწოდების ვადა, ადგილი და მიწოდების პირობა

მოწოდების ადგილია ბანკის სათავო ოფისში მისამართზე: ქ. თბილისი, ი. ჭავჭავაძის გამზ. #74;

შენიშვნა: მომსახურება უნდა მოხდეს სამუშაო საათებში;

პრეტენდენტის წინადადების ფასი და ანგარიშსწორების პირობები

• ხარჯები, რომლებიც სატენდერო წინადადების ფასში არ იქნება გათვალისწინებული, არდაექვემდებარება ანაზღაურებას;
• ბანკის მიერ ანაზღაურება განხორციელდება გამყიდველის მიერ ფაქტიურად მოწოდებული ნასყიდობის საგნისა და შესრულებული მომსახურების შესახებ გაფორმებული მიღება-ჩაბარების აქტის, სასაქონლო ზედნადებისა და საგადასახადო ანგარიშ-ფაქტურის წარმოდგენიდან 10 (ათი) სამუშაო დღის განმავლობაში;
• ტენდერში გამარჯვებული კომპანიის მხრიდან საავანსო თანხის მოთხოვნის შემთხვევაში, ბანკის მოთხოვნის საფუძველზე, კომპანია ვალდებულია მოთხოვნილ თანხაზე წარმოადგინოს ბანკისთვის მისაღები საბანკო ან/და სადაზღვევო გარანტია;

5.4. გამარჯვებული კომპანია ვალდებულია გახსნას ანგარიში სს „ლიბერთი ბანკი“-ში;

ზოგადი პირობები:

• პრეტენდენტის მიერ მოწოდებული ყველა დოკუმენტი ან/და ინფორმაცია ხელმოწერილი და ბეჭედდასმული (ბეჭდის არსებობის შემთხვევაში) უნდა იყოს უფლებამოსილი პირის მიერ (საჭიროების შემთხვევაში წარმოდგენილი უნდა იქნას მინდობილობა);
• სატენდერო დოკუმენტაციით მოთხოვნილი ყველა დოკუმენტ(ებ)ი წარმოდგენილ უნდა იქნეს ქართულ ენაზე; დოკუმენტების და ინფორმაციის უცხოურ ენაზე წარდგენის შემთხვევაში მათ უნდა დაერთოს ნოტარიულად დამოწმებული ქართული თარგმანი;
• გამარჯვებულ პრეტენდენტთან ხელშეკრულება გაფორმდება, ხელშეკრულების დრაფტის (დანართი N2) მიხედვით. ხელშეკრულების ხელმოწერაზე უარის თქმა ავტომატურად გამოიწვევს პრეტენდენტის დისკვალიფიკაციას და შავ სიაში მოხვედრას;

ინფორმაცია ელექტრონულ ტენდერში მონაწილეთათვის:

• შემოთავაზება უნდა აიტვირთოს ელექტრონული შესყიდვების ვებ-გვერდზე: tenders.ge
• ნებისმიერი შეკითხვა ტენდერის მიმდინარეობის პროცესში უნდა იყოს წერილობითი და გამოყენებულ უნდა იქნასwww.tenders.ge-ს პორტალის ონლაინ კითხვა-პასუხის რეჟიმი
• სატენდერო წინადადების წარმოდგენის ბოლო ვადა: 2026 წლის 6 მარტი, 17:00 საათი
• შეთავაზების ვალუტა: N.A
• ვაჭრობის ტიპი: ვაჭრობის გარეშე
• ელექტრონულ ტენდერში მონაწილეობის მიღების დეტალური ინსტრუქცია გთხოვთ იხილოთ თანდართულ ფაილში

სატენდერო დოკუმენტაციასთან დაკავშირებული განმარტებების მიღება პრეტენდენტს შეუძლია:

შესყიდვების მენეჯერი
შორენა თავაძე
595 901 200
ელ-ფოსტა: Shorena.tavadze@lb.ge 

ტენდერის კატეგორია:

• 72200000 პროგრამული უზრუნველყოფის შემუშავება და საკონსულტაციო მომსახურებები
• 48700000 პროგრამული პაკეტების მომსახურე პროგრამები