Er sensitive data sikre i organisasjonen din? Test av PII og PHI -samsvar

Hvis organisasjonen din regelmessig håndterer sensitive data, må du implementere strategier for datasikkerhet for å beskytte ikke bare personene som dataene tilhører, men også organisasjonen din mot å bryte føderale lover (f.eks. HIPPA, GDPR, etc.). Dette påvirker organisasjoner i bransjer som helse, bank, myndigheter, juridisk ... egentlig enhver organisasjon som håndterer sensitive data.

Vi snakker om PII (personlig identifiserbar informasjon) og PHI (beskyttet helseinformasjon). Eksempler på PII-

• Personnummer
• bankkontoer
• Fulle navn
• Passnummer osv.

Eksempler på PHI-

• Helsejournaler
• Lab-resultater
• Medisinske regninger og lignende, som inkluderer individuelle identifikatorer

Metoder for beskyttelse av følsomme data

Noen kunder har beskrevet metodene sine som scener du kan forestille deg i en film du har sett ... visualisere en gruppe mennesker bevæpnet med de nødvendige sikkerhetsklareringene som blir klemt i et låst rom, uten vinduer, for å kontrollere rapportutskriftene manuelt for å sikre at sensitiv informasjon er ikke inkludert. Selv om dette gir en dramatisk filmscene, er det ikke den mest idiotsikre eller den mest effektive måten å teste rapporter for sensitiv informasjon på. Og med fjerntliggende krav til Covid-19 arbeidskraft, er dette rett og slett ikke gjennomførbart for øyeblikket.

Vi har hjulpet flere av våre kunder med å implementere kraften i automatiserte tester for å dynamisk teste Cognos -rapportutgangene. Denne teststrategien fanger rapportene tidlig, så snart de faller ut av samsvar, og før de ender i produksjon for å ende opp i feil hender. Det er alltid en god idé å vite hvor det nærmeste trygdekontoret til deg er, for eksempel Trygdekontorer i Nevada, hvis det verste skulle skje, ettersom teamet på ditt lokale kontor vet hvordan de skal håndtere situasjonen.

Verdien av å teste tidlig i utviklingssyklusene

Å oppdage sårbarheter i datasikkerheten tidlig i utviklingsfasen kan bidra til å unngå fremtidige bøter og sanksjoner fra regjeringen. Ifølge US Department of Health og Human Services, til dags dato, har Office for Civil Rights (OCR) "avgjort eller pålagt en sivil pengestraff i 75 saker som resulterer i et totalt dollarbeløp på $ 116,303,582.00." Det er over 1.5 millioner dollar per sak! Og ifølge HIPAA Journal "unnlatelse av å utføre en organisasjonsomfattende risikoanalyse er et av de vanligste HIPAA-bruddene som resulterer i en økonomisk straff."

Bortsett fra å unngå straff fra staten, er det generelt viktig å oppdage feil tidlig i utviklingssyklusen siden dette er stadiet der problemer er mye enklere og billigere å fikse. Som et resultat er hovedmålet med denne øvelsen å bruke MotioCIsin regresjonstest for enkelt å identifisere slike feil og derfor forhindre dem tidlig i utviklingssyklusen.

La oss ta en titt på hvordan du konfigurerer testing. Vi starter med å sette opp vårt Cognos -miljø, og deretter forklarer vi hvordan vi konfigurerer automatisert testing for PHI- og PII -data for vårt eksempel. Vi vil også bruke de samme testtilfellene i produksjonsmiljøet for et ekstra nivå av samsvar og sikkerhetskontroll.

Oppsett av PHI & PII Cognos -miljø

Vårt utvalg av Cognos -miljø (figur 1) består av flere rapporter, som hver inneholder en blanding av PII- og PHI -sensitive data (f.eks. Diagnosekode, resept, personnummer, pasientens etternavn og etc.) og minimalt sensitive data (f.eks. Pasient fornavn, besøksdato osv.).

Det er to Cognos -roller, TillatPII og TillatPHI, som avgjør om noen av de sensitive dataene gjengis når rapporter utføres. (Tabell 1)

Tabell 1: Cognos -roller som styrer gjengivelse av sensitive data.

For eksempel, en bruker som mangler begge våre Cognos -roller, bør rapporten "Pasient daglig inntak" se slik ut (figur 2):

Som du kan se, er alle PHI- og PII -data fullstendig skjult fra at brukeren mangler medlemskap i begge "AllowPHI/PII" -roller.

La oss kjøre rapporten med en bruker som er medlem av “AllowPII” -rollen, noe som betyr at vi forventer at denne brukeren bare kan se PII -data (figur 3):

Og du kan se her at både personnummer og etternavn -kolonnene dukker opp på riktig måte uten noen redigering.

Så langt har vi fått et glimt av den mytiske klinikkens Cognos-miljø, og alt vi har sett hittil er Cognos rollebaserte datasikkerhet som mange av dere kanskje allerede har implementert i deres egne Cognos-miljøer. Dette vil da bringe oss til hovedspørsmålet som bærere av sensitiv data håper aldri ville måtte møte:

Hva om noen følsomme data, etter litt tungt utviklingsarbeid, glir gjennom og begynner å dukke opp for brukere som ikke skal se det?

Feil er absolutt uunngåelig, så senere i bloggen vil vi bruke den MotioCIregresjonstest for å holde et våkent øye med rapportene våre for å sikre at private data aldri blir utsatt for det utilsiktede publikummet.

Forstå samsvarstesting for Cognos

Som nevnt i forrige seksjon, kan enkle feil i rapportering eller modellering av rapporter forårsake uønsket oppførsel i rapporteringen i Cognos -miljøet. Og hvis disse endringene ikke er fanget opp, har de potensial til å snike seg inn i produksjonsmiljøet ditt. Det som ville være enda mer katastrofalt er at hvis disse uønskede endringene inkluderer eksponering av private data for et utilsiktet publikum.

For eksempel en bruker uten å være medlem av noen av dem TillatPII or TillatPHI Cognos -roller skal ikke se verken PII- eller PHI -private data i vårt prøve -Cognos -miljø. Som du kan se nedenfor (figur 4), har imidlertid en enkel endring i FM -modellen ført til at diagnosebeskrivelsen og pasientens SSN -nummer ble utsatt for en slik bruker, noe som er et STORT brudd på den føderale HIPAA sikkerhetsregelen.

Før du flytter ting til MotioCI, vil vi først opprette tre testbrukere i vårt Cognos -miljø og tildele dem til våre to roller på følgende måte (tabell 2):

Tabell 2: Testing av Cognos -brukerkontoer med sine tildelte roller.

Disse testbrukerkontoene vil senere bli brukt i MotioCI for regresjonstesting av rapportene våre som inneholder sensitive PII- og PHI -data. Våre testresultater vil avhenge av synligheten av sensitive data for hver bruker i henhold til rollemedlemskapet.

Nå som vi har satt opp testbrukerne våre, er vi klare til å konfigurere regresjonstesting i MotioCI.

MotioCI Miljøoppsett

Vårt prøvemiljø består av utviklings-, UAT- og produksjonskognos -forekomster. Selv om MotioCI lar oss logge inn på alle tre samtidig, vil vi begynne oppsettet av regresjonstesting i utviklingsmiljøet i tre forskjellige faser.

Når det gjelder regresjonstesting i MotioCI, En påstand er en individuell sjekk eller "test" som en testsak utfører på et objekt i din MotioCI for eksempel en rapport, mappe eller pakke. Påstanden som vil gjøre jobben med å teste rapportutdataene for sensitive data kalles Sensitiv datatest (Figur 7). Dette er en tilpasset påstand som vi har satt sammen for denne øvelsen. Nedenfor kan du se påstandstype som i utgangspunktet fungerer som hovedmalen som er kopiert for å teste saker i hele vår MotioCI miljø. Mer om dette senere.

Noen påstander gir noen brukerjusterbar funksjonalitet gjennom en ledetekstvindu. Her kan du endre hvordan du vil at en gitt påstand skal teste en gitt Cognos -rapport. Figur 8 nedenfor viser ledetekstvindu av vår påstand som vi vil bruke til å teste våre Cognos -rapporter som inneholder sensitive data.

Den øverste markerte delen i figur 8 viser testalternativene for PII- og PHI -sensitive data. Dette lar deg gjøre påstandstesten om rapporten enten må vise eller skjule PII- eller PHI -dataene. Vi vil gjøre endringer i disse to alternativene når vi begynner å lage testcases for hver av våre tre testbrukere.

Den midtre markerte delen i figur 8 viser navnene på kolonnene som inneholder PHI -sensitive data i rapportene våre. Selv om vårt prøvemiljø består av kolonner med navnene ICD10 Diag Code, Diagnosis Description, Procedure og Rx, kan du absolutt endre denne listen for å passe dine behov.

Til slutt viser den nederste markerte delen i figur 8 e -postalternativene. I tilfelle feil, vil denne påstanden sende en detaljert e -postmelding til mottakeren som er konfigurert i denne delen.

Fase I: Rapporter som bare viser PII

La oss lage et prosjekt under Utvikling eksempel i MotioCI og ring det Tillat bare PII. Vi kan gjøre det ved først å høyreklikke på Utvikling forekomstnode i MotioCI navigasjonstreet og velge Legg til prosjekt alternativet (Figur 9).

De Legg til prosjektveiviser tar deg gjennom noen trinn for å velge banene som trengs for prosjektet ditt. I vårt eksempel finnes alle rapportene som inneholder PII- og PHI -sensitive data under Pasientdata mappe. Når du sjekker denne overordnede mappen, blir alle de underliggende rapportene automatisk inkludert (figur 10 og 11).

Siden alle rapportene i dette prosjektet forventes å tillate at alle PII -data vises og alle PHI blir skjult, må vi konfigurere vår påstandstype med de riktige innstillingene før vi legger til noen testcases (figur 12). Det betyr at du setter de to testalternativene på samme påstand ledetekstvindu som vi så før i figur 8.

Nå er vi klare til å legge til våre testtilfeller i rapportene våre. For å gjøre det, høyreklikker du på prosjektnoden (dvs. Tillat bare PII prosjekt) i MotioCI og velg Generer testtilfeller alternativ (Figur 13). Dette starter veiviseren for generering av testsaker som lar oss lage et stort antall testcases for alle rapportene i prosjektet.

De Generer testkasse veiviseren vil også tillate oss å velge utdataformatene for testtilfellet som vi ønsker å utføre tester på. For vårt prøvemiljø valgte jeg CSV -utgangen. Veiviseren lar oss også velge påstandene som hver testcase vil bruke for selve testingen. Og for oss ville det være Sensitiv datatest påstand. Du kan se begge disse alternativene uthevet nedenfor (Figur 14).

Etter å ha klikket "OK" vil du bli tatt tilbake til MotioCI startskjermbildet, hvor du vil kunne se alle rapportene våre som hver inneholder en enkelt testcase og hver inneholder vår eneste påstand (figur 15).

Til slutt må vi konfigurere alle testtilfellene for å utføre sine foreldre -rapporter ved hjelp av riktig Cognos -bruker (f.eks. En av de tre testbrukerne som vi konfigurerte i Cognos før vi satte opp ting i MotioCI). Og siden vi for dette prosjektet tester for å sikre at PHI -innholdet er det ikke vises til brukere som bare har lov til å se PII -data, må vi angi at alle testtilfellene skal kjøres med TestBrukerA (se tabell 2).

Først kan dette høres ut som en kjedelig oppgave, men heldig for oss kan vi sette brukeren på prosjektnivå som deretter vil arves av ALLE de underliggende testtilfellene i prosjektet. For å gjøre det, på det venstre navigasjonstreet, skal vi klikke på prosjektnoden ( Tillat bare PII prosjekt) og velg deretter Prosjektinnstillinger i midten av skjermen. Deretter, under Testing delen, vil vi se et alternativ for å endre legitimasjonen (Figur 16):

Etter å ha klikket på Rediger knappen foran Credentials alternativet, vil vi bli presentert for Rediger legitimasjon vindu. Vi går videre og skriver inn legitimasjonen for TestBrukerA (Figur 17).

Vi ser nå den nye brukeren gjenspeiles i Testing delen av Prosjektinnstillinger kategorien (Figur 18).

Nå er vi klare og klare til å utføre alle testene våre.

For å gjøre det, klikker vi på Tillat bare PII prosjektet, og i midten vil vi bli presentert for test Cases -fanen som viser alle testtilfellene i prosjektet. Siden vi fremdeles ikke har utført noe, ville vi se status viser som Ingen resultater. For å utføre alle testtilfellene, klikker vi på den lille pilen ved Kjør knappen og velg Kjør alle alternativet (Figur 19).

MotioCI vil nå utføre alle testtilfellene og presentere resultatene når de er ferdige (Figur 20).

Som du kan se, lyktes alle våre testcases med unntak av Utålmodig rapportere. Så, la oss ta en titt på resultatene. For å gjøre det klikker vi på det blå tidsstempelet under Resultat kolonne og se på detaljene i Figur 21.

Under Påstandsresultater nå kan vi se at rapporten vår bryter kravene til samsvar med PHI. Vi kan laste ned CSV -rapportutdata fra Test Case-utganger ved å klikke på CSV -ikonet (Figur 21).

Som du kan se i vår rapport (Figur 22), i tillegg til PII -dataene som er greit for TestUserA å ha tilgang til, kan vi se PHI -prosedyredataene som bringer rapporten i strid med den føderale HIPAA -sikkerhetsregelen.

Hvis du husker fra vinduet for påstandsinnstillinger, skulle vi også motta en e -postvarsel for denne feilen. La oss se hvordan det ser ut (Figur 23):

På dette tidspunktet er vi ferdige med å teste for å sikre at PHI -data er skjult for brukere uten nødvendig TillatPHI Cognos rolle. Nå er vi klare til å utvide testen til at PII -data blir skjult for brukere som ikke trenger det nødvendige TillatPII Cognos rolle.

Fase II: Rapporter som bare viser PHI

Før vi oppretter det nye prosjektet, la oss først redigere alternativene for vår hovedpåstand for å sikre at det nå tester for at alle PII skal være skjult og at alle PHI skal vises (Figur 24).

Med vår påstand nå konfigurert, er vi nå klare til å lage det nye prosjektet og våre testcases. For det vil vi bare følge de samme trinnene som i "Fase I" og lage et prosjekt kalt Tillat bare PHI. La oss ikke glemme å legge til legitimasjonene til TestBrukerB som prosjektbruker.

Når vi er ferdige med alle konfigurasjonstrinnene, vil vi utføre alle testtilfellene som vi gjorde i fase I. I vårt prøvemiljø har vi denne gangen en annen rapport som ser ut til å være i brudd på HIPAA (Figur 25).

Videre undersøkelse av testtilfellet resultatene av Pasient daglig inntak rapporten viser at vår rapport viser pasientnummer for det utilsiktede publikummet (figur 26).

Nedlasting og åpning av CSV -filen vil ytterligere bekrefte resultatene av testen vår (Figur 27):

Som du kan se i figur 27, maskerer imidlertid rapporten vår pasientens etternavn -kolonne (også en PII) på riktig måte ved å bare vise initialen.

På dette tidspunktet burde miljøet vårt ha oppnådd full regresjonstesting av både PHI- og PII -sensitive data ved å bruke Cognos 'rollebaserte datasikkerhet. Våre testcases vil hver utføre sin overordnede rapport og analysere utdataene i henhold til testkonfigurasjonen som er satt innenfor deres underliggende påstander og fortelle oss om noen av rapportene faller ut av linje.

En av de viktigste skillene mellom testmiljøet vårt og det du kan ha i miljøet ditt, er absolutt størrelsen. Et typisk Cognos -miljø har sannsynligvis opptil hundrevis eller tusenvis av rapporter, og utførelse av alle samtidig, slik vi har gjort i vårt lille utvalgsmiljø, kan påvirke Cognos ytelse. Med MotioCIsine testskript, kan du imidlertid planlegge testtilfellene dine for å kjøre i mindre grupper i friminutt, og dermed sikre optimal ytelse for Cognos -miljøet ditt i trafikken.

God testpraksis under utvikling

Mellom de planlagte kjøretidene kan du imidlertid fortsatt kjøre så mange individuelle testtilfeller manuelt som du ønsker. Et godt eksempel ville være mens du utvikler en rapport, kan du kjøre testsaken for å sikre at endringene ikke har skapt noen HIPAA -brudd.

Automatisering av Cognos -testtilfeller

Tilbake til MotioCI, på navigasjonstreet, utvider vi et av prosjektene vi opprettet for å avsløre innholdet. Dette bør avsløre en node som heter Test skript. Når du utvider den, vises et sett med testskript som ble opprettet automatisk da du først opprettet prosjektet ditt (Figur 28).

Per definisjon a testskript er en komponent i et prosjekt som velger testcases som tilhører et prosjekt basert på spesifiserte kriterier. Du kan planlegge testskript eller kjøre dem manuelt. Når du kjører et testskript, MotioCI kjører alle testcases som overholder skriptkriteriene.

I vårt tilfelle ønsker vi å sette alle testtilfellene på en tidsplan. Så for å gjøre det klikker vi på Alle testskriptet fra navigasjonstreet, og klikk deretter på Test skriptinnstillinger kategorien som ligger midt på skjermen (Figur 29).

Deretter velger vi Legg til tidsplan alternativ. Her kan vi nå sette en tidsplan for testskriptet vårt. Jeg vil fortsette og la testcallene våre kjøre daglig mandag til fredag ​​klokken 3 (Figur 00).

Det er det! Vi kan nå sjekke innboksen vår hver morgen for å finne ut om noen av rapportene våre ikke er i samsvar. Vi kan også se alle de mislykkede rapportene ved å klikke på Endret eller mislyktes test script og alle de mislykkede test tilfellene vil bli presentert for oss under test Cases panel (Figur 31).

konklusjonen

Å falle ut av overholdelse av HIPPA, GDPR og andre føderale forskrifter rundt sensitiv informasjon og personvern kan være ganske kostbart, rundt $ 1.5 millioner per sak funnet i strid, faktisk.

Ved å implementere en automatisert teststrategi for å håndtere samsvarstesting, vil du ha det ekstra sikkerhetslaget og tryggheten at du overholder lovene. Utover mandater om personvern kan automatisert testing være til fordel for alle typer bransjer og alle slags testkrav organisasjonen din ønsker å sette på plass.

Hvordan kan vi hjelpe?

Hvis du vil se webinaret om dette bloggtemaet, få tilgang til den her. Eller, kontakt oss for å diskutere Cognos -testspørsmålene dine ytterligere.