23. april Spørgsmål og svar. Kontrakt om levering af logningsløsning. Aalborg Universitet

Transkript

1 23. april 2018 Spørgsmål og svar Kontrakt om levering af logningsløsning Aalborg Universitet

2 Spørgsmål 1 Jeg vil høre dig, om vi kan få tilsendt og i word format? Kravspecifikation for henholdsvis SaaS og on-premise løsning. Svar 1 Versioner i word-format er offentliggjort på Ordregivers hjemmeside. NYE FRISTER Ordregiver har modtaget henvendelser om, hvorvidt kontraktbilagene kan udfyldes af Ordregiver på visse punkter. Dette overvejer Ordregiver, og vil i givet fald offentliggøre nye versioner af kontraktbilag i uge 16. Som en konsekvens heraf ændres fristerne i udbuddet, jf. nedenstående: Dato Aktivitet 23. april Frist for spørgsmål, kl. 14: april Svar på spørgsmål 7. maj Tilbudsfrist, kl. 14: maj Forventet meddelelse om tildelingsbeslutning maj Standstill 25. maj Kontraktunderskrift 1. juni Kontraktstart Der gøres opmærksom på, at der kan ske afvigelser fra tidsplanen. Side 2

3 Spørgsmål 2 Ad) Krav 3.5.1: Hvad er længden af den forventede retention periode for størstedelen af dataene? Svar 2 For størstedelen af logningsdata, forventes arkivering at ske efter 12 mdr. Dermed vil løbende 12 mdr. s logdata være umiddelbart tilgængelig for analyse. Spørgsmål 3 I forbindelse med gennemlæsning af udbudsbetingelserne, vil vi høre om det er muligt at udarbejde en oversigt eller et skema over hvilke kontraktbilag ordregiver ser som relevante for så vidt angår Delaftale 1 og Delaftale 2. Sådan at tilbudsgiver får et klarere billede af hvilke bilag ordregiver ønsker udfyldt for hver delaftale i forbindelse med tilbudsgivningen. Ligeledes må det gerne fremgå hvis nogle bilag først er relevante ved kontraktindgåelsen. Svar 3 Der er indkommet flere spørgsmål vedrørende udfyldelse af kontraktbilagene, hvorfor Ordregiver har overvejet dette, jf. nedenstående oversigt. Det skal understreges, at ved de kontraktbilag, som Ordregiver har udfyldt, skal det udfyldte ikke anses for mindstekrav. Bilag 1 : Bilag 2 : Dette er et centralt bilag, som udgøres af Kravspecifikation plus tilbudsgivers løsningsbeskrivelse Bilag 3 : Bilag 4 : Bilag 5 : Bilag 6 : Bilag 7 : Ordregiver har udfyldt nogle af de tomme felter i dette bilag, og en ny version er offentliggjort på hjemmesiden. Tilbudsgiver bedes udfylde de resterende tomme felter, i det omfang det er relevant. Side 3

4 Bilag 8 : Ordregiver har udfyldt de tomme felter i dette bilag, og en ny version er offentliggjort på hjemmesiden. Bilag 9 : Bilag 10 : Ordregiver har udfyldt nogle af de tomme felter i dette bilag, og en ny version er offentliggjort på hjemmesiden. Tilbudsgiver bedes udfylde de resterende tomme felter, i det omfang det er relevant. Bilag 11 : Hvad angår oplysninger om personer fra Ordregivers organisation vil Ordregiver udfylde det efter evaluering, da det afhænger af tilbuddets indhold. Bilag 12 : Bilag 13 : Ordregiver har udfyldt nogle af de tomme felter i dette bilag, og en ny version er offentliggjort på hjemmesiden. Tilbudsgiver bedes udfylde de resterende tomme felter, i det omfang det er relevant. Spørgsmål 4 Efter en gennemlæsning af materialet er vi stødt på flere tilfælde i flere af kontraktbilagene hvor kravstillerens formuleringer ikke er afsluttet endeligt, men indeholder [ ]. Initialt kunne man tro, at det er grundet at Leverandøren skal indføre oplysningerne, men der er steder hvor det ikke giver mening. Et eksempel er i dokumenterne for servicemål i begge delaftaler, hvor der står: En overskridelse af en maksimal svartid med mere end [ ] % eller manglende opfyldelse af en opfyldelsesgrad med mere end [ ] procentpoint indebærer, at systemet anses for utilgængeligt fra det tidspunkt, hvor forholdet er skriftligt meddelt leverandøren, og indtil forholdet er afhjulpet. Sker der samtidig overskridelse af en maksimal svartid eller manglende opfyldelse af opfyldelsesgraden for flere forskellige transaktioner, betragtes det kun som en overskridelse. Vi skal naturligvis vurdere risikoen, hvor vi tager bod i betragtning, ved tilbudsgivning. Derfor undrer det, hvis det skulle være tilbudsgiver der har mulighed for at sætte bodsmål o.l. Et andet eksempel er summen for bonus ved en performance, der ligesom ovenstående er udefineret. Side 4

5 Er der noget vi har overset her? Rekvirerer vi de korrekte dokumenter? Svar 4 Se svar på spørgsmål 3. Spørgsmål 5 Kravspecifikation, afsnit 3: Hvor mange brugere forventes at bruge systemet? Hvilke typer brugere / roller forventes at bruge systemet? Hvor længe forventes log data at skulle gemmes?. Fx 10% i 5 år, 30% i 1 år, 50% i 3 md. Svar 5 Forventeligt vil løsningen benyttes af op til 50 forskellige brugere, dog typisk 1-5 samtidige. Brugeren vil bestå af følgende profiler: Supportmedarbejdere, IT sikkerhedsmedarbejdere, IT infrastrukturmedarbejdere og systemejere. Størstedelen af logdata vil være systemspecifikt, og det vurderes, at mere end 90% arkiveres efter 1 år og det resterende efter maksimalt 5 år. Spørgsmål 6 Kravspecifikation, afsnit 3.3 Det er vores antagelse at agentløst udstyr kan tilgå log management systemet direkte. Hvis ikke antager vi at eventuelle mellemled/servere til dette formål er uden for scope af udbuddet. Venligst bekræft. Side 5

6 Svar 6 For en logningsløsning placeret On-premise, vil det være muligt at etablere direkte adgang fra agentløst udstyr. Såfremt der er tale om logningsløsning As-a-Service, placeret uden for AAU s netværk, skal der af sikkerhedsmæssige hensyn benyttes en form for proxy. Denne/disse forventes at være en del af scope for udbuddet. Spørgsmål 7 Kravspecifikation, afsnit Hvad menes med gruppering af logkilder? Er det fx at kunne søge en delmængde af logkilder igennem, eller at få et overblik over alle logkilder? Svar 7 Med gruppering af logkilder forstås muligheden for at kunne søge og analysere på en logisk delmængde af logkilderne. Det kunne tænkes at logningsløsningen fx automatisk kunne gruppere -, netværks-, database-service, eller gruppering på andre parametre. Spørgsmål 8 Kravspecifikation, afsnit Kan niveauet af GDPR compliance rapportering uddybes? Svar 8 Med GDPR compliance menes som eksempel en rapport om afvigelse på normalbillede for specifikke systemer, der kunne indikere et muligt sikkerhedsbrud. Eksempelvis en rapport over sikkerhedshændelser inden for de seneste 72 timer. Side 6

7 Spørgsmål 9 Kravspecifikation, afsnit Kravet refererer til kravene til audit logs, men det er uklart hvilket. Er der tale om systemets egne audit logs eller audit logs fra andre systemer? Svar 9 Kravet gælder for håndtering af Audit logs fra andre systemer. Spørgsmål 10 Jf _udbudsbetingelser-logning pkt. 12: Udbudsstilleren ønsker bl.a. kontraktbilag udfyldt. Ud fra følgende beskrivelse, ønskes det besvaret, hvilke kontraktbilag Leverandøren skal udfylde og fremsende, herunder om [ ] samtlige steder skal udfyldes. Det kunne med fordel markeres, der hvor udbudsstilleren ønsker at Leverandøren indfører beskrivelse. a. Efter en gennemlæsning af materialet er vi stødt på flere tilfælde i flere af kontraktbilagene hvor kravstillerens formuleringer ikke er afsluttet endeligt, men indeholder [ ]. Initialt kunne man tro, at det er grundet at Leverandøren skal indføre oplysningerne, men der er steder hvor det ikke giver mening. Et eksempel er i dokumenterne for servicemål i begge delaftaler, hvor der står: En overskridelse af en maksimal svartid med mere end [ ] % eller manglende op-fyldelse af en opfyldelsesgrad med mere end [ ] procentpoint indebærer, at sy-stemet anses for utilgængeligt fra det tidspunkt, hvor forholdet er skriftligt meddelt leverandøren, og indtil forholdet er afhjulpet. Sker der samtidig overskridelse af en maksimal svartid eller manglende opfyldelse af opfyldelsesgraden for flere forskelli-ge transaktioner, betragtes det kun som en overskridelse. Svar 10 Se svar på spørgsmål 3. Spørgsmål 11 Hvilke datakilder er blevet brugt som grundlag for at beregne 50 GB/dag svarende til ca EPS? Dette ville svare til ca. 39 byte pr. event, hvilket lyder meget lavt. Normalt tales der om 300 bytes. Side 7

8 Svar 11 Datamængder fra krav ændres til nedenstående - Følgende inputdata (RAW) til logningsløsningen vurderes relevante o Op til 100 GB/dag svarende til ca EPS o Op til 300 GB/dag svarende til ca EPS o Op til 600 GB/dag svarende til ca EPS Såfremt ovenstående grænser er skæve i forhold til logningsløsningens licensering eller andre forhold, kan andre grænser foreslås af tilbudsgiver. Spørgsmål 12 Det skrives, at EPS er et relevant input-tal. Betyder dette, at Aalborg Universitet regner med at nå maximum EPS ved integration af alle datakilder? Svar 12 Se svar 11 for ændrede EPS tal. Spørgsmål 13 Er det korrekt, at antallet af systemer inklusive infrastruktur i alt dækker over ca ipadresser/noder/log sources (ekskl. RUS2), der skal indsamles data fra? Svar 13 For de systemer, der er i scope for dette udbud, er størstedelen af ip adresserne allokeret til Cisco AccessPoints og andet netværksudstyr (ca i alt). Det fulde scope for AAU s administrative infrastruktur vil indeholde mere end servere og dermed unikke ip adresser ud over de specificerede. Dertil vil der løbende blive integreret forskningsmæssigt udstyr i et ukendt antal, som dynamisk vil blive oprettet og nedlagt i varierende tidsinterval (dage/uger/mdr). Side 8

9 Spørgsmål 14 Hvor mange ip-adresser skal der indsamles data fra i det hostede system RUS2? Svar 14 Forventeligt mindre end 10. Spørgsmål 15 Hvordan ønsker AAU, at selve logningsløsningen skal være sikkerhedsmæssigt sikret imod hacking og manipulering med data efter logdata er modtaget af logningsløsningen - har AAU krav om EAL/CC certificering, eller er det en sikkerhed som AAU selv stiller til rådighed i form af at sikre administrative adgange til lognings-løsningen mv.? Svar 15 Der er ikke krav om et bestemt EAL/CC niveau til logningsløsningen. Til On-premise vil AAU håndtere sikring af systemet på samme måde som andre systemer med kritiske data. Adgang til logningsløsningen vil basere sig på RBAC, baseret på AD grupper såfremt løsningen understøtter dette, jævnfør krav Spørgsmål : Stiller AAU selv infrastruktur til rådighed i form af virtuelle/fysiske servere? Svar 16 Ja, se i øvrigt krav Spørgsmål : Er AAU indstillet på at etablere en fuld redundant løsning i forhold til imødegåelse af tab af logdata? Svar 17 AAU er indstillet på at lave redundans på relevante komponenter, således at der ikke opstår Single Point of Failure, men ikke nødvendigvis komplet dubleret udstyr. Side 9

10 Spørgsmål 18 Hvor mange personer regner Aalborg Universitet med, at der skal uddannes? Svar 18 Se svar 5, hvor uddannelse forventes at skulle gennemføres for alle, indenfor de specificerede roller/profiler. Spørgsmål : Hvem stiller driftsmiljøets kapacitet til rådighed? Svar 19 Se svar 16. Spørgsmål : ønsker kunden yderligere rapportering/usescases implementeret/aktiveret ved rekvirering af ydelsen eller omfatter udbuddet udelukkende en basisimplementering, hvor standard use cases er tilgængelig men ej aktiveret? Svar 20 Kunden forventer relevante usecases implementeret og aktiveret. Spørgsmål : ønsker kunden i forlængelse af de definerede tre usecases at Leverandøren medvirker til metoder hvorpå kunden kan anvende løsningen til at honorere forretnings- og sikkerhedsmæssige krav? Eksempelvis et løbende samarbejde mellem kunde og Leverandør i form af workshops o.l. hvor Leverandøren kan tilbyde kunden ekspertviden til anvendelse af løsningen. Svar 21 Ja kunden ønsker løbende sparring med den valgte Leverandør, således at løsningen løbende udvides/udvikles. Side 10

11 Spørgsmål 22 Ønsker Kunden eksempler på referencekunder for Leverandørens erfaringer andre kunder på løsningen? Svar 22 Nej. Spørgsmål 23 For en Onpremises deployment foretrækker ordre giver en virtuel deployment eller tilbud på hardware appliance. - kan logfiler blive opsamlet på en lokation? hvad er antal af datacentre, der skal opsamles logs fra? - Kan ordregiver bekræfte EPS niveau og hvordan dette antal er beregnet?, - I udbuds materialet er der indikationer på up til EPS, hvilke log kilder er med i disse betragtninger. - for de nævnte systemer der indgår i udbuds materiale, vil ordregiver venligst angive hvilke systemer der er kritiske og indeholder følsomme persondate/følsomme data. o Har ordre giver en liste af kritiske systemer/ følsomme data? o Vil alle nævnte systermer I udbudsmaterialet være relevant for projektet eller vil nogle systemer kun indgå i logningsløsningen for basal opsamling af log og storage? - For log collection/ management og analyse forventer ordregiver High Availability eller Disaster Recovery? - Har ordregiver allerede en eksisterende SIEM plaform som ordregiver ønsker en integration til? - Hvilken forventning har ordregiver til de ca netværks komponenter og logopsamling herfra. o hvad ønsket Ordregiver at opnå? Svar 23 - Kunden foretrækker virtuel deployment, men såfremt det økonomisk er mere fordelagtig med en hardware appliance, kan dette også accepteres. - Ja logdata kan opsamles på en lokation fra relevante datacentre og geografiske lokationer. Tilbudsgiver bedes beskrive muligheder for opsamling jævnfør krav Side 11

12 - For korrigerede EPS tal se svar 11, beregnet ud fra nuværende logopsamling. - Afsnit 5.2 Prioriterede systemer indeholder systemer med følsomme/personfølsomme data, men ikke begrænset hertil, med undtagelse af nedenstående: Netværksudstyr (1200 AP, 600 switche, routere/f5/vpn... mv - i alt 2000) Password Reset Radius (2 servere) - Grundlæggende er de listede systemer relevante for projektet. - Ønske fra kunden om High Availability (HA) og Disaster Recovery (DR) vil afhænge af hvor stor omkostning det har på den tilbudte løsning. - Ved DR forstås mulighed for genetablering af den komplette løsning inkl. Logdata. Umiddelbar forventning: HA DR Log collection Ja / afhængig af pris Ja Log management Nej / afhængig af pris Ja Log analyse Nej / afhængig af pris Ja - Nej, kunden har ingen SIEM implementeret. - Primært korrelering af logdata med NetFlow af hensyn til analyse af sikkerhedsbrud. Side 12