Definer tre forskjellige typer ufullstendighet
En ufullstendig innsamling kan bety at forventede rapporter aldri kom, at en enkelt fil er avkortet, eller at en velutformet rapport mangler de observasjonene som trengs for en bestemt konklusjon. Det er forskjellige forhold. En parser kan ikke gjenopprette fraværende senderobservasjoner ved å akseptere skadet XML, og et gyldig dokument fastslår ikke at hver mottaker rapporterte all relevant trafikk.
Begynn med å navngi nivået som vurderes: transportkvittering, artefaktintegritet, syntaks og skjema, feltkonsistens, herkomst eller populasjonsdekning. Ta vare på rapportidentifikatoren, rapporteringsintervallet og inntakskonteksten der dette er tilgjengelig. Ikke presenter en generisk "ugyldig rapport"-telling som om den forklarer hvilket lag som mislyktes. RFC 9990 skiller rapportgenerering, levering og evaluering, og gir grunnlaget for en lagdelt gjennomgang i stedet for én binær helsepoengsum. RFC 9990 , avsnitt 3.1, 3.5 og 9
Behandle parsergrensen som sikkerhetssensitiv
Samlet rapport filer er ikke-klarert input. RFC 9990 beskriver spesifikt ressursutmattelsesangrep mot arkivdekomprimering og XML-parsere, inkludert komprimerte og XML-bomber. En rapport som kommer gjennom en forventet postboks eller refererer til et kjent domene, blir ikke trygt å behandle uten grenser. Ekstern rapporteringstillatelse gjelder mottakerforholdet, ikke ufarligheten til vilkårlig filinnhold.
Et foreslått parserdesign bør pålegge grenser før dyrt arbeid: meldings- og vedleggsstørrelse, dekomprimerte byte, komprimeringsforhold der det er nyttig, nesting eller elementantall, behandlingstid og køarbeid. Det bør deaktivere farlige XML-funksjoner som unødvendig ekstern enhetsoppløsning og unngå å hente eksterne ressurser bare fordi et dokument navngir dem. Dette er defensive designanbefalinger, ikke påstander om at en bestemt parser eller EmailAuth funksjon er konfigurert. RFC 9990 , avsnitt 8.1
Valider struktur uten å stille omskriving av bevis
Ta vare på den originale artefakten eller en passende tilgangskontrollert beviskopi før transformasjoner, underlagt en definert oppbevaringsbeslutning. Identifiser medietype, komprimeringshåndtering, dokumentformat og skjemaversjon. RFC 9990 definerer aggregert XML-struktur og utvidelseshåndtering. En parser bør skille en støttet utvidelse fra misformet struktur, og bør ikke stille tvinge til vilkårlige inndata i en klarert rapport bare fordi noen kjente elementnavn vises.
Registrer feil med et nyttig presisjonsnivå uten å lekke sensitivt innhold inn i generelle logger. Et avkortet dokument, feil rotstruktur og format som ikke støttes, bør ha tydelige årsaker. Hvis en implementering tilbyr delvis utvinning, må utdata forbli tydelig merket som ufullstendig og uegnet for krav som krever de manglende feltene. Ikke kast feiltilstanden mens du beholder tellinger med attraktivt utseende. RFC 9990 , seksjon 5 og vedlegg A
Sjekk konsistens og herkomst etter parsing
Syntaktisk suksess beviser ikke sannferdig innhold. RFC 9990 advarer om at rapportdata kan forfalskes for å påvirke politiske beslutninger eller overbelaste rapportmottakssystemer. Bevar avsender- og transportkonteksten tilgjengelig for innsamlingssystemet, og hold den rapporterende organisasjonens påståtte identitet atskilt fra bevis som autentiserer den. En rapports XML-krav alene skal ikke skape kundeeierskap eller endre en håndhevingspolicy.
Foreslåtte semantiske kontroller bør undersøke rapporteringsintervallrekkefølge, felttyper og områder, telletolkning, policykontekst og forhold mellom evaluerte resultater og autentiseringsdetaljer. Forskjeller kan oppstå fra policyendringer i løpet av en rapporteringsperiode eller ulike observasjonskontekster, så en inkonsekvens fortjener klassifisering før en anklage om forfalskning. Dupliserte eller overlappende rapporter trenger også en dokumentert håndteringsstrategi i stedet for blindt tillegg til totaler. RFC 9990 , avsnitt 3.3 og 8.2
Design en sikker armaturpakke før implementeringskrav
Akseptplanen bør inkludere en gyldig minimumsrapport, en støttet utvidelsessak, en avkortet artefakt, misformet XML, et feiltypefelt, et motstridende intervall, en duplikatrapport og en ressursutmattelseskandidat. Bruk inerte, avgrensede lokale armaturer hvis størrelse og forventede utfall er deklarert. Dette manuskriptet gir ikke kjørbare ondsinnede nyttelaster eller påstår at noen test har kjørt.
Registrer identifikator, hash, tiltenkt format, komprimerte og utvidede størrelsesforutsetninger, ressursbudsjett, forventet klassifisering og gjenopprettingshandling for hver armatur. Det forventede resultatet bør skille avvise, karantene, trygt akseptere eller akseptere med en eksplisitt begrensning. En test som bare unngår en krasj, viser ikke at input ikke kan forurense samlet statistikk eller krysse leietakergrenser.
Hold gjenopprettingsadferd i samme aksepttabell. Etter å ha avvist én artefakt, bør arbeideren frigjøre ressurser, bevare en avgrenset diagnostisk post og fortsette å behandle ikke-relatert gyldig arbeid under den foreslåtte utformingen. Den faktiske implementeringen må demonstrere denne atferden. En armaturpakke uten ressursmålinger eller gjenopprettingsbevis er en ufullstendig sikkerhetsevaluering, selv om testnavnene høres omfattende ut.
Fiktiv diagnose: en avkortet fil og en plausibel duplikat
Se for deg en fiktiv daglig samling som inneholder ett gyldig samlet dokument, et andre vedlegg avkortet under overføring og en tredje fil som gjentar en tidligere rapportidentifikator og intervall med forskjellige tellinger. Ingen rapporter ble lastet opp eller analysert for dette eksemplet. Den foreslåtte arbeidsflyten isolerer først den avkortede artefakten som en strukturell feil i stedet for å tolke dens overlevende elementer som fullstendig daglig dekning.
Det motstridende duplikatet mottar en separat konsistens- og herkomstgjennomgang. Det kan representere en korrigert rapport, et leveringsduplikat med endret innhold eller falske data; filen alene løser ikke dette spørsmålet. Samleren bør bevare forholdet og unngå stille å summere begge versjonene til et trenddiagram. Enhver avstemmingsbeslutning trenger en nedtegnet begrunnelse og omfang.
Den gyldige rapporten forblir kvalifisert for normal behandling under de foreslåtte kontrollene, men dashbordet bør avsløre at innsamlingskvaliteten for intervallet er ufullstendig. Den skal ikke vise fraværet av analyserte feil fra den avkortede artefakten som bevis på at autentiseringen ble forbedret. Dette skillet beskytter analytiske konklusjoner uten å gjøre alle skadede filer til en påstand om den rapporterende organisasjonen som ikke er støttet.
Oppbevaring, feilrapporter og utgivelsesstatus
Velg oppbevaring i henhold til diagnostisk behov, personvernforpliktelser og autorisert tilgang, i stedet for å finne opp et universelt antall dager. RFC 9990 overlater lagringsbeslutninger etter behandling til evaluatoren. Oppbevar råartefakter, normaliserte poster og feillogger under separat begrunnede tilgangs- og oppbevaringsregler. En foreslått oppryddingsprosess må ikke beskrives som allerede sletting av data eller som tilfredsstiller et lovkrav.
Feilrapporter er et eget format og personvernoverflate under RFC 9991. Ikke mat dem inn i en samlet parser eller anta at det mer detaljerte innholdet deres kan deles der det er tillatt med aggregerte sammendrag. Rut ustøttede rapporttyper til en klar, avgrenset håndteringsbane og få de nødvendige datadelingsbeslutningene før reell behandling. RFC 9990 , avsnitt 9.3; RFC 9991 , seksjon 4 og 7
Katalogen krever en ondsinnet og misformet fixturpakke med ressursgrenser, forventede resultater og gjenopprettingsadferd. Den suiten og dens utførelse forblir åpen. Dette utkastet gir kun et designrammeverk og fiktiv diagnose. Originale bevis, menneskelig vurdering, kildeanvendbarhet, produksjonsruter, visuell tilgjengelighet og eierutgivelse forblir åpne. Ingen faktisk rapport, parserkjøring, ekstern opplasting eller oppbevaring av produksjonsdata ble utført.