Om din organisation regelbundet hanterar känslig data måste du implementera strategier för överensstämmelse av datasäkerhet för att skydda inte bara de individer som uppgifterna tillhör utan också din organisation från att bryta mot federala lagar (t.ex. HIPPA, GDPR, etc.). Detta påverkar organisationer i branscher som vård, bank, regering, juridik ... egentligen alla organisationer som hanterar känslig information.
Vi pratar om PII (personligt identifierbar information) och PHI (skyddad hälsoinformation). Exempel på PII-
- Personnummer
- bankkonton
- Fullständiga namn
- Passnummer etc.
Exempel på PHI-
- Hälsojournaler
- Lab-resultat
- Medicinska räkningar och liknande, som inkluderar individuella identifierare
Metoder för att skydda känsliga data
Vissa kunder har beskrivit deras metoder som scener du kan tänka dig i någon film du har tittat på ... visualisera en grupp människor beväpnade med sina nödvändiga säkerhetsavklaringar som ligger ihop i ett låst rum, utan fönster, för att manuellt kontrollera rapportutskrifter för att säkerställa att känslig information ingår inte. Även om detta ger en dramatisk filmscen, är det inte det mest idiotsäkra eller det mest effektiva sättet att testa rapporter för känslig information. Och med avlägsna krav på Covid-19-arbetskraft är detta helt enkelt inte genomförbart just nu.
Vi har hjälpt flera av våra kunder att implementera kraften i automatiserade tester för att dynamiskt testa deras Cognos -rapportutgångar. Denna teststrategi fångar rapporterna tidigt, så snart de faller ur överensstämmelse och innan de hamnar i produktion för att hamna i fel händer. Det är alltid en bra idé att veta var det närmaste socialkontoret till dig är, som Socialförsäkringskontor i Nevada, om det värsta skulle hända, eftersom teamet på ditt lokala kontor vet hur man hanterar situationen.
Värdet av att testa tidigt i utvecklingscyklerna
Att upptäcka sårbarheter i datasäkerhet tidigt i utvecklingsstadiet kan hjälpa till att undvika framtida böter och sanktioner från regeringen. Enligt US Department of Health and Human Services, hittills har Office for Civil Rights (OCR) "löst eller ålagts ett civilrättsligt straff i 75 fall som resulterar i ett totalt dollarbelopp på $ 116,303,582.00 1.5 XNUMX." Det är över XNUMX miljoner dollar per fall! Och enligt HIPAA Journal "misslyckandet med att utföra en organisationsövergripande riskanalys är en av de vanligaste HIPAA-kränkningarna som leder till ett ekonomiskt straff."
Bortsett från att undvika regeringens påföljder är det i allmänhet viktigt att upptäcka fel tidigt i utvecklingscykeln, eftersom detta är det stadium där problem är mycket lättare och billigare att åtgärda. Som ett resultat är huvudmålet med denna övning att använda MotioCIs regressionstest för att enkelt identifiera sådana misstag och därför förhindra dem tidigt i utvecklingscykeln.
Låt oss ta en titt på hur du ställer in tester. Vi börjar med att konfigurera vår Cognos -miljö och sedan förklarar vi hur vi ställer in automatiserade tester för PHI- och PII -data för vårt exempel. Vi kommer också att använda samma testfall i produktionsmiljön för en ytterligare nivå av överensstämmelse och säkerhetskontroll.
PHI & PII Cognos -miljö inställd
Vårt prov Cognos -miljö (figur 1) består av flera rapporter, var och en innehållande en blandning av PII- och PHI -känslig data (t.ex. diagnoskod, recept, personnummer, patientens efternamn och etc.) och minimalt känsliga data (t.ex. patient förnamn, besöksdatum etc.).
Figur 1: Vårt prov Cognos miljö.
Det finns två Cognos -roller, TillåtPII och TillåtPHI, som avgör om någon av de känsliga uppgifterna återges när rapporter körs. (Bord 1)
| Cognos roller | Anmärkningar |
| TillåtPII | Medlemmar i denna roll kan se alla PII -uppgifter (dvs. personnummer och patientnamn) i Cognos -rapporter. |
| TillåtPHI | Medlemmar i denna roll kan se alla PHI -data (t.ex. ICD10 -diagnoskoder, detaljerad diagnosbeskrivning etc.) i Cognos -rapporter. |
Tabell 1: Cognos -roller som styr återgivningen av känslig data.
Till exempel, en användare som saknar båda våra Cognos -roller, deras "Patient Daily Intake" -rapport ska se ut så här (figur 2):
Figur 2: Rapportutmatning producerad av en användare som saknar både AllowPII- och AllowPHI -roller.
Som du kan se är alla PHI- och PII -data helt fördunklade från att användaren saknar medlemskap i båda "AllowPHI/PII" -rollerna.
Låt oss nu köra rapporten med en användare som är medlem i "AllowPII" -rollen, vilket innebär att vi förväntar oss att den här användaren bara kan se PII -data (figur 3):
Figur 3: Rapportutmatning som produceras av en användare som är medlem i AllowPII -rollen och INTE AllowPHI -rollen.
Och du kan se här att både kolumnerna för personnummer och efternamn visas på rätt sätt utan någon redigering.
Hittills har vi fått en glimt av vår mytiska kliniks Cognos-miljö och allt vi hittills har sett är Cognos rollbaserade datasäkerhet som många av er kanske redan har implementerat i era egna Cognos-miljöer. Detta skulle då föra oss till huvudfrågan som bärare av känslig data hoppas aldrig skulle behöva ställas inför:
Tänk om vissa känsliga data, efter en omfattande utvecklingsansträngning, glider igenom och börjar dyka upp för användare som inte ska se den?
Misstag är verkligen oundvikliga, så senare i bloggen kommer vi att använda MotioCIs regressionstest för att hålla ett vakande öga på våra rapporter för att säkerställa att privat data aldrig blir utsatt för den oavsiktliga publiken.
Förstå efterlevnadstest för Cognos
Som nämnts i föregående avsnitt kan enkla misstag vid rapportskapande eller modellering orsaka oönskat beteende i rapporterna i din Cognos -miljö. Och om dessa förändringar inte fångas upp har de potential att smyga sig in i din produktionsmiljö. Vad som skulle vara ännu mer katastrofalt är att om dessa oönskade förändringar inkluderar exponering av privat data för en oavsiktlig publik.
Till exempel en användare utan att vara medlem i någon av TillåtPII or TillåtPHI Cognos roller är inte tänkt att se vare sig PII eller PHI privata data i vår prov Cognos miljö. Men som du kan se nedan (figur 4) har en enkel ändring av FM -modellen gjort att diagnosbeskrivningen och patientens SSN -nummer har blivit utsatta för en sådan användare, vilket är en STOR överträdelse av den federala HIPAA -säkerhetsregeln.
Figur 4: En användare utan AllowPII- och AllowPHI -rollmedlemskap exponeras på något sätt för HIPAA -känslig data.
Innan du flyttar saker till MotioCIkommer vi först att skapa tre testanvändare i vår Cognos -miljö och tilldela dem till våra två roller på följande sätt (tabell 2):
| användare | Rollmedlemskap | Anmärkningar |
| TestUserA | TillåtPII | All PHI -data måste döljas för den här användaren |
| TestUserB | TillåtPHI | All PII -data måste döljas för den här användaren |
| TestUserC | Ingen | Användaren förväntas INTE se antingen PHI eller PII |
Tabell 2: Testa Cognos -användarkonton med sina tilldelade roller.
Dessa testanvändarkonton kommer senare att användas i MotioCI för regressionstestning av våra rapporter som innehåller känslig PII- och PHI -data. Våra testresultat beror på synligheten av känslig data för varje användare beroende på deras rollmedlemskap.
Nu när vi har konfigurerat våra testanvändare är vi redo att konfigurera vårt regressionstest i MotioCI.
MotioCI Miljöinställning
Vår provmiljö består av utvecklings-, UAT- och produktionskognosinstanser. Även om MotioCI tillåter oss att logga in på alla tre samtidigt, vi kommer att börja vår installation av regressionstester i utvecklingsmiljön i tre olika faser.
Figur 5: MotioCI inloggningsskärmen.
Figur 6: MotioCI startskärm som visar Cognos -instanser.
När det gäller regressionstestning i MotioCI, En påstående är en individuell kontroll eller "test" som ett testfall utför på ett objekt i din MotioCI till exempel en rapport, mapp eller paket. Påståendet som kommer att göra jobbet med att testa rapportutmatningarna för känslig data kallas Testning av överensstämmelse med känslig data (Figur 7). Detta är ett anpassat påstående som vi har sammanställt för denna övning. Nedan kan du se påstående typ som i princip fungerar som den huvudsakliga mallen som kopieras till testfall i hela vår MotioCI miljö. Mer om detta senare.
Figur 7: "Sensitive Data Compliance Testing" påstående typ. Kopior av detta påstående distribueras till testmiljön.
Vissa påståenden ger vissa användarjusterbara funktioner genom en snabbfönster. Här kan du ändra hur du vill att ett givet påstående ska testa en given Cognos -rapport. Figur 8 nedan visar snabbfönster av vårt påstående som vi kommer att använda för att testa våra Cognos -rapporter som innehåller känslig data.
Figur 8: Prompt -fönstret i påståendet "Sensitive Data Compliance Testing", vilket avslöjar alla användarjusterbara testalternativ.
Det övre markerade avsnittet i figur 8 visar testalternativen för PII- och PHI -känsliga data. Detta gör att du kan göra testet om rapporten antingen måste visa eller dölja PII- eller PHI -data. Vi kommer att göra ändringar av dessa två alternativ när vi börjar skapa testfall för var och en av våra tre testanvändare.
Det mellersta markerade avsnittet i figur 8 visar namnen på kolumnerna som innehåller PHI -känslig data i våra rapporter. Även om vår provmiljö består av kolumner med namnen på ICD10 Diag -kod, diagnosbeskrivning, procedur och Rx, kan du verkligen ändra den här listan efter dina behov.
Slutligen visar det nedre markerade avsnittet i figur 8 e -postalternativen. I händelse av ett fel skickar detta påstående ett detaljerat e -postmeddelande till mottagaren som konfigurerats i det här avsnittet.
Fas I: Rapporter som endast visar PII
Låt oss skapa ett projekt under Utveckling instans i MotioCI och kalla det Tillåt endast PII. Vi kan göra det genom att först högerklicka på Utveckling instansnod i MotioCI navigeringsträd och välja Lägg till projekt alternativ (Figur 9).
Figur 9: Skapa ett nytt projekt. I MotioCI varje projekt fungerar som en testplats för en fördefinierad del av innehållsbutiken.
Smakämnen Lägg till projektguiden tar dig igenom några steg för att välja de vägar som behövs för ditt projekt. I vårt exempel finns alla rapporter som innehåller PII- och PHI -känslig data under Patientdata mapp. Om du markerar den här överordnade mappen kommer alla underliggande rapporter automatiskt att inkluderas (figur 10 och 11).
Figur 10: Bestämning av projektets omfattning i MotioCI genom att välja sökvägar från Cognos -miljön.
Figur 11: Visar alla Cognos -objekt som valts för MotioCI projektet.
Eftersom alla rapporter i det här projektet förväntas tillåta att alla PII -data visas och alla PHI skyms, måste vi konfigurera vår påstående typ med rätt inställningar innan vi lägger till några testfall (Figur 12). Det innebär att du ställer in de två testalternativen på samma påstående snabbfönster som vi såg tidigare i figur 8.
Figur 12: PII- och PHI -testalternativ för påståendet "Sensitive Data Compliance Testing".
Nu är vi redo att lägga till våra testfall i våra rapporter. För att göra det, högerklicka på projektnoden (dvs. Tillåt endast PII projekt) i MotioCI och välj Skapa testfall alternativ (Figur 13). Detta startar guiden för att skapa testfall som gör att vi kan skapa ett stort antal testfall för alla rapporter inom projektet.
Figur 13: MotioCI kan automatiskt generera alla nödvändiga testfall på vilken nivå som helst från projektet.
Smakämnen Skapa testfodral guiden tillåter oss också att välja utmatningsformat för testfallet som vi vill utföra tester på. För vår provmiljö valde jag CSV -utdata. Guiden låter oss också välja de påståenden som varje testfall kommer att använda för själva testjobbet. Och för oss skulle det vara Testning av överensstämmelse med känslig data påstående. Du kan se båda dessa alternativ markerade nedan (Figur 14).
Figur 14: Alternativen som visas under guiden "Generera testfall".
Efter att ha klickat på "OK" kommer du tillbaka till MotioCI startskärmen, där du kommer att kunna se alla våra rapporter som var och en innehåller ett enda testfall och var och en innehåller vårt enda påstående (Figur 15).
Figur 15: MotioCI navigeringsträd som visar alla Cognos -objekt som nu alla innehåller ett testfall och det underliggande påståendet.
Slutligen måste vi konfigurera alla testfall för att köra sina överordnade rapporter med rätt Cognos -användare (t.ex. en av de tre testanvändarna som vi konfigurerade i Cognos innan vi ställde in saker i MotioCI). Och eftersom vi för detta projekt testar för att säkerställa att PHI -innehållet är det inte visas för användare som bara får se PII -data, måste vi ställa in alla testfall att köras med TestUserA (se tabell 2).
Till en början kan detta låta som en tråkig uppgift, men tur för oss kan vi ställa in användaren på projektnivå som sedan skulle ärvas av ALLA underliggande testfall inom det projektet. För att göra det, i det vänstra navigeringsträdet, kommer vi att klicka på projektnoden ( Tillåt endast PII projekt) och välj sedan Projektinställningar i mitten av skärmen. Sedan, under Testning avsnitt, kommer vi att se ett alternativ för att ändra autentiseringsuppgifterna (Figur 16):
Figur 16: Om du anger användaruppgifterna för ett projekt kommer alla testfall att köra den överordnade Cognos -rapporten i Cognos med den användaren. Detta kan skrivas över av varje enskilt testfall.
Efter att ha klickat på Redigera knappen framför referenser alternativet kommer vi att presenteras med Redigera referenser fönster. Vi kommer att fortsätta och ange referenser för TestUserA (Bild 17).
Figur 17: Fönstret "Redigera referenser" låter dig ställa in en ny användaruppgifter eller använda överordnade referenser som är inställda på Cognos -instansnivå, även känd som systemuppgifter.
Vi ser nu att den nya användaren återspeglas i Testning sektion av Projektinställningar fliken (Figur 18).
Figur 18: De nya användaruppgifterna är nu inställda på projektet.
Nu är vi klara och redo att utföra alla våra testfall.
För att göra det klickar vi på Tillåt endast PII projektet och i mitten kommer vi att presenteras med Test Cases fliken som visar alla testfall som finns i projektet. Eftersom vi fortfarande inte har utfört något skulle vi se status visar som Inga resultat. För att utföra alla testfall klickar vi på den lilla pilen vid Körning knappen och välj Kör alla alternativ (Figur 19).
Figur 19: Fliken "Testfall" innehåller ett antal åtgärder som kan utföras på hela eller delar av testfallen i bulk. Här kör vi bara alla testfall.
MotioCI kommer nu att utföra alla testfall och presentera resultaten för oss när de är klara (Figur 20).
Figur 20: Fliken "Testfall" visar körstatus för varje testfall inklusive eventuella utdata.
Som du kan se lyckades alla våra testfall med undantag för slutenvård Rapportera. Så, låt oss ta en titt på resultaten. För att göra det klickar vi på den blå tidsstämpeln under Resultat kolumn och titta på detaljerna i Figur 21.
Figur 21: Panelen "Testfallresultat" visar detaljerade resultat av testfallets utförande inklusive sökvägen för det testade objektet, påståendesresultat och eventuella utdata från rapporten.
Enligt Påstående Resultat avsnitt kan vi nu se att vår rapport bryter mot PHI -kraven. Vi kan ladda ner CSV -rapportutdata från Testfallets utgångar genom att klicka på CSV -ikonen (Figur 21).
Figur 22: CSV -rapportutmatning som visar en kolumn "Procedur" som måste ha blivit dold för testanvändaren.
Som du kan se i vår rapport (Figur 22) kan vi, förutom PII -data som är okej för TestUserA att ha tillgång till, se PHI -procedurdata som gör att rapporten bryter mot den federala HIPAA -säkerhetsregeln.
Om du kommer ihåg från fönstret för påståendeinställningar skulle vi också få ett e -postmeddelande om detta fel. Låt oss se hur det ser ut (Figur 23):
Figur 23: E -postmeddelande som skickats genom påståendet om det misslyckade testfallet, som visar ett brott mot följsamheten för känsliga uppgifter, troligen på grund av en ny förändring i rapporten.
Vid det här laget har vi testat färdigt för att säkerställa att PHI -data är dolda för användare utan att behöva TillåtPHI Cognos roll. Nu är vi redo att utvidga vår testning till att PII -data är dolda för användare som inte behöver det TillåtPII Cognos roll.
Fas II: Rapporter som endast visar PHI
Innan vi skapar det nya projektet, låt oss först redigera våra master -påståendes alternativ för att se till att det nu testar för att alla PII ska döljas och att alla PHI ska visas (Figur 24).
Figur 24: PII- och PHI -testalternativ för "Sensitive Data Compliance Testing" -påståendet som ställs in för TestUserB.
Med vårt påstående nu konfigurerat är vi nu redo att skapa det nya projektet och våra testfall. För det kommer vi bara att följa samma steg som i "Fas I" och skapa ett projekt som heter Tillåt endast PHI. Låt oss inte heller glömma att lägga till referenser för TestUserB som projektanvändare.
När vi är klara med alla konfigurationssteg kommer vi att utföra alla testfall som vi gjorde i fas I. I vår provmiljö har vi den här gången en annan rapport som verkar vara i HIPAA -kränkning (Figur 25).
Figur 25: Fliken "Testfall" som visar körstatus för varje testfall inklusive eventuella utdata.
Ytterligare undersökning av testfallets resultat av Patientens dagliga intag rapporten visar att vår rapport visar patientnummer för den oavsiktliga publiken (Figur 26).
Figur 26: Resultatet av testfallet visar ett brott mot kravet på SSN PII -överensstämmelse.
Nedladdning och öppning av CSV -filen kommer ytterligare att bekräfta resultaten av vårt test (Figur 27):
Figur 27: CSV -utmatningen visar den avslöjade patientens SSN där den borde ha blivit fördunklad.
Som du kan se i figur 27 maskerar vår rapport dock korrekt kolumnen för patientens efternamn (även en PII) genom att bara visa initialen.
| Läxa! |
| Upprepa samma steg för TestUserC som saknar både TillåtPII och TillåtPHI roller, vilket betyder att de inte ska se vare sig PII- eller PHI -data när de kör någon av våra rapporter. |
Vid denna tidpunkt borde vår miljö ha uppnått fullständig regressionstestning av både PHI- och PII -känslig data med hjälp av Cognos rollbaserade datasäkerhet. Våra testfall kommer var och en att utföra sin överordnade rapport och analysera utmatningen enligt testkonfigurationen som ligger inom deras underliggande påståenden och berätta om någon av rapporterna faller ur linje.
En av de viktigaste skillnaderna mellan vår testmiljö och vad du kan ha i din miljö är säkerligen storleken. En typisk Cognos -miljö har troligen uppåt hundratals eller till och med tusentals rapporter och att köra dem alla samtidigt, som vi har gjort i vår lilla provmiljö, kan ta en vägtull på Cognos prestanda. Med MotioCI's testskript kan du dock schemalägga dina testfall att köras i mindre omgångar under lediga timmar, vilket garanterar optimal prestanda för din Cognos -miljö under de högtrafikerade timmarna.
Bra testmetoder under utvecklingen
Mellan de schemalagda körtiderna kan du dock fortfarande köra så många individuella testfall manuellt som du vill. Ett bra exempel skulle vara när du utvecklar en rapport, du kan köra testfallet för att se till att dina ändringar inte har skapat några HIPAA -kränkningar.
Automatisera Cognos -testfall
Tillbaka till MotioCI, på navigeringsträdet, utökar vi ett av de projekt som vi skapade för att avslöja dess innehåll. Detta bör avslöja en nod som kallas Testa skript. Om du utökar det visas en uppsättning testskript som skapades automatiskt när du först skapade ditt projekt (Figur 28).
Figur 28: Testskript kan skapas för att endast visa ett begränsat antal testfall som matchar ett visst kriterium från administratörsanvändaren.
Per definition a testskript är en komponent i ett projekt som väljer testfall som tillhör ett projekt baserat på angivna kriterier. Du kan schemalägga testskript eller köra dem manuellt. När du kör ett testskript, MotioCI kör alla testfall som följer skriptkriterierna.
I vårt fall skulle vi vilja ställa in alla testfall på ett schema. Så för att göra det klickar vi på Alla testskript från navigeringsträdet och klicka sedan på Testa skriptinställningar fliken i mitten av skärmen (Figur 29).
Figur 29: Fliken "Testskriptinställningar" låter dig lägga till ett schema för alla testfall.
Därefter väljer vi Lägg till schema alternativ. Här kan vi nu ställa in ett schema för vårt testskript. Jag fortsätter och får våra testfall att köras dagligen måndag till fredag klockan 3:00 (Figur 30).
Figur 30: Förutom dags- och veckoschemat kan du också ställa in en minutfrekvens på ett schema.
Det är allt! Vi kan nu kontrollera vår e -postinkorg varje morgon för att ta reda på om någon av våra rapporter inte har följts. Vi kan också se alla misslyckade rapporter genom att helt enkelt klicka på Ändrad eller misslyckad testskript och alla misslyckade testfall kommer att presenteras för oss under Test Cases panelen (Figur 31).
Figur 31: Det inkluderade testskriptet "Ändrat eller misslyckat" som visar det enda testfall som har misslyckats i den senaste testfallssatskörningen.
Slutsats
Att falla ur efterlevnad av HIPPA, GDPR och andra federala föreskrifter kring känslig information och integritet kan vara ganska kostsamt, cirka 1.5 miljoner dollar per fall som bryts, faktiskt.
Genom att implementera en automatiserad teststrategi för att hantera överensstämmelsestest kommer du att ha det extra säkerhetslagret och sinnesro som du följer lagarna. Utöver mandat för sekretessdata kan automatiserade tester gynna alla typer av branscher och alla slags testkrav som din organisation skulle vilja införa.
Hur kan vi hjälpa?
Om du vill titta på webinaret om detta blogginlägg, få tillgång till den här. Eller kontakta oss för att diskutera dina Cognos -testfrågor ytterligare.
