Si la vostra organització gestiona regularment dades sensibles, heu d’implementar estratègies de compliment de la seguretat de les dades per protegir no només les persones a les quals pertanyen les dades, sinó també la vostra organització contra la violació de les lleis federals (per exemple, HIPPA, GDPR, etc.). Això afecta a organitzacions de sectors com la sanitat, la banca, el govern, la legalitat ... realment qualsevol organització que manegi dades sensibles.
Estem parlant PII (informació d'identificació personal) i PHI (informació de salut protegida). Exemples de PII-
- Números de seguretat social
- comptes bancàries
- Noms complets
- Números de passaport, etc.
Exemples de PHI-
- Expedients sanitaris
- Resultats del laboratori
- Factures mèdiques i similars, que inclouen identificadors individuals
Mètodes per protegir dades sensibles
Alguns clients han descrit els seus mètodes com a escenes que us podríeu imaginar en alguna pel·lícula que heu vist ... visualitzeu un grup de persones armades amb les autoritzacions de seguretat necessàries que es troben amuntegades en una habitació tancada, sense finestres, per comprovar manualment els informes impresos per assegurar-vos que la informació sensible no està inclòs. Tot i que això resulta en una escena de pel·lícules dramàtiques, no és la manera més infal·lible ni la manera més eficaç de provar els informes per obtenir informació sensible. I amb els requisits remots de força de treball de Covid-19, això no és possible actualment.
Hem ajudat a diversos dels nostres clients a implementar el poder de les proves automàtiques per provar dinàmicament els resultats de l'informe Cognos. Aquesta estratègia de prova detecta els informes aviat, tan aviat com es compleixen, i abans que acabin en producció per acabar en mans equivocades. Sempre és una bona idea saber on és l’oficina de seguretat social més propera a vosaltres, com ara Oficines de la Seguretat Social a Nevada, en cas que passi el pitjor, ja que l'equip de la vostra oficina local sabrà com gestionar la situació.
Valor de les proves a principis dels cicles de desenvolupament
La detecció de vulnerabilitats de seguretat de dades al començament de l'etapa de desenvolupament pot ajudar a evitar multes i sancions imposades pel futur govern. D'acord amb la Departament de Salut i Serveis Humans dels EUAfins ara, l'Oficina de Drets Civils (OCR) "ha establert o imposat una multa de diners civils en 75 casos, que han suposat un import total en dòlars de 116,303,582.00 dòlars". Això supera els 1.5 milions de dòlars per caixa. I segons el Revista HIPAA el "no realitzar una anàlisi de riscos a tota l'organització és una de les infraccions HIPAA més freqüents que comporta una sanció financera".
A part d’evitar les sancions imposades pel govern, en general és important detectar errors al principi del cicle de desenvolupament, ja que és l’etapa en què els problemes són molt més fàcils i econòmics de solucionar. Com a resultat, l’objectiu principal d’aquest exercici és utilitzar-lo MotioCIEl poder de les proves de regressió per identificar fàcilment aquests errors i, per tant, prevenir-los al principi del cicle de desenvolupament.
Vegem com configurar les proves. Començarem per configurar el nostre entorn Cognos i, a continuació, explicarem com configurar proves automàtiques de dades de PHI i PII per al nostre exemple. També utilitzarem aquests mateixos casos de prova a l’entorn de producció per obtenir un nivell afegit de verificació de la conformitat i la seguretat.
Configuració de l'entorn de Cognos PHI i PII
El nostre entorn Cognos de mostra (figura 1) consta de diversos informes, cadascun dels quals conté una barreja de dades sensibles a PII i PHI (per exemple, codi de diagnòstic, recepta mèdica, número de seguretat social, cognom del pacient, etc.) i dades mínimament sensibles (per exemple, pacient nom, data de la visita, etc.).
Figura 1: El nostre entorn Cognos de mostra.
Hi ha dues funcions de Cognos, AllowPII i AllowPHI, que determinen si alguna de les dades sensibles es renderitza quan s'executen els informes. (Taula 1)
|
Rols Cognos |
notes |
|
AllowPII |
Els membres d'aquesta funció poden veure totes les dades de PII (és a dir, el número de seguretat social i el cognom del pacient) als informes de Cognos. |
|
AllowPHI |
Els membres d'aquesta funció poden veure totes les dades de PHI (per exemple, codis de diagnòstic ICD10, descripció detallada del diagnòstic, etc.) als informes de Cognos. |
Taula 1: rols de Cognos que controlen la representació de dades sensibles.
Per exemple, un usuari al qual li falten les dues funcions de Cognos, el seu informe "Consum diari del pacient" hauria de ser així (Figura 2):
Figura 2: Informe de sortida produït per un usuari que no té funcions AllowPII i AllowPHI.
Com podeu veure, totes les dades de PHI i PII estan totalment ofuscades de l'usuari que no pertany als dos rols "AllowPHI / PII".
Ara, executem l'informe amb un usuari que sigui membre del rol "AllowPII", és a dir, esperem que aquest usuari només pugui veure dades de PII (Figura 3):
Figura 3: Informe de sortida produït per un usuari membre del rol AllowPII i NO del rol AllowPHI.
I podeu veure aquí que tant les columnes Número de seguretat social com Cognoms es mostren adequadament sense cap modificació.
Fins ara hem vist un cop d’ull a l’entorn Cognos de la nostra mítica clínica i tot el que hem vist fins ara és la seguretat de dades basada en funcions de Cognos que molts de vosaltres ja podríeu haver implementat als vostres propis entorns Cognos. Això ens portaria a la principal qüestió que mai no haurien d’afrontar els portadors de dades sensibles:
Què passa si, per exemple, després d’un gran esforç de desenvolupament, algunes dades sensibles s’escapen i comencen a aparèixer per a usuaris que no se suposa que els han de veure?
Els errors són, sens dubte, inevitables, de manera que més endavant utilitzarem el bloc MotioCIEl poder de les proves de regressió per vigilar els nostres informes per assegurar-nos que les dades privades no s’exposen mai al públic no desitjat.
Comprensió de les proves de compliment per a Cognos
Com es va esmentar a la secció anterior, els errors simples en la creació o modelització d’informes podrien induir comportaments no desitjats a la sortida dels informes al vostre entorn Cognos. I si aquests canvis no es capturen, podrien introduir-se al vostre entorn de producció. El que seria encara més desastrós és que si aquests canvis no desitjats inclouen l’exposició de dades privades a un públic no desitjat.
Per exemple, un usuari sense ser-ne membre AllowPII or AllowPHI Se suposa que els rols de Cognos no veuran dades privades de PII ni PHI al nostre entorn Cognos de mostra. Tanmateix, com es pot veure a continuació (Figura 4), un simple canvi en el model FM ha fet que la descripció del diagnòstic i el número SSN del pacient estiguessin exposats a aquest usuari, cosa que suposa una enorme violació de la norma federal de seguretat HIPAA.
Figura 4: Un usuari sense pertinença a funcions AllowPII i AllowPHI està exposat d'alguna manera a les dades sensibles de HIPAA.
Abans de traslladar les coses a MotioCI, primer crearem tres usuaris de prova al nostre entorn Cognos i els assignarem als nostres dos rols de la manera següent (taula 2):
| Usuaris | Membres de rol | notes |
| TestUserA | AllowPII | Totes les dades PHI s'han d'amagar a aquest usuari |
| Usuari de provaB | AllowPHI | Totes les dades PII s'han d'amagar a aquest usuari |
| ProvaUsuariC | cap | S'espera que l'usuari NO vegi ni PHI ni PII |
Taula 2: Prova dels comptes d'usuari de Cognos amb els rols assignats.
Aquests comptes d'usuari de prova s'utilitzaran posteriorment a MotioCI per a proves de regressió dels nostres informes que contenen dades sensibles de PII i PHI. Els resultats de les nostres proves dependran de la visibilitat de les dades sensibles per a cada usuari segons la seva pertinença al rol.
Ara que hem configurat els nostres usuaris de prova, ja estem preparats per configurar les nostres proves de regressió MotioCI.
MotioCI Configuració del medi ambient
El nostre entorn de mostra consisteix en instàncies de desenvolupament, UAT i Production Cognos. Encara que MotioCI ens permet iniciar la sessió als tres alhora, començarem la configuració de proves de regressió a l’entorn de desenvolupament en tres fases diferents.
Figura 5: MotioCI pantalla d'inici de sessió.
Figura 6: MotioCI pantalla inicial, mostrant les instàncies de Cognos.
Pel que fa a les proves de regressió a MotioCI, Una afirmació és un control individual o "prova" que un cas de prova realitza a un objecte del vostre MotioCI per exemple, com ara un informe, una carpeta o un paquet. Es diu l’afirmació que farà la feina de provar les sortides de l’informe de dades sensibles Proves de conformitat de dades sensibles (Figura 7). Aquesta és una afirmació personalitzada que hem elaborat per a aquest exercici. A continuació podeu veure el tipus d’afirmació que bàsicament actua com la plantilla principal que es copia per provar casos a tot el nostre MotioCI entorn. Més informació sobre això més endavant.
Figura 7: tipus d'afirmació "Prova de conformitat de dades sensibles". Es creen còpies d'aquesta afirmació a l'entorn de proves.
Algunes afirmacions proporcionen algunes funcionalitats ajustables per l'usuari mitjançant un finestra de sol·licitud. Aquí podeu canviar com voleu que una afirmació determinada provi qualsevol informe de Cognos. La figura 8 següent mostra el finestra de sol·licitud de la nostra afirmació que farem servir per provar els nostres informes Cognos que contenen dades sensibles.
Figura 8: Finestra de sol·licitud de l'afirmació "Proves de conformitat de dades sensibles", que revela totes les opcions de prova ajustables per l'usuari.
La secció destacada superior de la figura 8 mostra les opcions de prova de dades sensibles a PII i PHI. Això us permet fer la prova d’afirmació si l’informe ha de mostrar o amagar les seves dades PII o PHI. Farem canvis en aquestes dues opcions a mesura que comencem a crear casos de prova per a cadascun dels nostres usuaris de prova.
La secció ressaltada central de la figura 8 mostra els noms de les columnes que contenen dades sensibles a la PHI als nostres informes. Tot i que el nostre entorn de mostra consta de columnes amb el nom de Codi Diag ICD10, Descripció del diagnòstic, Procediment i Rx, segur que podríeu modificar aquesta llista per adaptar-la a les vostres necessitats.
Finalment, la secció ressaltada inferior de la figura 8 mostra les opcions de correu electrònic. En cas de fallada, aquesta afirmació enviarà un missatge de correu electrònic detallat al destinatari configurat en aquesta secció.
Fase I: informes que només mostren PII
Creem un projecte sota el fitxer desenvolupament instància a MotioCI i cridar-ho Permet només PII. Ho podem fer fent primer clic amb el botó dret a la icona desenvolupament node d'instància a MotioCI arbre de navegació i seleccionant el fitxer Afegeix projecte opció (Figura 9).
Figura 9: Creació d’un nou projecte. En MotioCI cada projecte actua com a camp de proves per a una secció predefinida del magatzem de contingut.
El Afegeix assistent de projectes us farà alguns passos per seleccionar els camins necessaris per al vostre projecte. En el nostre exemple, tots els informes que contenen dades sensibles a PII i PHI existeixen a Dades del pacient carpeta. Si marqueu aquesta carpeta principal, s'inclouran automàticament tots els informes subjacents (figures 10 i 11).
Figura 10: Determinació de l'abast del projecte a MotioCI seleccionant els camins de l’entorn Cognos.
Figura 11: Mostrant tots els objectes de Cognos seleccionats per a MotioCI projecte.
Com que s’espera que tots els informes d’aquest projecte permetin mostrar totes les dades d’IPE i ofuscar totes les PHI, haurem de configurar el nostre tipus d’asserció amb la configuració correcta abans d’afegir cap cas de prova (Figura 12). Això significa establir les dues opcions de prova en la mateixa afirmació finestra de sol·licitud que hem vist abans a la figura 8.
Figura 12: Opcions de proves de PII i PHI de l'afirmació "Prova de conformitat de dades sensibles".
Ara estem preparats per afegir els nostres casos de prova als nostres informes. Per fer-ho, feu clic dret sobre el node del projecte (és a dir, el fitxer Permet només PII projecte) a MotioCI I seleccioneu el Generar casos de prova opció (Figura 13). S’iniciarà l’assistent de generació de casos de prova que ens permetrà crear un gran nombre de casos de prova per a tots els informes del projecte.
Figura 13: MotioCI pot generar automàticament tots els casos de prova necessaris a qualsevol nivell des del projecte.
El Genera un cas de prova L'assistent també ens permetrà seleccionar els formats de sortida per al cas de prova en el qual ens agradaria fer proves. Per al nostre entorn de mostra, vaig triar la sortida CSV. L’assistent també ens permetrà escollir les afirmacions que utilitzarà cada cas de prova per al treball real de la prova. I per a nosaltres això seria el Proves de conformitat de dades sensibles afirmació. Podeu veure aquestes dues opcions ressaltades a continuació (Figura 14).
Figura 14: Les opcions revelades durant l'assistent "Generar casos de prova".
Després de fer clic a "D'acord", tornareu a la pàgina MotioCI pantalla inicial, on podreu veure tots els nostres informes que contenen un cas de prova únic i contenen cadascun la nostra afirmació única (Figura 15).
Figura 15: MotioCI arbre de navegació que mostra tots els objectes del Cognos que ara contenen un cas de prova i l’afirmació subjacent.
Finalment, hem de configurar tots els casos de prova per executar els seus informes pares mitjançant l’usuari de Cognos correcte (per exemple, un dels tres usuaris de prova que vam configurar a Cognos abans de configurar les coses a MotioCI). I ja que per a aquest projecte estem provant per assegurar-nos que el contingut PHI és no que es mostri als usuaris que només tenen permís per visualitzar dades PII, haurem de configurar tots els casos de prova per executar-los TestUserA (vegeu la taula 2).
Al principi això pot semblar una tasca tediosa, però, per sort, podem establir l’usuari al nivell del projecte que després serien heretats per TOTS els casos de prova subjacents d’aquest projecte. Per fer-ho, a l’arbre de navegació esquerre, farem clic al node del projecte ( Permet només PII projecte) i seleccioneu el fitxer Configuració del projecte al mig de la pantalla. A continuació, sota el fitxer Proves a la secció, veurem una opció per canviar les credencials (Figura 16):
Figura 16: definir les credencials d'usuari en un projecte farà que tots els casos de prova executin l'informe de Cognos pare a Cognos amb aquest usuari. Això es pot sobreescriure per cada cas de prova individual.
Després de fer clic al botó Editar botó situat davant del fitxer cartes credencials opció, se'ns presentarà el fitxer Editeu les credencials finestra. Seguirem endavant i introduirem les credencials de TestUserA (Figura 17).
Figura 17: La finestra "Edita les credencials" us permet establir noves credencials d'usuari o utilitzar les credencials principals definides al nivell d'instància de Cognos, també conegudes com a credencials del sistema.
Ara veiem el nou usuari reflectit al fitxer Proves secció de la Configuració del projecte pestanya (Figura 18).
Figura 18: Les noves credencials d'usuari s'han definit al projecte.
Ara ja estem preparats per executar tots els nostres casos de prova.
Per fer-ho, farem clic al botó Permet només PII projecte i al mig se'ns presentarà el Casos de prova pestanya que mostra tots els casos de prova ubicats dins del projecte. Com que encara no hem executat res, veuríem el Estat mostrant com No hi ha resultats. Per executar tots els casos de prova, farem clic a la petita fletxa situada al costat de la Correr i seleccioneu el botó Executa-ho tot opció (Figura 19).
Figura 19: La pestanya "Casos de prova" proporciona una sèrie d'accions que es podrien dur a terme de manera massiva en tots o en alguns casos de prova. Aquí només estem executant tots els casos de prova.
MotioCI ara executarà tots els casos de prova i ens presentarà els resultats quan estiguin acabats (Figura 20).
Figura 20: La pestanya "Casos de prova" mostra l'estat d'execució de cada cas de prova, incloses les sortides, si n'hi ha.
Com podeu veure, tots els nostres casos de prova han tingut èxit a excepció del Pacient intern informe. Per tant, fem una ullada als resultats. Per fer-ho, farem clic a la marca de temps blava situada a sota del fitxer Resultat columna i mireu els detalls de la figura 21.
Figura 21: El tauler "Resultat del cas de prova" mostra els resultats detallats de l'execució del cas de prova, incloent-hi la ruta de l'objecte provat, els resultats de l'asserció i qualsevol sortida produïda per l'informe.
Sota el Resultats de l'afirmació ara podem veure que el nostre informe infringeix els requisits de compliment de la PHI. Podem descarregar la sortida de l'informe CSV des de Sortides de casos de prova secció fent clic a la icona CSV (Figura 21).
Figura 22: la sortida de l'informe CSV que mostra una columna "Procediment" que s'ha d'haver ofuscat per a l'usuari de la prova.
Com podeu veure al nostre informe (Figura 22), a més de les dades PII, que està bé perquè hi pugui accedir TestUserA, podem veure les dades del procediment PHI que incompleixen l’informe a la Norma federal de seguretat HIPAA.
Si recordeu a la finestra de configuració de l’afirmació, també se suposava que havíem de rebre una notificació per correu electrònic d’aquest error. Vegem com és això (Figura 23):
Figura 23: missatge de correu electrònic enviat per l'afirmació del cas de prova fallit, que mostra un incompliment del compliment de dades sensibles, probablement a causa d'un canvi recent a l'informe.
En aquest moment, hem acabat de provar per assegurar-nos que les dades PHI estan ocultes als usuaris sense el necessari AllowPHI Cognos paper. Ara estem preparats per estendre les nostres proves a les dades PII que estiguin ocultes als usuaris que no en tinguin el necessari AllowPII Cognos paper.
Fase II: informes que només mostren PHI
Abans de crear el nou projecte, primer editem les opcions de la nostra afirmació mestra per assegurar-nos que ara provi que s’amaguen tots els PII i que es mostrin tots els PHI (Figura 24).
Figura 24: Opcions de proves de PII i PHI de l'afirmació "Prova de conformitat de dades sensibles" que s'estableix per TestUserB.
Amb la nostra afirmació configurada, ja estem preparats per crear el nou projecte i els nostres casos de prova. Per a això, seguirem els mateixos passos que a la "Fase I" i crearem un projecte anomenat Permet només PHI. A més, no oblidem afegir les credencials de Usuari de provaB com a usuari del projecte.
Quan hàgim acabat tots els passos de configuració, executarem tots els casos de prova, tal com vam fer a la fase I. Al nostre entorn de mostra, aquesta vegada tenim un informe diferent que sembla que infringeix HIPAA (Figura 25).
Figura 25: la pestanya "Casos de prova" que mostra l'estat d'execució de cada cas de prova, incloses les sortides, si n'hi ha.
Més investigació sobre els resultats del cas de prova del Consum diari del pacient l'informe mostra que el nostre informe mostra els números de seguretat social dels pacients al públic no desitjat (Figura 26).
Figura 26: Resultat del cas de prova que mostra una infracció del requisit de conformitat SSN PII.
La baixada i l’obertura del fitxer CSV confirmaran encara més els resultats de la nostra prova (Figura 27):
Figura 27: La sortida CSV mostra el SSN del pacient revelat on hauria d’haver estat ofuscat.
Com podeu veure a la figura 27, però, el nostre informe emmascara adequadament la columna del cognom del pacient (també un PII) mostrant només la inicial.
|
Deures! |
|
Repetiu els mateixos passos per ProvaUsuariC que no té tant AllowPII i AllowPHI rols, és a dir, que no se suposa que veuen dades PII ni PHI quan executen cap dels nostres informes. |
En aquest moment, el nostre entorn hauria d'haver aconseguit proves de regressió completes tant de dades sensibles de PHI com de PII mitjançant la seguretat de dades basada en el rol de Cognos. Els nostres casos de prova executaran cadascun el seu informe principal i analitzaran el resultat segons la configuració de proves establerta dins de les seves afirmacions subjacents i ens indicaran si algun dels informes no funciona.
Certament, una de les distincions més importants entre el nostre entorn de prova i el que podeu tenir al vostre entorn és la mida. Un entorn típic de Cognos és probable que tingui més de centenars o fins i tot milers d’informes i executar-los al mateix temps, tal com hem estat fent en el nostre petit entorn de mostra, podria afectar el rendiment de Cognos. Amb MotioCIEls scripts de prova, però, podeu programar els casos de prova perquè s’executin en lots més petits durant les hores de descans, garantint per tant un rendiment òptim del vostre entorn Cognos durant les hores de gran trànsit.
Una bona pràctica de proves durant el desenvolupament
Entre els temps d'execució programats, però, podeu executar manualment tants casos de prova individuals com vulgueu. Un bon exemple seria que, mentre es desenvolupa un informe, es pot executar el cas de prova per assegurar-se que els canvis no hagin creat infraccions HIPAA.
Automatització de casos de prova de Cognos
Feu una còpia de MotioCI, a l'arbre de navegació, ampliem un dels projectes que vam crear per revelar-ne el contingut. Això hauria de revelar un node anomenat Prova scripts. En ampliar-lo es mostrarà un conjunt de scripts de prova que es van crear automàticament quan vau crear el projecte per primer cop (Figura 28).
Figura 28: Es poden crear scripts de prova per mostrar només un nombre limitat de casos de prova que coincideixin amb determinats criteris establerts per l'usuari administrador.
Per definició, a guió de prova és un component d'un projecte que selecciona casos de prova que pertanyen a un projecte segons criteris especificats. Podeu programar scripts de prova o executar-los manualment. Quan executeu un script de prova, MotioCI executa tots els casos de prova que compleixen els criteris de script.
En el nostre cas, ens agradaria establir tots els casos de prova en un calendari. Així, per fer-ho, fem clic a All proveu l'script de l'arbre de navegació i feu clic a Prova la configuració de scripts pestanya que es troba al mig de la pantalla (Figura 29).
Figura 29: La pestanya "Paràmetres de script de prova" us permet afegir una programació per a tots els casos de prova.
A continuació, seleccionem el fitxer Afegeix una programació opció. Aquí ja podem establir un calendari per al nostre script de prova. Seguiré endavant i faré que els nostres casos de prova s’executin diàriament de dilluns a divendres a les 3:00 del matí (Figura 30).
Figura 30: A més de la programació diària i setmanal, també podeu establir una freqüència de minuts en una programació.
Això és! Ara podem consultar la nostra bústia d’entrada de correu electrònic cada matí per saber si algun dels nostres informes s’ha quedat sense compliment. També podem veure tots els informes fallits simplement fent clic a S'ha canviat o ha fallat el guió de prova i tots els casos de prova fallits se'ns presentaran a la secció Casos de prova tauler (Figura 31).
Figura 31: L'escriptori de prova inclòs "Canviat o fallit" que mostra el cas únic de prova que ha fallat en la darrera execució per lots de casos de prova.
Conclusió
No complir el compliment de HIPPA, GDPR i altres normatives federals sobre informació sensible i privadesa pot costar bastant, de fet aproximadament 1.5 milions de dòlars per cas.
En implementar una estratègia de proves automatitzades per gestionar les proves de compliment, tindreu aquesta capa addicional de seguretat i tranquil·litat que esteu complint amb les lleis. Més enllà dels mandats de dades de privadesa, les proves automàtiques poden beneficiar tot tipus d’indústries i qualsevol tipus de requisit de prova que la vostra organització vulgui establir.
Com podem ajudar-nos?
Si voleu veure el seminari web sobre aquest tema del bloc, accediu-hi aquí. O, contacti'ns per debatre més sobre les vostres preguntes sobre les proves de Cognos.
