US DHS Resilient PNT Conformance Framework: hva Kshana gir belegg for

Rammeverket beskriver resiliensnivåer fra 0 til 4 bygget på åtte nummererte krav, og en evalueringstilnærming som kombinerer statisk analyse med dynamisk analyse der testvektorer representerer trusler. Det har ikke noe eget skjema for kravidentifikatorer, så henvisningene nedenfor er nivå- og kravnumrene og seksjonsnumrene. Det er resultatbasert og katalogiserer ikke trusler.

Hver rad sier hvilke Kshana-utdata som gir belegg for kravet og hva som gjenstår. Ingenting her sier at et rammeverk er oppfylt eller at noe produkt er vurdert eller godkjent av noen. Kjør kshana compliance-report på dine egne resultatfiler for å se hvilke rader kjøringene dine faktisk gir evidens for; se README.md.

Kildedokumenter#

Resilient Positioning, Navigation, and Timing (PNT) Conformance Framework: versjon 2,0, 26. april 2022 (DHS Science and Technology Directorate, sammen med CISA). https://www.dhs.gov/sites/default/files/2022-05/22_0531_st_resilient_pnt_conformance_framework_v2.0.pdf. Lest 2026-10-09: dokumentet er lest i sin helhet; publikasjonens landingsside ble ikke hentet.

Kobling#

Referanse	Hva det ber om (parafrasert)	Kshana-utdata som gir belegg for det	Hull
Seksjon 5,2 (Prevent, Respond, Recover)	Resiliens beskrives som tre funksjoner: å forebygge skade, å respondere (oppdage, rapportere, avbøte, begrense) og å gjenopprette. Deteksjon er sannsynlighetsbasert, så både falske alarmer og uoppdagede hendelser teller.	Tillitsvurdering av mottakerlogg; Deteksjon av spoofing og meaconing; Holdover og coasting	Forebygging er en egenskap ved produktets utforming som ingen simuleringsutdata viser. Deteksjonsstatistikk fra en syntetisk kjøring eller en kjøring med én økt er ikke en målt rate for falske alarmer eller uoppdagede hendelser for et produkt i drift.
Nivå 1, krav 1	Kontroller at lagrede data som kommer fra eksterne kilder stemmer med formatene og verdiområdene i de relevante standardene.	ingen	En egenskap ved programvaresikring og inndatavalidering i produktet som testes. Kshana inspiserer ikke et produkts håndtering av inndata.
Nivå 1, krav 2	Tillat full manuell gjenoppretting ved å tømme eller tilbakestille minnet, slik at systemet går tilbake til definert ytelse når trusselen er borte.	Tillitsvurdering av mottakerlogg	En mottakerlogg viser når en posisjonsbestemmelse ble ikke-tiltrodd og når den ble gjenopprettet; den viser ikke at en manuell tilbakestilling tømmer hver lagrede tilstand.
Nivå 1, krav 3	Last inn eller oppdater fastvare på en sikker måte.	ingen	Sikkerheten ved fastvareoppdatering ligger utenfor det noen Kshana-utdata observerer.
Nivå 2, krav 4	Identifiser kompromitterte PNT-kilder og hindre dem i å ødelegge løsningen.	Deteksjon av spoofing og meaconing; Tillitsvurdering av mottakerlogg; Integritetsovervåking og beskyttelsesnivåer	Kshana scorer detektorer og monitorer den modellerer eller kjører over en logg; om et produkts egen kildeutelatelse virker, krever produktets interne tilstand, ikke bare loggen.
Nivå 2, krav 5	Gjenopprett kilder og systemet automatisk uten å avbryte utdataene; en løsning leveres fortsatt under trusselen, muligens med ubegrenset forringelse.	Holdover og coasting; Tillitsvurdering av mottakerlogg	Holdover-kjøringer avgrenser modellert drift for en oppgitt klokke- eller treghetsmodell, ikke produktets egen gjenopprettingsatferd.
Nivå 3, krav 6	Korrupte data fra én kilde må ikke forurense en annen kilde.	Alternative og mangfoldige PNT-kilder	Kshana kjører kilder side om side; kildeisolasjon inne i et produkt krever designgjennomgang eller feilinjeksjon i produktet.
Nivå 3, krav 7	Krysskontroller løsningene fra alle kilder, og hold forringelsen under en trussel begrenset.	Integritetsovervåking og beskyttelsesnivåer; Holdover og coasting; Alternative og mangfoldige PNT-kilder	Begrenset forringelse vises for de modellerte sensorene; produktets egen krysskontroll observeres ikke.
Nivå 4, krav 8	Bruk kilder med ulike teknologier mot fellesmodustrusler, uten forringelse under trusselen.	Alternative og mangfoldige PNT-kilder; Effekter av jamming på linkbudsjettet	Et fellesmodusargument krever det virkelige produktets kildesett og en trussel som spenner over dem; et scenario oppgir én, det beviser ikke at produktet ikke har noen felles svakhet.
Seksjon 5,5 (fellesmodus)	Ulike mekanismer må ikke dele en svakhet: for eksempel slår en jammer som dekker to bånd ut båndmangfoldet.	Effekter av jamming på linkbudsjettet; Resiliensscoring over trusselensembler; Alternative og mangfoldige PNT-kilder	Scoringen bruker et syntetisk trusselensemble, oppgitt som sådan; det er ikke feltdata.
Seksjonene 8,1 til 8,3 (evaluering)	Evalueringen kombinerer statisk analyse med dynamisk analyse, der testvektorer representerer trusler; testklassene er kildesvikt, interferens og interne feil. Simulatorer nevnes som testmetode.	Tillitsvurdering av mottakerlogg; Effekter av jamming på linkbudsjettet; Deteksjon av spoofing og meaconing	Eksportert bevegelse og eksporterte hendelser kan drive en laboratoriesimulator (docs/TEST-BENCH.md). Kshana skriver ikke noe signal, så simulatoren og dens autoriserte operatør leverer trusselen.
Seksjon 8,6 (elementer i testplanen)	En testplan oppgir nivået, kravet, inndataene, referansene, nødvendig datatilgang, prosedyren med kriterier for bestått eller ikke bestått, resultatene og merknader.	Reproduserbart opphav for kjøringer; Tillitsvurdering av mottakerlogg	Kriteriene for bestått eller ikke bestått velges av den som vurderer; Kshana registrerer inndataene, terskelene og hashene den kjørte med.