1. ALLMÄNT

1.1. Om föreskriften

Alla järnvägsföretag och infrastrukturförvaltare använder någon form av IT-system, som kan ha större eller mindre inverkan på verksamheten och säkerheten. Dess nytta måste vägas mot de risker datoranvändningen kan medföra och därför är avsikten med denna föreskrift att peka på procedurer för att öka nyttan och minska risker. Denna föreskrift visar hur tillgångar i form av IT-system ska hanteras.

1.2. Styrande dokument

• Förordning (EU) 2018/762 med ändringar enligt förordning (EU) 2020/782, om gemensamma säkerhetsmetoder för krav på säkerhetsstyrningssystem, Bilaga I och II punkt 5.2: Styrning och kontroll av operativa tillgångar

1.3. Definitioner

• Tillgång = All utrustning (fast eller rörlig), struktur, programvaror eller andra komponentersom kräver underhåll över tid och tillhandahålls för järnvägsdrift.
• IT-system = ett system som används för att samla in, lagra, bearbeta och distribuera information för att stödja kommunikation och arbete inom organisationen.
• Applikation = datorprogram som fyller ett direkt syfte för användaren.
• Livscykel = sammanfattningen av de stadier en tillgång genomgår från planering till avveckling. För indelning se avsnitt 3.1.
• Komfortinställningar = inställningar som ej påverkar funktionen, exvis ljusstyrka, ljudvolym, men anpassar gränssnittet till användaren.

1.4. Dokumentation och spårbarhet

All programvara ska åtföljas av dokumentation, som ska vara tillräcklig för att en användare ska kunna hantera systemet och förstå eventuella felmeddelanden. I den mån MBV har tillgång till källkod, ska även denna vara dokumenterad i form av kommentarer till koden och separat beskrivning av uppbyggnaden.

Applikationer som MBV har full kontroll över ska vara utformade så att man utgående från utdata ska kunna spåra vilka indata som som använts. Äldre versioner ska arkiveras och beslut om större ändringar ska dokumenteras.

1.5. Direkt avvikelsehantering

En applikation får innehålla en funktion som genererar en avvikelseanmälan om en avvikelse från föreskrifter eller rutiner upptäcks.

2. INDELNING AV IT-APPLIKATIONER

2.1. Klassificering

För att i en första omgång kunna bedöma risker och ställa krav på systemen, behövs en grov indelning. Varje applikation karakteriseras med två tecken XY där det första anger den direkta säkerhetsinverkan:

A = Stor och direkt inverkan på säkerheten.
B = Liten eller indirekt inverkan på säkerheten.
C = Obetydlig eller ingen inverkan på säkerheten.

Andra tecknet, en siffra, anger hur stort inflytande MBV har över konfigurationen:

1 = Inget inflytande av betydelse.
2 = Möjligt men inte hundraprocentigt inflytande.
3 = Full kontroll.

Exempelvis klassas ATC som A1, avvikelserapporteringen som B3 och vanliga kontorsprogram som C2.

Då dessa totalt nio klasser är en grov indelning, ska varje applikation även bedömas individuellt.

2.2. Policy

MBV ska använda IT-system där detta är motiverat och höjer säkerheten. Ett IT-system ska inte tillåtas att på egen hand bestämma om åtgärder som kan medföra ökade risker, utan i första hand vara rådgivande så att en människa kan fatta ett beslut grundat på sitt omdöme och sin kunskap om säkerhetsstyrningssystemet och det aktuella området.

2.3. Övergripande regler klass A

För att få användas, ska programvaran (samt i förekommande fall hårdvaran den är installerad på) vara certifierad av ett vederbörligt certifieringsorgan. Det ska inte vara möjligt att ändra på konfigurationen utöver inställningar av komfortkaraktär. I allmänhet betyder detta att endast A1 ska få användas. Klasserna A2 och A3 har stor potential att strida mot policyn i avsnitt 2.2 och ska i möjligaste mån undvikas.

Kan man förvissa sig om att installation och användning är hårt styrda av externa organisationer vars uppgift är att se till att systemet är säkert, är ingen ytterligar riskutredning nödvändig för klass A1.

2.4. Övergripande regler klass B

En utförlig riskanalys enligt MBVF 0126 ska göras i såväl planerings- som införandefasen.

2.5. Övergripande regler klass C

Först ska avgöras om systemet eller applikationen har någon inverkan på säkerheten. Om så inte är fallet, ska den inte behandlas inom ramen för denna föreskrift. I andra fall ska riskhanteringen inledas med en bedömning av om riskanalys ska göras eller är onödig.

3. LIVSCYKLER FÖR IT-SYSTEM

3.1. Livscykelmodellen

Livscykelmodellen indelas i

1. Planeringsfasen
2. Genomförandefasen
3. Drifts- och underhållsfasen inkl ändringar
4. Modernisering, avveckling och bortskaffande

En strikt tillämpning av denna indelning är inte alltid möjlig när det gäller IT-system. I synnerhet flyter ofta planerings- och genomförandefaserna ihop när det gäller enklare system.

3.2. Planeringsfasen

Inför utveckling av ett system/applikation eller anskaffning från extern leverantör, måste ett antal frågor, minst nedanstående, beaktas:

• Vilka problem avser man att lösa?
• Hur kommer systemet att kunna integreras i verksamheten?
• Hur klassificeras systemet (avsnitt 2.1 ovan)?
• Kommer befintliga applikationer att påverkas?
• Finns det risker som redan nu kan förutses?
• Finns tillräcklig dokumentation tillgänglig?

Resonemanget ska dokumenteras som en utredning. Om närmare riskanalys erfordras ska denna dokumenteras separat.

3.3. Genomförandefasen

Ett antal frågor, minst nedanstående, ska beaktas:

• Avgörande om egen förmåga duger eller applikationen ska upphandlas.
• Plan för driftsättning.
• Utbildning av användare.
• Anpassning av tidigare rutiner.

3.4. Drifts- och underhållsfasen

Ett antal frågor, minst nedanstående, ska beaktas:

• Avvikelserapportering om fel upptäcks. Kan göras av användare eller applikationen (se avsnitt 1.5).
• Återkoppling från användare beträffande användbarhet m m, som kan leda till förbättringar i programvaran eller rutiner kring den.
• Installation av ändringar.
• Utbildning av tillkommande användare.

Ändringar, som ofta hänförs till en separat fas, i programvaran innebär här endast smärre ändringar av typen buggfixar och liknande som inte inverkar på funktionaliteten eller introducerar nya funktioner (i så fall är det moderniseringsfasen som ska inträdas i). Dessa får introduceras under driften. I tillämpliga delar ska dokumentationen uppdateras.

3.5. Modernisering, avveckling och bortskaffande

Modernisering innebär i detta sammanhang installation av en programversion som väsentligt avviker från den tidigare använda. Allt efter behov ska då metoderna i genomförandefasen användas. Vid avveckling ska det göras en bedömning av eventuella risker som kan uppstå vid avvecklingen.

Vid bortskaffande av applikation(er) ska tillses att till dessa knuten hårdvara återvinns på sett sätt som överensstämmer med svensk lag (programvara är inget problem).

Malmbanans Vänner, Arcusvägen 95, 975 94 LULEÅ. Tel 0920-250016.

 Fil 0696 datum 2025-03-15