DNP3

DNP3 utvecklades som svar på de verkliga begränsningarna hos Modbus och andra enkla protokoll i elkraftmiljöer. Elkraftkommunikation på 1990-talet byggde ofta på hyrda telefonlinjer, radiolänkar och kraftlinjeburna system som var långsamma, störningskänsliga och benägna att avbrytas. Modbus, som förutsätter en pålitlig anslutning och inte tillhandahåller tidsstämpling eller kvalitetstillskrivning, var dåligt lämpad för dessa förhållanden. Ett värde som läses från ett Modbus-register kan vara aktuellt, eller det kan vara timmar gammalt om länken har varit intermittent. Modbus hade inget sätt att skilja mellan de två fallen.

DNP3 löste detta genom att introducera strukturerade händelsebuffertar med millisekundtidsstämplar, datakvalitetsflaggor och en protokollarkitektur som hanterar kommunikationslänkdegradation elegant. Om en länk går ner och kommer tillbaka igen bevarar utstationens händelsebuffert en post över allt som förändrades under avbrottet, och mastern kan hämta den historiken i sekvens när länken återställs. Denna förmåga är väsentlig i kraftsystem där korrekt rekonstruktion av händelsesekvenser krävs för analys efter incidenter och regulatorisk efterlevnad.

Funktionen för oombedd rapportering speglar ett annat verkligt operativt behov. I ett stort SCADA-system som pollar hundratals utstationer blir rundsturstiden för att polla varje enhet för varje värde en begränsning. DNP3 tillåter utstationer att proaktivt rapportera dataändringar till mastern när värden passerar konfigurerade trösklar, vilket minskar pollningslast och förbättrar aktualiteten hos kritiska tillståndsändringar som når kontrollenrummet. Dessa designval gjorde DNP3 genuint bättre lämpad för elnätets SCADA än sina föregångare, vilket är varför det blev standarden.

DNP3 är strukturerat i fyra lager. Det fysiska lagret hanterar det faktiska överföringsmediet, oavsett om det är serie eller Ethernet. Datalänklagret tillhandahåller ramindelning, adressering, feldetektering med CRC och flödeskontroll för tillförlitlig leverans över störningskänsliga media. Transportlagret sätter ihop flerramsapplikationsmeddelanden från datalänkramar. Applikationslagret definierar de faktiska meddelandena: förfrågningar om data, svar, styrkommandon och de typade dataobjekten som bär värdena.

Objektmodellen är vad som ger DNP3 dess semantiska rikedom jämfört med Modbus. Istället för att adressera numrerade register utan inneboende typinformation definierar DNP3 objektgrupper och variationer. Ett mätvärde som en strömmavläsning är inte bara ett 16-bitars tal utan ett objekt av en specifik grupp med en specifik variation som kodar huruvida det kommer med en kvalitetsflagga, huruvida det inkluderar en tidsstämpel och vid vilken upplösning värdet uttrycks. Den här strukturen gör det möjligt för ett mottagande system att tolka data korrekt utan konfigurationskunskap utanför bandet om vad en viss adress innebär.

Kvalitetsflaggor är en viktig operativ funktion. Varje DNP3-dataobjekt kan bära en kvalitetsbyte som anger om värdet är online eller offline, om det har åsidosatts lokalt, om det är utanför intervallet och om referenskällan är tillförlitlig. I praktiken gör kvalitetsflaggor det möjligt för SCADA-system att skilja mellan ett giltigt mätvärde, ett mätvärde från en enhet som tappat ström och ett mätvärde från en sensor som rapporterar orealistiskt höga värden. För säkerhetsövervakning kan kvalitetsflaggor också indikera manipulering om värden verkar sunda medan den underliggande enheten befinner sig i ett onormalt tillstånd.

DNP3-styroperationer följer en Select-Before-Operate-sekvens för de flesta kritiska funktioner. Mastern skickar först ett SELECT-meddelande som identifierar styrpunkten och den avsedda åtgärden. Utstationen svarar med en bekräftelse som upprepar select-parametrarna. Mastern skickar sedan ett OPERATE-meddelande för att utföra åtgärden. Utstationen verifierar att operate-parametrarna matchar de tidigare valda parametrarna och utför sedan åtgärden. Den här tvåstegsekvensen designades för att förhindra oavsiktliga operationer på grund av korrupta meddelanden eller operatörsfel i kommunikationsmiljöer med högt störningsnivå.

Select-Before-Operate-mekanismen missförstås ofta som en säkerhetskontroll. Det är den inte. Den tillhandahåller ingen autentisering av vem som utfärdar kommandot. Vilken enhet som helst som kan kommunicera med utstationen kan slutföra select- och operate-sekvensen. Mekanismen förhindrar olyckor men inte attacker. En DNP3 Secure Authentication-utmaning skulle behöva åtfölja select- eller operate-meddelandet för att ge meningsfull åtkomstkontroll, och de flesta driftsatta system implementerar inte detta.

Direct Operate är ett förenklat styrningsläge tillgängligt i DNP3 som utför en styråtgärd omedelbart utan ett föregående select. Det är avsett för icke-kritiska utgångar där tvåstegsprocessen är onödig, men det används ibland även för kritiska punkter när operatörer eller integratörer vill ha snabbare respons. Ur ett säkerhetsperspektiv kräver Direct Operate-kommandon samma granskning som Select-Before-Operate-sekvenser, och att tillåta Direct Operate på styrpunkter med hög konsekvens medan man förlitar sig på Select-Before-Operate som ett informellt funktionssäkerhetslager bör behandlas som en konfigurationsrisk.

DNP3 Secure Authentication utvecklades för att adressera protokollets grundläggande avsaknad av autentisering. Definierat i IEEE 1815 lägger den nuvarande generationen till utmaning-svar-autentisering med HMAC-algoritmer. När Secure Authentication är aktiverat måste en master som utfärdar ett styrkommando först svara på en utmaning från utstationen genom att tillhandahålla en meddelandeautentiseringskod härledd från en delad nyckel. Utstationen verifierar koden innan kommandot utförs. Det förhindrar ej autentiserade kommandon från obehöriga källor, förutsatt att de delade nycklarna hanteras korrekt.

Klyftan mellan vad Secure Authentication specificerar och vad som faktiskt är driftsatt i fält är betydande. Implementering av SA kräver firmwarestöd på utstationen, konfigurering av delade nycklar, nyckelhanteringsprocesser och testning. Många äldre RTU:er i drift i dag tillverkades innan SA standardiserades eller har inte firmwareuppdateringar som stödjer det. Att eftermontera SA i en befintlig driftsättning kan innebära betydande leverantörskoordinering, testning för att säkerställa att operativt beteende inte påverkas och godkännandetest av driftsorganisationen. Dessa hinder innebär att mycket av den DNP3-infrastruktur som för närvarande är i drift i elnätbolag och vattensystem körs utan någon autentisering.

Även där SA är driftsatt varierar nyckelhanteringspraxis avsevärt. Delade nycklar som aldrig roteras, nycklar som är desamma för alla utstationer i en flotta, eller nycklar som förvaras osäkert på mastersystem undergräver det skydd som SA är avsett att tillhandahålla. Att utvärdera DNP3-säkerhet i en driftsorganisations miljö innebär inte bara att fråga om SA är konfigurerat utan också att undersöka nyckelhanteringsprocesserna bakom det, eftersom svag nyckelhantering gör även ett korrekt implementerat protokoll effektivt ej autentiserat.

Övervakning av DNP3-trafik ger värdefull insyn i den operativa statusen hos kritisk infrastruktur och i avvikelser som kan indikera obehörig åtkomst eller manipulation. Normal DNP3-trafik mellan en SCADA-master och dess utstationer följer förutsägbara mönster: mastern pollar enligt ett schema, utstationer svarar med data, styroperationer inträffar sällan och under kända operationsfönster, och händelsebuffertar hämtas konsekvent. Avvikelser från dessa mönster, som styroperationer vid ovanliga tidpunkter, operationer på punkter som sällan eller aldrig kommanderas, pollning från oväntade källadresser eller plötsliga förändringar i händelsebuffertinnehåll, är meningsfulla signaler.

Industriella nätverksövervakningsplattformar som tolkar DNP3 kan extrahera funktionskoder, objektgrupp- och variationsinformation, käll- och destinationsadresser och styrpunktsidentifierare från infångad trafik. Det gör det möjligt att bygga en beteendebaslinje för normal DNP3-aktivitet för en given utstation och generera larm när baslinjen kränks. Ett styrkommando riktat mot en brytare eller pump som inte manövrerades på månader, som anländer från en källadress som inte är den primära SCADA-mastern, är exakt den typ av händelse som bör utlösa omedelbar utredning.

Händelsebuffertanalys är en forensisk förmåga som DNP3 tillhandahåller och Modbus inte gör. Efter en misstänkt incident kan hämtning av fullständig händelsehistorik från drabbade utstationer avslöja en sekvens av tillståndsändringar, styroperationer och mätavvikelser som inte fångades i nätverkstrafikloggar. Den historiken kan fastställa en tidslinje över vad som hände, i vilken ordning och vid vilka tidsstämplar, vilket är väsentligt för att förstå omfattningen av ett intrång och för regulatorisk incidentrapportering i elnätbolagets och vattensektorns miljöer.