Bakgrunn

Vi har fått noen henvendelser på service desk om problemer med å sende lenker til Signeringstjenesten for ansvarlige foretak på e-post. Ulike sikringstiltak mot phishing-mail hos mottakerne kan gjøre at e-postene i noen tilfeller ikke kommer frem, eller at lenken blir fjernet eller brutt.

Det er svært viktig at tilliten til FtPB-plattformen er høy og at vi gjør nødvendige sikringstiltak i alle ledd. Vi ber søknadssystemene om å følge tiltakene under. Rådene er basert på veiledning fra Nasjonal sikkerhetsmyndighet.

Anbefalte sikkerhetstiltak

Sikring av e-posttjeneren

Avsenders mailserver bør være satt opp med følgende:

1. SPF (Sender Policy Framework): angir hvilke e-posttjenere som kan sende på vegne av avsender.

2. DKIM (DomainKeys Identified Mail): elektronisk signatur fra avsender som legges på utgående e-post, som kan verifiseres mot DNS.

Andre anbefalte metoder, som ikke alltid er praktisk mulige, er:

• DMARC (Domain based Message Authentication, Reporting and Conformance): beskriver hvordan e-post som feiler på SPF og DKIM-sjekk behandles og gjør det mulig å fange opp f.eks. phishing-forsøk hvor avsender misbrukes.

• Bruk av autentiseringsmekanismer mellom mail-servere (STARTTLS med sertifikat): gir autentisert og kryptert kommunikasjon mellom mail-servere.

Et annet tiltak kan være å sette opp overvåking av e-post som ikke blir levert hos avsender og som kommer tilbake med en feilkode eller lignende. Det gjør det mulig å varsle mottakeren og følge opp omfanget av leveringsproblemet.

Formatering av e-posten

Her er noen tips til selve e-postinnholdet:

• HTML-formatert e-post må ha et design som identifiserer avsender, være språklig korrekte og skrevet med klart språk. Det gjør dem mer troverdige for mottakerne.

• Forkortelser av lenken (av typen bitly eller lignende), eller at man legger en informativ tekst over visningen av lenken, gjør at e-posten oppfattes som mer mistenkelig. Det anbefales derfor å vise hele URL-en.

• E-posten kan inneholde en generell lenke med informasjon av tjenesten, slik at det dokumenteres at oppgaven som skal utføres er legitim.

• Vedlegg bør ikke sendes på e-post, men lenkes opp slik at mottaker kan laste dem ned fra serveren ved behov.

På bakgrunn av tipsene over har vi endret malene våre:

Varsling og mal for varslingstekster, Signeringstjenesten

Tiltakshavers samtykke til byggeplaner

Vurder om e-post med lenker kan unngås 

På generelt grunnlag er ikke e-post med lenker en sikker løsning, fordi det kan bidra til å svekke den alminnelige årvåkenheten mot phishing-forsøk. Erfaringsmessig er det vellykkede phishing-forsøk som er den største kilden til suksessfulle cyber-angrep mot myndigheter og bedrifter. Man bør derfor alltid vurdere om varsling kan skje på en annen måte enn ved bruk av e-post eller SMS.

Søknadssystemene sitter tettest på brukerne og kan best lage alternative løsninger, for eksempel gjennom administrering av portaler og brukerkontoer. DiBK er gjerne med på å diskutere hvordan vi kan tilgjengeliggjøre grunnlagsdata som gjør at søknadssystemene kan lage en portal for blant annet Signeringstjenesten for ansvarlige foretak.

Se også: Hvordan unngå direktelenke til erklæringen?

Kilder til mer informasjon

• Datatilsynet: Phishing - hvordan beskytte virksomheten | Datatilsynet

• NSM: Sikring av e-post - Nasjonal sikkerhetsmyndighet (nsm.no)

• Nettvett: https://nettvett.no/er-lenken-trygg/

Vi har oppdaget at det ble en feil i behandlingen av Tiltakshavers samtykke til byggeplaner etter oppdateringen av Arbeidsflyt Alfa den 15.02.2022.

En feil ved mottak av samtykket i arbeidsflyt tjenesten medførte at innsender mottok en melding i Altinn om at samtykket ikke kunne bli sendt og APIer som henter status på samtykket ble ikke oppdatert.

Problemet hadde med at den nye instansen av tjeneste som behandler Altinn innsendinger manglet en autentisering.

Vi har nå oppdatert alle statuser og gjort samtykker nedlastbare for søknadssystemene.

Vi ser at noen brukere har brukt signeringslenken flere ganger. Systemet bruker i så fall den første signaturen.

Etter en lang periode med fokus på Signeringstjenesten for ansvarlige foretak, har vi gjort noen oppdateringer i valideringsreglene for flere av tjenestene våre. Mange av innspillene kommer fra service desk - tusen takk for engasjementet deres!

Det er hovedsakelig tekstlige endringer som er utført. Noen sjekklistepunkt er lagt til, og enkelte regler har endret advarsel.

Oversikt over endringer

Under har vi satt opp en oversikt over endringene, fordelt på henholdsvis søknader og nabovarsel.

Endret validering for søknader

Tabellene under viser endringene i validering for søknad om ramme, ettrinn og tiltak uten ansvarsrett.

Se også oppdaterte kravtabeller for hver tjeneste (endringene er markert med 23.02.22):

• Søknad om rammetillatelse

• Søknad om tillatelse i ett trinn

• Søknad om tillatelse til tiltak uten ansvarsrett

Rammesøknad

Ettrinnssøknad

Søknad om tiltak uten ansvarsrett

Endret validering for nabovarsel

Vi beskriver de planlagte endringene under. Se også kravtabellen (oppdatert 23.02.2022):

• Nabovarsel

Oppdatering til ny valideringsmetode

For nabovarsel har vi gjort en større gjennomgang av reglene for å oppdatere til ny metode for validering opp mot sjekkpunkt. Det gjør at en rekke regler har fått oppdatert tekst, regelnummer og sjekk mot relevante tiltakstyper. Det gjelder særlig validering mot eiendom/byggested, som nå harmoniserer mer med hovedsøknadene.

Selve innholdet i reglene skal ikke være endret, bortsett fra det som er listet i tabellen under.

Regler som er endret

Vi oppdaterer Arbeidsflyt Alfa i PROD kl 20:00 15.02.2022.

I denne sammenhengen blir stopper behandlingen av innsendinger i backend i en stund. Tjenestene Signaturtjenesten (Ansako) og Tiltakshavers samtykke til byggeplaner blir nede i en periode.

Vi tror nede tiden blir mindre enn en time. Denne saken blir oppdatert underveis.

Det er mulig å sende inn søknader gjennom Altinn REST API. Disse blir lagt på kø og behandlet senere. FtB Status, Download og Validerings API og Ansako signeringer og Samtykke signering blir ikke tilgjengelige.

Eksempel på hva brukerne ser når Ansako er i vedlikeholdsmodus:

Hei alle søknadssystemer! Vi ser at de fleste tester Ansako innsendinger så det er færre innsendinger gjennom Altinn på TEST nå. Vi har satt opp den nye konfigurasjonen av Arbeidsflyt Alfa i TEST og blir veldig glade om dere har tid til å kjøre noen innsendingstjenester gjennom TT02. Vi vil gjerne teste dette oppsettet så mye vi kan før den legges i PROD torsdag kveld, så send gjerne noen innsendinger torsdag 10.02.2022.

Vi oppdaterer Arbeidsflyt Alfa i PROD kl 20:00 10.02.2022. I denne sammenhengen tar vi ned backend og Signaturtjenesten (Ansako) i en periode. Vi tror nedetiden blir mindre enn en time. Denne saken blir oppdatert underveis.

Det er mulig å sende inn søknader gjennom Altinn REST API. Disse blir lagt på kø og behandlet senere. FtB Status, Download og Validerings API og Ansako signeringer blir ikke tilgjengelige.

Vi får tilbakemeldinger om at Ansako-filene er store, typisk 2-4 mb. Dette gjør naturlig nok at en del foretak blir bekymret for lagringsplassen sin.

Filene som Ansako sender til signering er typisk 400-800 kb. Det meste av data legges med andre ord på i eSignering. Det er fordi den signerte filen inneholder en pakke med signeringsinformasjon. Denne pakken er nødvendig for at signaturen skal holde som en kvalifisert signatur som kan prøves i en rettssak, jf. eIdas-forordningen.

Vi har fått følgende tilbakemelding fra Digitaliseringsdirektoratet om størrelsen på signaturpakken:

Det jobbes med å erstatte dagens pakkemetoder for PAdES og de embeddede XAdES-filene med en ny metode som skal ta ned størrelsen på XAdES, og dermed også PAdES. Forventet effekt blir da at man både får mindre output, og at det blir mulig å dytte inn større (og flere) inputfiler til signering (om man skulle ønske det), siden prosesseringa av signaturen blir lettere med mindre data til signering. Leverandøren vår, Posten, holder på å implementere de nye metodene på si side nå. Vi håper å ha noe klart til dere i test i løpet av en måned eller to.

Vi håper på bakgrunn av dette at problemet (bokstavelig talt) blir mindre med tiden.

Vi jobber også på vår side for å se om det er noe vi kan gjøre for å begrense størrelsen på det vi sender til eSignering, for eksempel ved å minke kvaliteten. Dette vil imidlertid ha begrenset effekt så lenge det meste av data legges på etter signering.

Vi jobber med å forbedre ytelsen på vår backend. Vi må gjøre noen rekonfigureringer i Azure og setter i gang med det arbeidet kl 15 i dag. Tjenesten kommer til å være nede en stund og kan være noe ustabil senere i kveld.

Send sak på service desk eller ring vakttelefon om dette tidspunktet er vanskelig i dag.

Dette omhandler bare TEST miljøene, men alle tjenester er berørt (også Ansako).

Vi ser at SvarUt er nede og har slått av all behandling av køen fra Altinn inn i Fellestjenester Plan og Bygg. Ansako tjenestene er ikke berørt.

Forsendelser som har feilet mens SvarUt var nede:

AR472955653
AR472955106
AR472954827
AR472954523
AR472954117
AR472953573
AR472953454
AR472953229
AR472953024
AR472952518
AR472952285
AR472951837
AR472951801
AR472950762
AR472950711
AR472950519
AR472950400
AR472950391
AR472949767
AR472948885

Alle behandlingsstatuser for Ansako er nå implementert i PROD.

Søknadssystemet kan sette følgende statuser:

• Signert manuelt (initieres fra ansvarlig søker)

• Trukket (initieres fra ansvarlig søker)

• Avsluttet (initieres fra ansvarlig søker)

• Feilet (settes av søknadssystem)

All dokumentasjon om behandlingsstatus er samlet her: Behandlingsstatus, Signeringstjenesten

KS flytter FIKS SvarUt TEST miljøet over til en ny database. Arbeidet har startet nå og vil holde på noen dager.

De varsler at SvarUt i TEST kan bli utilgjengelig periodevis mens flyttingen skjer.

Dette betyr at test utsendinger fra Fellestjenester Plan og Bygg til SvarUt kan feile i denne perioden om mottagende SvarUt system er nede når vi prøver å overleverer en forsendelse. Alle tjenester som sender noe til print/Posten er også omfattet (i praksis sendes aldri noe fra TEST).