Análise de Segurança Baseada em Roles para Fábricas de Software
Miguel Loureiro, Luísa Lourenço, Lúcio Ferrão, Carla Ferreira
AAn´alise de Seguran¸ca Baseada em Roles paraF´abricas de Software
Miguel Loureiro , Lu´ısa Louren¸co , L´ucio Ferr˜ao , and Carla Ferreira NOVA-LINCS & DI, FCT, Universidade Nova de Lisboa OutSystems Portugal
Resumo
A maioria das f´abricas de software contˆem aplica¸c˜oes cominforma¸c˜ao sens´ıvel que necessita de ser protegida contra quebras deconfidencialidade e integridade, as quais podem ter consequˆencias graves.No contexto de f´abricas de grandes dimens˜oes com aplica¸c˜oes complexas,n˜ao ´e vi´avel analisar manualmente acessos a informa¸c˜ao sens´ıvel sem osmecanismos de seguran¸ca necess´arios.Este artigo apresenta uma t´ecnica de an´alise est´atica de seguran¸ca paraf´abricas de software, baseada em pol´ıticas de seguran¸ca com roles . Naabordagem proposta ´e constru´ıda uma representa¸c˜ao em forma de grafo daf´abrica de software, tendo por base a pol´ıtica de seguran¸ca definida peloutilizador. Posteriormente o modelo ´e analisado para encontrar acessosa informa¸c˜ao onde a pol´ıtica de seguran¸ca ´e quebrada, garantindo quetodos os poss´ıveis estados de execu¸c˜ao s˜ao analisados.Foi desenvolvida uma proof of concept que implementa a nossa t´ecnica dean´alise para f´abricas de software OutSystems. Com base nos resultados daan´alise s˜ao gerados relat´orios de seguran¸ca, de modo a dar visibilidade `asfalhas encontradas e ajudar a equipa de desenvolvimento a prioritizar estasfalhas. O prot´otipo foi avaliado usando f´abricas de software de grandesdimens˜oes e com requisitos fortes de seguran¸ca. Foram encontradas v´ariasfalhas de seguran¸ca, algumas graves, que dificilmente seriam encontradassem a nossa an´alise.
Keywords:
Pol´ıticas de seguran¸ca baseadas em roles · Seguran¸ca · An´alise est´atica de programas.
Na inform´atica, a seguran¸ca ´e uma ´area em constante evolu¸c˜ao, de importˆanciacada vez maior `a medida que a nossa sociedade se vai tornando cada vez maisavan¸cada e dependente em infraestructuras como a internet. Relat´orios de segu-ran¸ca recentes mostram que em 2017 houve um aumento de 13% no n´umero devulnerabilidades de seguran¸ca encontradas. Outro relat´orio de seguran¸ca mostra Relat´orios de seguran¸ca da Symantec 2017 e 2018: e Relat´orio de segura¸ca Trustwave 2017: a r X i v : . [ c s . P L ] S e p M. Loureiro et al. que mais de metade das vulnerabilidades de seguran¸ca encontradas em aplica¸c˜oesweb fazem parte da categoria de fugas de informa¸c˜ao.Vulnerabilidades de seguran¸ca, nomeadamente fugas de informa¸c˜ao, tˆem re-percuss˜oes negativas tanto para clientes como para empresas. Expor a informa¸c˜aopessoal de um indiv´ıduo pode ter efeitos graves. Por exemplo, se a informa¸c˜aobanc´aria de um cliente for exposta publicamente, ´e um alvo para roubo, ou seinforma¸c˜ao pessoal sens´ıvel for exposta pode ser v´ıtima de roubo de identidade.Ao n´ıvel empresarial, fugas de informa¸c˜ao reduzem o n´ıvel de confian¸ca dosclientes, afetam o seu valor de mercado, e criam complica¸c˜oes legais.Este trabalho foi desenvolvido com o objetivo de melhorar a seguran¸ca def´abricas de software, i.e. , um conjunto de aplica¸c˜oes que podem estar relacionadase nas quais pode existir troca de informa¸c˜ao. Em f´abricas de software compostaspor um n´umero elevado de aplica¸c˜oes web que trabalhem com informa¸c˜ao sens´ıvel,torna-se dif´ıcil assegurar que n˜ao existem falhas de seguran¸ca. Devido `a quantidadede aplica¸c˜oes e `a complexidade de cada uma delas, ´e complicado determinarque informa¸c˜ao ´e exposta para cada um dos roles em cada entrypoint ( e.g. ,ecr˜as, endpoints REST). Assim, torna-se dif´ıcil colocar os devidos mecanismosde seguran¸ca para proteger informa¸c˜ao sens´ıvel, e ainda mais dif´ıcil determinar `aposteriori onde faltam estes mecanismos de seguran¸ca.Surge assim um problema para equipas que desenvolvam f´abricas de softwarede grandes dimens˜oes. ´E inevit´avel que, por vezes, os programadores se esque¸camde proteger informa¸c˜ao sens´ıvel com mecanismos de seguran¸ca. Assim, existe umapropaga¸c˜ao de falhas de seguran¸ca, que dificilmente ser´a manualmente detetadasposteriormente. Portanto, ´e inexequ´ıvel garantir a seguran¸ca de uma f´abrica desoftware sem uma an´alise de seguran¸ca que detete falhas.As contribui¸c˜oes chave apresentadas neste artigo s˜ao uma t´ecnica de an´aliseest´atica de seguran¸ca para f´abricas de software compostas por v´arias aplica¸c˜oesweb com um modelo de controlo de acesso baseado em roles . A an´alise recebe umapol´ıtica de seguran¸ca que associa recursos a roles e encontra, analisando todasas aplica¸c˜oes da f´abrica, entrypoints e sub-rotinas chamadas, onde a pol´ıtica ´equebrada.A t´ecnica foi implementada numa ferramenta proof of concept direcionadapara f´abricas de software OutSystems. Depois de detetar falhas de seguran¸canuma f´abrica, a ferramenta gera um relat´orio de seguran¸ca que, ao dar visibilidadea estas falhas, ajuda o utilizador a encontrar e prioritizar falhas na sua f´abricade software.O resto do documento est´a estruturado da seguinte forma. Na Sec¸c˜ao 2 ´e feitaa descri¸c˜ao geral da t´ecnica de an´alise. Na Sec¸c˜ao 3 ´e apresentada a descri¸c˜aoda implementa¸c˜ao da t´ecnica numa proof of concept . A descri¸c˜ao da avalia¸c˜ao `at´ecnica desenvolvida ´e apresentada na Sec¸c˜ao 4. De seguida, a Sec¸c˜ao 5 descreveo trabalho relacionado `a t´ecnica desenvolvida. Por ´ultimo, a Sec¸c˜ao 6 apresentaas conclus˜oes e observa¸c˜oes finais. n´alise de Seguran¸ca Baseada em Roles para F´abricas de Software 3
Figura 1.
Exemplo de uma pol´ıtica de seguran¸ca
Nesta sec¸c˜ao ´e feita uma descri¸c˜ao geral da t´ecnica de an´alise est´atica desenvolvida.S˜ao feitas as seguintes assun¸c˜oes sobre a arquitetura duma aplica¸c˜ao web gen´ericaque utilize um modelo de controlo de acessos baseado em roles: – Os utilizadores do sistema tˆem um ou mais roles atribu´ıdos; – O acesso a cada entrypoint pode estar limitado a um ou mais roles ; – O modelo cont´em primitivas para atribuir, remover e verificar roles .A nossa t´ecnica de an´alise tem por base numa pol´ıtica de seguran¸ca definidapelo utilizador. Cada uma das regras da pol´ıtica de seguran¸ca consiste numrecurso ( e.g. , uma tabela de uma base de dados) e nos conjuntos de roles comacesso de leitura e de escrita. A Figura 1 mostra um exemplo duma pol´ıtica deseguran¸ca, que define que o recurso (entidade)
Client pode ser lido e escrito pelos roles Admin e Lawyer , e pode ser lido pelo role Customer .O processo de an´alise come¸ca por produzir uma s´ıntese da f´abrica de softwarecom base na pol´ıtica de seguran¸ca recebida. Tendo em conta a dimens˜ao dasf´abricas de software e `a quantidade de elementos diferentes e complexos quecada f´abrica pode ter, ´e importante construir um modelo sintetizado, s´o cominforma¸c˜ao relevante, sob o qual se pode realizar a an´alise.O modelo sintetizado duma f´abrica de software ´e constru´ıdo num call graph,um grafo que representa as rela¸c˜oes de chamada entre sub-rotinas dum programa.Este call graph cont´em: – Os entrypoints das v´arias aplica¸c˜oes da f´abrica; – As sub-rotinas chamadas por cada entrypoint da f´abrica; – As primitivas de leitura e escrita de recursos da f´abrica; – Os recursos da f´abrica.Um call graph apenas com esta informa¸c˜ao j´a daria resultados ´uteis, mas devido`a falta de alguma informa¸c˜ao relevante – como as chamadas de primitivas queatribuem, retiram ou verificam os roles de um utilizador – ia resultar num elevadon´umero de falsos positivos. Como tal, os n´os do call graph associados a sub-rotinasguardam tamb´em o control flow graph (CFG) dessa sub-rotina.Depois de construir o modelo sintetizado, o modelo ´e analisado `a procura defalhas de seguran¸ca. Esta an´alise ´e composta por trˆes passos:1. Procurar potenciais falhas de seguran¸ca no call graph;
M. Loureiro et al.
2. Expandir o call graph de cada potencial falha, usando os CFGs das sub-rotinas;3. Analisar o CFG de cada potencial falha, para validar a existˆencia de umafalha.O primeiro passo consiste em utilizar o call graph para encontrar todas aspotenciais falhas de seguran¸ca. Uma potencial falha ´e um caminho entre umrecurso X que fa¸ca parte da pol´ıtica de seguran¸ca e um entrypoint Y que permitao acesso a um utilizador com um role que n˜ao fa¸ca parte da pol´ıtica de X . ´Ede notar que n˜ao ´e poss´ıvel determinar de forma definitiva que os caminhosidentificados representam falhas reais, pois o call graph n˜ao tem informa¸c˜aocompleta, como primitivas que verificam se o utilizador atual possu´ı um role ( check role ). A Figura 2 mostra um exemplo da utiliza¸c˜ao de uma verifica¸c˜ao de role para proteger o acesso a um recurso – s´o se o utilizador tiver o role Admin ´e que a opera¸c˜ao de escrita DeleteLegalCase vai ser chamada. Se um recursoidentificado como uma potencial falha estiver protegido por um check role usadonum bloco condicional, ent˜ao trata-se dum falso positivo. Para encontrar todasas potenciais falhas, ´e utilizado um algoritmo de pesquisa em profundidade.O segundo passo consiste em expandir o call graph de cada potencial falhacom o CFG interno de cada sub-rotina. Obt´em-se assim um CFG, com maisinforma¸c˜ao em rela¸c˜ao ao call graph.O terceiro passo consiste em analisar o CFG resultante do segundo passopara validar a potencial falha encontrada. Esta an´alise ´e feita com um algoritmode pesquisa em profundidade eficiente . A an´alise dum CFG come¸ca no n´o do entrypoint e ´e mantido um estado durante a an´alise de cada caminho. Este estadovai conter os roles que o utilizador pode ter e os roles que o utilizador tem .O estado inicial ´e determinado a partir do conjunto de roles com acesso ao entrypoint , sendo atualizado durante a travessia com as primitivas que atribuem,retiram ou verificam um role ao utilizador. Um dos mecanismos de seguran¸causados consiste na utiliza¸c˜ao da primitiva check role dentro de um bloco condici-onal. O estado vai ser alterado para cada ramo do bloco condicional, consoante acondi¸c˜ao usada. Ao passar por um n´o dum recurso que perten¸ca `a pol´ıtica deseguran¸ca, verifica-se o estado para determinar se existe uma falha de seguran¸ca.Se o utilizador n˜ao possuir um dos roles da pol´ıtica, e puder ter um role que n˜aofa¸ca parte da pol´ıtica, trata-se duma potencial falha de seguran¸ca que deve serreportada.O resultado da an´alise ´e um conjunto de entrypoints com falhas de seguran¸ca,as sub-rotinas chamadas por cada entrypoint com falhas de seguran¸ca, e oscaminhos tanto no call graph como no control flow graph de cada falha encontrada.Na pr´oxima sec¸c˜ao ´e descrito como ´e que os resultados da an´alise s˜ao usadospara ajudar o utilizador final a visualizar e a prioritizar as falhas encontradas. N˜ao percorre caminhos redundantes.n´alise de Seguran¸ca Baseada em Roles para F´abricas de Software 5
Figura 2.
Exemplo de
CheckRole a proteger o acesso de escrita a uma entidade
Legal-Case
Nesta sec¸c˜ao ´e descrita a implementa¸c˜ao da t´ecnica de an´alise de seguran¸cae a gera¸c˜ao de relat´orios com o resultado da an´alise. A implementa¸c˜ao dat´ecnica foi direcionada a f´abricas de software OutSystems, e para tal foi feitoum mapeamento dos elementos do modelo gen´erico da an´alise para elementos domodelo OutSystems.A OutSystems ´e uma plataforma que permite o desenvolvimento r´apido deaplica¸c˜oes web e mobile. As aplica¸c˜oes OutSystems podem ter v´arios entrypoints ,e.g., ecr˜as, endpoints REST, endpoints
SOAP. Um ecr˜a ´e um elemento do modeloOutSystems que cont´em uma interface para utilizador final interagir com aaplica¸c˜ao e que ´e usado como entrypoint da aplica¸c˜ao.Para simplificar, a nossa an´alise s´o contempla ecr˜as como entrypoints deaplica¸c˜oes. Um ecr˜a em OutSystems tem um conjunto de permiss˜oes, ou seja,um conjunto de roles com acesso ao ecr˜a. Em OutSystems, os dados (sens´ıveisou n˜ao) duma aplica¸c˜ao est˜ao armazenados em entidades. Pode-se assumir queuma entidade OutSystems ´e uma tabela numa base de dados SQL. O modeloOutSystems possu´ı trˆes primitivas de RBAC –
GrantRole , RevokeRole e CheckRole – que respetivamente atribuem um role ao utilizador, retiram um role ao utilizador,e verificam se o utilizador tem um role .Em OutSystems ´e comum utilizar a primitiva
CheckRole para proteger oacesso a entidades. A Figura 2 cont´em um exemplo dum
CheckRole dentrodum bloco condicional a garantir que o acesso `a entidade
LegalCase ´e restrito autilizadores com o role
Admin .O caminho duma potencial falha de seguran¸ca come¸ca num ecr˜a e terminanuma entidade. Um ecr˜a possu´ı a¸c˜oes que podem aceder a entidades, ou podemchamar outras a¸c˜oes que eventualmente acedem a uma entidade. Mais preci-samente, uma potencial falha de seguran¸ca consiste num caminho entre umaentidade que faz parte da pol´ıtica de seguran¸ca, um ecr˜a que permite a entradaa roles que n˜ao fazem parte da pol´ıtica de seguran¸ca da entidade, e um caminhosem mecanismos de seguran¸ca at´e `a entidade. M. Loureiro et al.
Figura 3.
Relat´orio de seguran¸ca
No desenvolvimento da ferramenta foi implementada uma interface paraajudar os utilizadores a definirem as suas pol´ıticas de seguran¸ca. A interfacemostra uma lista de todas as entidades e roles da f´abrica de software e permite outilizador definir que roles tˆem acesso de leitura e escrita a cada entidade. Cadaregra duma pol´ıtica de seguran¸ca associa a cada entidade dois conjuntos de roles ,os roles com acesso de leitura e os roles com acessos de escrita.Ap´os a defini¸c˜ao da pol´ıtica de seguran¸ca, pode-se executar a an´alise, cujoresultado vai ser uma cole¸c˜ao de ecr˜as com (potenciais) falhas de seguran¸ca, cadaum com uma cole¸c˜ao de a¸c˜oes com falhas, mais os respetivos caminhos do callgraph e CFG.Para que resultados da an´alise sejam ´uteis para o utilizador final, a ferramentaconstr´oi tamb´em um relat´orio de seguran¸ca. O relat´orio vai mostrar todas asfalhas encontradas, ordenando-as por risco de modo a ajudar a sua prioritiza¸c˜ao.A Figura 3 mostra um relat´orio de seguran¸ca produzido pela ferramenta. Esterelat´orio come¸ca por listar todos os m´odulos de aplica¸c˜ao com potenciais falhas deseguran¸ca. Em cada entrada do relat´orio ´e tamb´em mostrado o n´umero de falhasencontradas e que roles ´e que quebraram a pol´ıtica de seguran¸ca. Ao selecionaruma entrada do relat´orio, essa ´e expandida e s˜ao mostrados todos os ecr˜as dessem´odulo que contˆem falhas. Um entrada dum ecr˜a tamb´em pode ser expandida,mostrando todas as a¸c˜oes com falhas encontradas nesse ecr˜a. A Figura 3 mostraque foram encontradas falhas no m´odulo “LaywerExample”, mais especificamenteno seu ecr˜a “SecretAdminPage”. Neste ecr˜a, para cada um dos roles
Registered , Anonymous e Client , foram encontradas duas potenciais falhas de seguran¸ca,onde utilizadores com esses roles podem ter acesso indevido a uma entidade.Nas entradas de ecr˜as e a¸c˜oes, ´e tamb´em poss´ıvel selecionar no bot˜ao “InspectCall Graph”, que vai mostrar o call graph da(s) falha(s) encontradas naqueleecr˜a/a¸c˜ao. A Figura 4 mostra esta funcionalidade do relat´orio de seguran¸ca. n´alise de Seguran¸ca Baseada em Roles para F´abricas de Software 7
Figura 4.
Relat´orio de seguran¸ca, com call graph expandido
Esta sec¸c˜ao descreve a avalia¸c˜ao emp´ırica da ferramenta que implementa a an´alisepara f´abricas de software OutSystems, descrita na Sec¸c˜ao 3.Para a avalia¸c˜ao foram utilizadas trˆes f´abricas de software. A primeira f´abrica´e um mock-up que consiste num exemplo simples dum sistema de gest˜ao parauma firma de advogados. As outras duas f´abricas utilizadas, A e B, s˜ao f´abricasde clientes da OutSystems . A utiliza¸c˜ao de uma f´abrica mock-up ´e ´util porque´e poss´ıvel introduzir falhas de seguran¸ca e verificar se a an´alise ´e capaz de asdetetar. No entanto n˜ao ´e suficiente, n˜ao s´o devido `a sua reduzida dimens˜ao mastamb´em porque numa f´abrica real podem-se encontrar falhas que dificilmenteser´ıamos capazes de reproduzir.A f´abrica mock-up tem dois m´odulos, um para a UI da aplica¸c˜ao e outro parao modelo de dados. O modelo de dados ´e simples e cont´em trˆes entidades: Client , Lawyer e LegalCase . Client representa os clientes da firma de advogados,
Lawyer representa os advogados da firma, e
LegalCase representa os processos legais dafirma. Cada processo est´a associado a um cliente e a um advogado.Nesta f´abrica foram introduzidas algumas falhas de seguran¸ca, por exemplo,ecr˜as ( entrypoints ) que d˜ao acesso a roles que n˜ao deviam e que chamam a¸c˜oes(sub-rotinas) que acedem a entidades sens´ıveis sem checks de seguran¸ca.Em rela¸c˜ao `as f´abricas de software dos clientes, a f´abrica A ´e de tamanhom´edio, com cerca de 30 m´odulos, tendo mais de 200 ecr˜as ( entrypoints ), 200entidades e 35 roles . Esta f´abrica cont´em v´arias aplica¸c˜oes usadas internamentepor uma empresa.A f´abrica B ´e uma das maiores f´abricas existentes em OutSystems. Cont´emmais de 700 m´odulos de aplica¸c˜ao, com mais de 2000 entidades, 2500 ecr˜as e N˜ao revelados por motivos de privacidade. M. Loureiro et al.
Ecr˜as Ecr˜as Falhas Falsos % de falhascom falhas validados reais positivos reaisPol´ıtica 1
Pol´ıtica 2
Tabela 1.
Valida¸c˜ao dos resultados da f´abrica de software A roles . A f´abrica B cont´em um sistema semelhante ao mock-up da firma deadvogados, mas direcionado para uma ´area profissional diferente. Esta f´abricavai ser o nosso benchmark para performance e escalabilidade. Ou seja, se a nossat´ecnica tiver boa performance com esta f´abrica podemos assumir que a suaperformance tamb´em ser´a boa para a maioria das f´abricas de software existentes.
Para validar a nossa t´ecnica, test´amos-la com as trˆes f´abricas de software. Utili-zando a nossa pol´ıtica de seguran¸ca para a f´abrica mock-up , os resultados obtidosforam todos corretos. A an´alise foi capaz de detetar todas as falhas de seguran¸caintroduzidas, sem falsos positivos nem falsos negativos.Em rela¸c˜ao `as f´abricas de software A e B, seria virtualmente imposs´ıvel valid´a-las completamente, devido `as suas dimens˜oes, falta de contexto, complexidade depol´ıticas de seguran¸ca e quantidade de resultados em cada relat´orio. Foi feitauma amostragem de resultados de an´alises `as f´abricas A e B, que foi validadamanualmente.Para validar a nossa an´alise das f´abricas A e B, obtivemos algumas pol´ıticasde seguran¸ca dos clientes, e tamb´em definimos algumas pol´ıticas nossas. Para asregras que definimos, escolhemos entidades que inclu´ıam informa¸c˜ao sens´ıvel edeclaramos que os roles p´ublicos n˜ao devem ter acesso a estas entidades. Note-seque todos os utilizadores com uma conta tˆem por defeito o role Registered etodos os utilizadores tˆem por defeito o role Anonymous . Estes dois roles v˜ao tera maior pool de utilizadores, por esse motivo entidades sens´ıveis n˜ao devem seracedidas por utilizadores que s´o possuam roles atribu´ıdos por defeito.Da f´abrica A foram usadas duas pol´ıticas de seguran¸ca fornecidas pelos donosda f´abrica. Execut´amos a an´alise e obtemos dois relat´orios. Do que observ´amos,a f´abrica A parece estar bem protegida, pois os dois relat´orios s˜ao pequenos(quando comparados com os da f´abrica B). A Tabela 1 cont´em os resultados danossa valida¸c˜ao `a f´abrica A.As pol´ıticas de seguran¸ca usadas para a f´abrica A foram: – A entidade da
Pol´ıtica 1 cont´em informa¸c˜ao relacionada com uma aplica¸c˜aode feedback de empregados, e restringe acesso a utilizadores que tenhamapenas os roles por defeito do sistema. – A entidade da
Pol´ıtica 2 cont´em informa¸c˜ao relacionada com o sistema degest˜ao financeira duma empresa. Esta entidade s´o deve ser acedida pelos roles de administrador, back-office ou de gestor financeiro. n´alise de Seguran¸ca Baseada em Roles para F´abricas de Software 9
Ecr˜as com Ecr˜as % ecr˜as Falhas Falsos % falhasfalhas validados validados reais positivos reaisPol´ıtica 1
280 20 ≈
7% 18 2 90%
Pol´ıtica 2
Pol´ıtica 3
Pol´ıtica 4
14 7 50% 7 0 100%
Pol´ıtica 5
42 8 ≈
19% 8 0 100%
Tabela 2.
Valida¸c˜ao dos resultados da f´abrica de software B
O relat´orio obtido com a pol´ıtica 1 mostrou 5 ecr˜as com falhas de seguran¸ca.Todas as 5 falhas reportadas eram falsos positivos, causados por uma limita¸c˜aona nossa an´alise. A quest˜ao ´e que a equipa de desenvolvimento da f´abrica Autilizam outros mecanismos de seguran¸ca para al´em das primitivas
CheckRole .Nestes casos o resultado duma query estava a ser filtrado pelo identificador doutilizador.O relat´orio obtido com a pol´ıtica 2 mostrou 9 ecr˜as com falhas de seguran¸ca.Os 9 ecr˜as foram validados e continham falhas de seguran¸ca. Estes ecr˜as n˜aotinham os roles corretos nas suas permiss˜oes e n˜ao possu´ıam nenhum mecanismode seguran¸ca nas a¸c˜oes que invocavam.Da f´abrica B foram usadas 5 pol´ıticas de seguran¸ca, cada uma relacionadacom uma entidade na f´abrica: – A entidade da
Pol´ıtica 1 cont´em informa¸c˜ao pessoal sobre os clientes daempresa, e pro´ıbe o seu acesso a utilizadores que s´o tenham os roles pordefeito do sistema; – A entidade da
Pol´ıtica 2 cont´em informa¸c˜ao sobre o sistema de biom´etricada empresa, e pro´ıbe o seu acesso a utilizadores que s´o tenham os roles pordefeito do sistema; – A entidade da
Pol´ıtica 3 cont´em informa¸c˜ao espec´ıfica sobre empregadosda empresa, e pro´ıbe o seu acesso a utilizadores que s´o tenham os roles pordefeito do sistema; – A entidade da
Pol´ıtica 4 cont´em informa¸c˜ao sobre o stock dum produtoutilizado na empresa, e pro´ıbe o seu acesso a utilizadores que s´o tenham os roles por defeito do sistema; – A entidade da
Pol´ıtica 5 cont´em informa¸c˜ao espec´ıfica sobre alguns clientesda empresa, e pro´ıbe o seu acesso a utilizadores que s´o tenham os roles pordefeito do sistema.A Tabela 2 cont´em os resultados da nossa valida¸c˜ao da f´abrica B. Alguns dosrelat´orios n˜ao foram completamente validados, pois tinham muitas entradas ou acomplexidade de algumas a¸c˜oes era demasiada alta para conseguir validar semter contexto da f´abrica de software.Dos 45 ecr˜as com falhas reportadas que valid´amos, mais de 95% tinhamfalhas que necessitaram de ser corrigidas. Estes resultados s˜ao muito positivos emostram que a nossa an´alise ´e capaz de encontrar falhas relevantes em f´abricasde software.
F´abrica ApplicationObjects Tamanho(M´odulos) Tamanho(MB) Gerargrafo (s) N´osgrafo ArcosgrafoMock-up
28 2 2 < A
772 34 24 101 3581 10352 B Tabela 3.
Resultados de carregar e gerar 3 diferentes f´abricas de software
A maioria das falhas encontradas foram casos triviais em que um ecr˜a n˜aotinha as permiss˜oes corretas e as a¸c˜oes que chamava n˜ao tinham mecanismos deseguran¸ca. Estas falhas s˜ao f´aceis de corrigir, assim que detetadas, mas tendoem conta a dimens˜ao da f´abrica B a sua dete¸c˜ao manual n˜ao ´e exequ´ıvel. Assimsendo, a nossa an´alise ´e essencial para as equipas de desenvolvimento assegurarema seguran¸ca nas suas f´abricas de software.Para exemplificar a gravidade de algumas das falhas encontradas, a falhaque encontr´amos usando a pol´ıtica 2 comprometia a seguran¸ca do sistema debiom´etrica da f´abrica. Um dos ecr˜as que permitia utilizadores criarem ou alteraremas impress˜oes digitais no sistema n˜ao estava restrito ao conjunto certo de roles en˜ao existia nenhum mecanismo de seguran¸ca nas suas a¸c˜oes. Isto permitia queum atacante inserisse a sua pr´opria impress˜ao digital no sistema, ou at´e queremovesse ou alterasse a de outro utilizador, fazendo-se passar por ele. Valid´amosesta falha de seguran¸ca com os donos da f´abrica, que confirmaram a sua gravidadee o desconhecimento da sua existˆencia.Os 2 falsos positivos detetados devem-se a limita¸c˜oes da nossa an´alise, referidasna Sec¸c˜ao 2. Nestas entradas do relat´orio est˜ao a ser usados outros mecanismosde seguran¸ca que ainda n˜ao s˜ao contemplados pela nossa an´alise.A an´alise possui algumas limita¸c˜oes. Nomeadamente, outros mecanismos deseguran¸ca para al´em de check roles com condicionais podem ser usados, e a an´aliseainda n˜ao os deteta, resultando em falsos positivos. Outra limita¸c˜ao consiste emsitua¸c˜oes onde a condi¸c˜ao dentro dum bloco condicional cont´em um check role em disjun¸c˜ao com outra express˜ao. Condi¸c˜oes com disjun¸c˜oes n˜ao s˜ao triviais e ´edif´ıcil inferir os roles do utilizador em cada ramo do bloco condicional. Nestasitua¸c˜ao, a nossa an´alise segue uma abordagem conservadora, que pode resultarem falsos positivos. Apesar disto, falsos positivos s˜ao uma caracter´ıstica comumem an´alises est´aticas, e a existˆencia deles n˜ao tira valor `as falhas encontradascom sucesso.
Para avaliar a performance da nossa an´alise, ger´amos 20 relat´orios utilizandov´arias pol´ıticas de seguran¸ca na f´abrica B. Para avaliar a performance da nossaan´alise combinamos pol´ıticas definidas especificamente para a avalia¸c˜ao compol´ıticas fornecidas pelos donos da f´abrica.O tempo de execu¸c˜ao m´edio foi de cerca de 5 minutos, com os piores casos porvolta dos 14 minutos. O objetivo desta t´ecnica ´e gerar um relat´orio de seguran¸cadepois de executar a an´alise, o qual ser´a posteriormente inspecionado. Como tal,tempos de execu¸c˜ao mais longos n˜ao s˜ao problem´aticos n´alise de Seguran¸ca Baseada em Roles para F´abricas de Software 11
F´abrica Tamanho (M´odulos) Tamanho (MB) Espa¸co em mem´oria (MB)
Mock-up 2 2 ≈
90A 34 25 ≈ ≈ Tabela 4.
Espa¸co em mem´oria de 3 diferentes f´abricas de software
Em termos de escalabilidade, medimos o tempo de carregar e gerar o modelosintetizado das 3 f´abricas, o tamanho resultante dos grafos, e o espa¸co ocupado emmem´oria pelos modelos sintetizados de cada f´abrica. As Tabelas 3 e 4 cont´em osresultados destas observa¸c˜oes. Na segunda coluna da Tabela 3, o termo
ApplicationObjects ´e uma m´etrica usada em OutSystems, que conta o n´umero de p´aginas etabelas existentes numa f´abrica .Os resultados da nossa an´alise foram representativos e atingiram os objetivosa que nos propusemos. Escalabilidade n˜ao foi um problema, mesmo ao analisarum f´abrica com as dimens˜oes da B. Em ambas as f´abricas foram encontradasfalhas graves, com um n´umero reduzido de falsos positivos. Ainda que graves,a corre¸c˜ao da maioria das falhas ´e trivial, sendo o maior desafio a sua dete¸c˜aomanual.A an´alise possu´ı valor, pois vai ajudar as equipas de desenvolvimento aassegurarem a seguran¸ca nas suas f´abricas de software, reduzindo o tempodespendido no processo de dete¸c˜ao manual de falhas de seguran¸ca. Estas equipasde desenvolvimento trabalham sobre plataformas low-code , onde podem faltarferramentas para fazerem testes extensivos. Al´em disso, mesmo com bons testes´e poss´ıvel n˜ao apanhar todas as falhas, logo uma an´alise est´atica como a queapresentamos ´e ´util. e Os clientes que forneceram as f´abricas mostraram interessena an´alise e esperam poder integrar a an´alise no processo de desenvolvimento deaplica¸c˜oes. O modelo de Role-Based Access Control (RBAC) [8] proposto por Sandhusimplifica a atribui¸c˜ao de permiss˜oes a utilizadores dum sistema. Em vez de seatribu´ırem permiss˜oes a utilizadores individuais, criam-se roles e atribuem-se roles aos utilizadores, e as permiss˜oes s˜ao dadas a roles em vez de utilizadores.A nossa an´alise possu´ı algumas semelhan¸cas a t´ecnicas de taint analysis [1, 7,9, 10], t´ecnicas que detetam caminhos em que informa¸c˜ao n˜ao confi´avel consigachegar a locais sens´ıveis onde n˜ao devia chegar, sem serem desclassificados. ´Eposs´ıvel fazer uma analogia destes caminhos com aqueles que nossa an´alise deteta.A diferen¸ca ´e que taint analysis s˜ao detetados dados n˜ao confi´aveis, enquanto anossa an´alise deteta roles que acedem a indevidamente recursos protegidos.Mais semelhantes `a nossa an´alise s˜ao as t´ecnicas de Model Checking [2–6],que exploram todos os estados poss´ıveis dum sistema de modo a verificar se ele https://success.outsystems.com/Support/Enterprise_Customers/Licensing/Overview/Application_Object_count cumpre com um dado conjunto de propriedades. A nossa an´alise verifica se existealgum estado que n˜ao cumpra a pol´ıtica de seguran¸ca definida. Da mesma formaque a nossa an´alise come¸ca por usar um call graph para detetar poss´ıveis falhas,a t´ecnica CEGAR [5], tamb´em come¸ca por utilizar um modelo mais abstrato dosistema, e s´o quando deteta erros no modelo abstrato ´e que o refina com maisinforma¸c˜ao para verificar o erro detetado. Neste artigo apresent´amos uma t´ecnica an´alise de seguran¸ca est´atica que detetafalhas de seguran¸ca ao n´ıvel de roles em f´abricas de software.A t´ecnica foi implementada para f´abricas de software OutSystems e detetoucom sucesso falhas de seguran¸ca em f´abricas de software de clientes, algumasdelas graves, que dificilmente seriam detetadas sem uma ferramenta de an´alise.Estas falhas j´a estavam presentes nas f´abricas h´a bastante tempo e n˜ao tinhamsido encontradas manualmente.Como trabalho futuro, ´e particularmente importante endere¸car outros meca-nismos de seguran¸ca para al´em de check roles com condicionais e desta formareduzir o n´umeros de falsos positivos. Planeamos melhorar e aperfei¸coar a fer-ramenta de modo a que possa ser integrada no ambiente de desenvolvimentoOutSystems.
Acknowledgements:
This work was partially supported by NOVA LINCS(UID/CEC/ 04516/2013) and FCT project PTDC/CCI-INF/32081/2017.
Referˆencias
1. Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., Le Traon, Y.,Octeau, D., McDaniel, P.: Flowdroid: Precise context, flow, field, object-sensitiveand lifecycle-aware taint analysis for android apps. In: PLDI (2014)2. Baier, C., Katoen, J.P.: Principles of model checking. MIT press (2008)3. Biere, A., Cimatti, A., Clarke, E.M., Strichman, O., Zhu, Y., et al.: Bounded modelchecking. Advances in computers (11) (2003)4. Burch, J.R., Clarke, E.M., McMillan, K.L., Dill, D.L., Hwang, L.J.: Symbolic modelchecking: 1020 states and beyond. Information and computation (2) (1992)5. Clarke, E., Grumberg, O., Jha, S., Lu, Y., Veith, H.: Counterexample-guidedabstraction refinement for symbolic model checking. Journal of the ACM (JACM) (5) (2003)6. Clarke Jr, E.M., Grumberg, O., Kroening, D., Peled, D., Veith, H.: Model checking.MIT press (2018)7. Newsome, J., Song, D.X.: Dynamic taint analysis for automatic detection, analysis,and signaturegeneration of exploits on commodity software. In: NDSS. vol. 5 (2005)8. Sandhu, R.S.: Role-based access control. In: Advances in computers, vol. 46 (1998)9. Tripp, O., Pistoia, M., Cousot, P., Cousot, R., Guarnieri, S.: Andromeda: Accurateand scalable security analysis of web applications. In: FASE (2013)10. Tripp, O., Pistoia, M., Fink, S.J., Sridharan, M., Weisman, O.: Taj: Effective taintanalysis of web applications. SIGPLAN Not.44