Relatório de Análise Técnica............................. SEGESP AL – Secretaria de Estado da Gestão Pública da...... Alag...
.    .    .    .    .    .    .    .    .    .                                                                          RE...
.    .    .    .    .    .    .    .    .    .                                                                            ...
RELATÓRIO DE ANÁLISE TÉCNICACENÁRIOEm 1996 o Estado de Alagoas terceirizou a operação do seu Sistema Integrado de RH, deno...
RELATÓRIO DE ANÁLISE TÉCNICAOBJETIVORealizar uma análise técnica de segurança no Sistema Informatizado de Recursos Humanos...
RELATÓRIO DE ANÁLISE TÉCNICAAuditoria e Monitoramento Eletrônico     As informações sensíveis, confidenciais e valiosas sã...
RELATÓRIO DE ANÁLISE TÉCNICA                Não houve   bloqueio da senha mesmo apos várias tentativas de autenticação    ...
RELATÓRIO DE ANÁLISE TÉCNICA              (Observar que o usuário PRODFP possui a senha r0u553au, armazenada em           ...
RELATÓRIO DE ANÁLISE TÉCNICA     A criação da senha pelo pessoal interno permite que os mesmos possam se fazer passar pelo...
RELATÓRIO DE ANÁLISE TÉCNICAEm sistemas multicamadas, cada camada interposta gera maior possibilidade de contorno dosmecan...
RELATÓRIO DE ANÁLISE TÉCNICA      O controle de acesso deve ser uniforme em todo o sistema, utilizando-se uma única rotina...
RELATÓRIO DE ANÁLISE TÉCNICAutilizados no sistema para a proteção de dados sensíveis e senhas dos usuários devem ser basea...
RELATÓRIO DE ANÁLISE TÉCNICAComunicação de dados     Interfaces desprotegidas entre um sistema e outros são pontos vulnerá...
RELATÓRIO DE ANÁLISE TÉCNICAIdentificação e autenticação     As credenciais coletadas do usuário (login e senha) precisam ...
RELATÓRIO DE ANÁLISE TÉCNICAA comunicação com servidores e outros componentes do sistema, em particular quando estacomunic...
RELATÓRIO DE ANÁLISE TÉCNICAApós a autenticação do usuário, deve ser apresentada a data e a hora da última autenticação be...
RELATÓRIO DE ANÁLISE TÉCNICAPrivilégios de usuário      Em sistemas utilizados por vários usuários, é importante adotar um...
RELATÓRIO DE ANÁLISE TÉCNICA                      dados.                      Por não termos acesso ao código fonte do sis...
RELATÓRIO DE ANÁLISE TÉCNICA       Um manual do administrador contendo procedimentos para o caso de incidentes ou falhas d...
RELATÓRIO DE ANÁLISE TÉCNICACONCLUSÃOIniciamos o trabalho colhendo as experiências vividas na operação diária do sistema E...
RELATÓRIO DE ANÁLISE TÉCNICA               informações não podem ser expostas pelo sistema. Desta forma ferem-se os precei...
RELATÓRIO DE ANÁLISE TÉCNICAdesenvolvimento do sistema não adotou esta prática e que o seu controle de qualidade não captu...
Upcoming SlideShare
Loading in …5
×

Segesp laudo técnico sistema elógica

1,002 views
891 views

Published on

Laudo sobre o sistema da folha de pagamento que rodava em Alagoas.

Published in: News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,002
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Segesp laudo técnico sistema elógica

  1. 1. Relatório de Análise Técnica............................. SEGESP AL – Secretaria de Estado da Gestão Pública da...... Alagoas..... ANÁLISE DE SEGURANÇA DO SISTEMA INFORMATIZADO.... DE RECURSOS HUMANOS - ELÓGICARH.................................................................................................................... MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008
  2. 2. . . . . . . . . . . RELATÓRIO DE ANÁLISE TÉCNICA . . . . . . . . . . . . . . . . ATENÇÃO . . . . . . . . As informações existentes neste documento e em seus anexos são para uso restrito da SEGESP – sendo seu sigilo . . protegido por lei. A leitura e publicação indevidas poderão causar perdas materiais, financeiras e de vantagem . . competitiva. Caso não seja destinatário, saiba que sua leitura, divulgação e cópia são proibidas. O uso impróprio . . . . será tratado pela legislação em vigor, por acordos de sigilo e pelas normas internas da Módulo e da Organização . . contratante dos serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . São Paulo . . Av. Eng. Luis Carlos Berrini, 550 - 5º andar . . Brooklin - São Paulo - SP . . CEP: 04571-000 . . . . Tel/Fax: (+11) 5504-3600 . . . . . . Rio de Janeiro . . . . Rua da Quitanda, 106 Centro . . 20091-005 - Rio de Janeiro - RJ . . Pabx: (+21) 2206-4600 . . Fax: (+21) 2206-4720 . . . . . . . . Brasília . . SCN, Quadra 5, Bloco A . . Centro Empresarial Brasília Shopping and Towers . . Torre Norte, sala 918 . . Brasília - DF . . . . CEP: 70.715-900 . . Tel: (+61) 3218-7500 . . Fax: (+61) 3218-7506 . . . . . . . Nova Iorque . . 52 Vanderbilt Avenue - 14th floor . . . . New York, N.Y. 10017 . . Tel.: (212) 609-0340 . . Cel.: (973) 563-2402 . . . . . . . . . . . . .MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 2/22
  3. 3. . . . . . . . . . . RELATÓRIO DE ANÁLISE TÉCNICA . . . . . . . . . . . . . . . . . . . . . Sumário . . . . . . CENÁRIO ............................................................................................. 4 . . . . OBJETIVO ........................................................................................... 5 . . . . ESCOPO DA ANÁLISE TÉCNICA DE SEGURANÇA ................... 5 . . . . ANÁLISE DE SEGURANÇA .............................................................. 5 . . . . AUDITORIA E MONITORAMENTO ELETRÔNICO ................................................... 6 . . CONTAS E SENHAS .......................................................................................... 6 . . CONTROLE DE ACESSO .................................................................................... 9 . . CRIPTOGRAFIA .............................................................................................. 11 . . . . COMUNICAÇÃO DE DADOS .............................................................................. 13 . . IDENTIFICAÇÃO E AUTENTICAÇÃO ................................................................... 14 . . PRIVILÉGIOS DE USUÁRIO............................................................................... 17 . . TOLERÂNCIA A FALHAS .................................................................................. 17 . . DOCUMENTAÇÃO ........................................................................................... 18 . . . . CONCLUSÃO ..................................................................................... 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 3/22
  4. 4. RELATÓRIO DE ANÁLISE TÉCNICACENÁRIOEm 1996 o Estado de Alagoas terceirizou a operação do seu Sistema Integrado de RH, denominadoElógicaRH para a Elógica S/A, fornecedora do sistema, que se manteve como prestadora destaterceirização até o início de 2007. A operação reiniciou a ser operada pelo funcionalismo público no iníciode 2007, através da passagem do sistema e de seus processos para a SEGESP.Ao fim do prazo contratual original, se seguiu um período de meses durante os quais as partesnegociaram novos termos e condições para a prorrogação contratual por 12 meses e o encerramento daoperação do sistema pela Elógica, com a transferência da referida operação para o funcionalismo doEstado, mediante treinamento apropriado.Durante a transição e operação do sistema ElógicaRH, foram identificados erros e comportamentos nosistema que expunham informações sensíveis como senhas de usuário administrador do banco de dadosdo sistema, permitindo e criando um meio de acesso a usuários não autorizados. Estas descobertasforam relatadas ao fornecedor, ao qual foram solicitados os ajustes e acertos necessários para quefossem sanadas.Diversas medidas foram tomadas em busca da solução dos problemas encontrados mas, conformedescrito pela SEGESP, apenas alguns foram resolvidos.Este relatório tem o propósito de apresentar um parecer técnico com base na análise dos resultadosalcançados face às melhores práticas de mercado.A análise foi baseada em normas e melhores práticas para o Desenvolvimento de Sistemas e Segurançada Informação, a saber, ISO 15408 Common Criteria. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 4/22
  5. 5. RELATÓRIO DE ANÁLISE TÉCNICAOBJETIVORealizar uma análise técnica de segurança no Sistema Informatizado de Recursos Humanos utilizado pelaSEGESP AL, denominado ElógicaRH, e realizar testes para a comprovação da ocorrência dos erros nosistema que expõem o usuário e senha do administrador.Este relatório descreve com a verdade, e com todas as circunstâncias, o que foi observado.ESCOPO DA ANÁLISE TÉCNICA DE SEGURANÇAPara efeito desta análise foram considerados somente os ativos diretamente relacionados com o SistemaInformatizado de Recursos Humanos – ElógicaRH, conforme apresentado a seguir: • Servidor de Aplicação – 10.10.0.1; • Servidor de Banco de Dados 01; • Servidor de Banco de Dados 02.ANÁLISE DE SEGURANÇAFoi realizada uma análise de segurança no Sistema Informatizado de Recursos Humanos – ElógicaRH, deforma criteriosa, com o objetivo de identificar as possíveis falhas de segurança através da não aplicaçãoe/ou aplicação incorreta dos controles de segurança recomendados pelas normas internacionais e quena sua ausência podem propiciar o acesso não autorizado, manipulação indevida, perda, divulgação enão rastreabilidade das informações no Sistema ElógicaRH.O resultado da análise de segurança é apresentada a seguir. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 5/22
  6. 6. RELATÓRIO DE ANÁLISE TÉCNICAAuditoria e Monitoramento Eletrônico As informações sensíveis, confidenciais e valiosas são os mais prováveis alvos de ataques e tentativas de ataque. Todos os sistemas que possuam informações deste tipo devem ser configurados para registrar acessos e alterações em dados sensíveis mantidos pela aplicação, pois a falta de um mecanismo de auditoria torna bem mais difícil a tarefa de identificar a ação e responsabilizar o autor, introduzindo a falta de rastreabilidade. • Referências: Common Criteria: FAU_GEN.1, FDP_ACF.1, nível básico. Resultado da Análise Não foi identificado qualquer tipo de mecanismo e/ou registro de auditoria no Sistema Informatizado de Recursos Humanos – ElógicaRH em uso pela SEGESP.Contas e Senhas A tentativa de quebra de senha por força bruta é, de forma geral, o primeiro método testado por um atacante, pois é de simples aplicação e pode gerar resultados significativos. Para evitar este tipo de ataque, utilizam-se medidas passivas (métrica da senha, troca periódica de senha) e medidas ativas (bloqueio após um determinado número de tentativas com falha). • Referências: Common Criteria: AVA_SOF.1, FIA_SOS.1, FIA_UAU.3, FIA_AFL.1, FMT_SAE.1, FIA_ATD.1, FTA_TSE.1, FPT_TSM.1. Resultado da Análise Apos vários teste não foi observada a exigência de métricas que definam a complexidade mínima da senha e da troca da senha. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 6/22
  7. 7. RELATÓRIO DE ANÁLISE TÉCNICA Não houve bloqueio da senha mesmo apos várias tentativas de autenticação com uso de senha errada.As senhas do sistema devem ser armazenadas cifradas de forma irreversível pelo sistema, o que podeser obtido através do uso de algoritmos e funções de "hash", que convertem, de forma irreversível ainformação em um dado pequeno, ou seja, o dado apenas pode ser transformado de texto para cifrado,mas não pode ser decifrado para o texto original. O uso de "hash" garante que sequer o administradordo banco de dados conheça as senhas do sistema. Esta estratégia evita problemas de ataque oriundo dopessoal interno, ataques de invasores que consigam ganhar acesso ao banco de dados e problemaslegais quanto a responsabilização dos usuários mal intencionados das aplicações, evitando que aleguemque a senha era de conhecimento de outros dentro da organização. • Referências: Common Criteria: FIA_UAU.3 Resultado da Análise Foram identificados senhas de acesso aos banco de dados armazenadas sem nenhum tipo de criptografia na tabela TBSRV conforme evidência abaixo, na coluna SENHADB. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 7/22
  8. 8. RELATÓRIO DE ANÁLISE TÉCNICA (Observar que o usuário PRODFP possui a senha r0u553au, armazenada em texto claro). Quando são executadas tarefas que realizem acesso ao banco de dados, identificamos que as senhas não possuem qualquer tipo de criptografia no arquivo de texto C:/RHcexecucao_DLL.LOG, conforme evidências abaixo: (Foi utilizado o usuário PRODFP com a senha TESTE123).MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 8/22
  9. 9. RELATÓRIO DE ANÁLISE TÉCNICA A criação da senha pelo pessoal interno permite que os mesmos possam se fazer passar pelos usuários , indevidamente, ao utilizarem o sistema. Este modelo de criação de senhas também impede a responsabilização do usuário autêntico por eventual uso indevido do sistema, visto que outras pessoas conhecem sua senha. Assim a aplicação deve ser desenvolvida de forma que exista um mecanismo de escolha da senha para os novos usuários sem a interferência do pessoal interno. • Referências: FIA_SOS.2, FMT_MOF.1, FMT_SMR.1. Resultado da Análise Não foram identificados mecanismos de escolha de senha para os novos usuários. As senhas são criadas pela equipe de suporte do sistema e informadas aos usuários finais.Controle de acesso Sistemas web, "web services" e outros são baseados em protocolos sem sessão, ou seja, cada solicitação de informações ao servidor é independente da outra. Isso implica em que os dados acessados na primeira solicitação sejam inacessíveis às demais solicitações. Neste tipo de sistema é importante que o controle de acesso seja verificado em cada página e em cada informação apresentada, pois os parâmetros de chamada ou links podem ser manipulados muito facilmente. Assim o controle de acesso em sistemas distribuídos que utilizem protocolos sem sessão, como http, deve ser verificado a cada evento. • Referências: Common Criteria: FPT_TDC.1, FPT_RVM.1, FPT_SSP.1, FTP_TRP.1, FTP_ITC.1. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada deste controle. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 9/22
  10. 10. RELATÓRIO DE ANÁLISE TÉCNICAEm sistemas multicamadas, cada camada interposta gera maior possibilidade de contorno dosmecanismos de acesso. Por exemplo, a verificação dos direitos de acesso na camada de apresentação,ou seja, na camada mais próxima ao usuário, possibilita que este possa depurar ou alterardeliberadamente tal camada. Quanto mais próximo dos dados, menor a possibilidade de quebra oucontorno dos mecanismos de controle de acesso, ou seja, o controle de acesso é tão mais eficaz quantomais próximo dos dados for implementado. Assim, em sistemas multicamadas, o controle de acessodeve ser feito na camada mais próxima possível dos dados. • Referências: Common Criteria: AVA_CCA.1, FDP_ACF.1, FDP_ACC.1, FDP_IFC.1, FDP_IFF.1, FPT_TDC.1, FPT_RVM.1. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada deste controle.O sistema de controle de acesso deve ser aplicado diretamente nos dados armazenados, indicandodireitos para cada usuário ou grupo, o que pode ser implementado incluindo uma lista de controle deacesso ou outra forma discricionária de controle de acesso. • Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada desta recomendação. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 10/22
  11. 11. RELATÓRIO DE ANÁLISE TÉCNICA O controle de acesso deve ser uniforme em todo o sistema, utilizando-se uma única rotina de verificação no sistema, evitando inconsistências relacionadas aos direitos de acesso aos objetos da aplicação, ou seja, garantindo que as alterações na política de controle de acesso fiquem efetivas em todo o código. Esta recomendação também facilita a auditoria de códigos maliciosos, pois qualquer condição para controle de acesso, fora do padrão, é automaticamente inválida. • Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1, FPT_TDC.1, FPT_RVM.1. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada desta recomendação. O controle de acesso independente do código do sistema, fora do contexto do usuário logado, evita que este possa depurar o mecanismo de implementação, alterando seu comportamento e obtendo acesso privilegiado indevido. Também evita que a rotina de verificação seja executada com direitos do usuário final do sistema. Isto, em última análise, permitiria que o usuário tivesse algum direito sobre a tabela de direitos de acesso. Assim o controle de acesso deve ser realizado por componente isolado do sistema. • Referências: Common Criteria: FDP_ACC.1, FDP_ACF.1, FPT_SEP.2, FPT_TDC.1, FPT_RVM.1. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada desta recomendação.Criptografia Algoritmos proprietários, desenvolvidos internamente, geralmente são facilmente vulneráveis a ataques por criptoanálise. De fato, os algoritmos públicos seguros, RSA, DES, 3DES, IDEA, etc., são escolhidos justamente por serem insusceptíveis a estes ataques. Desta forma os algoritmos de criptografia MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 11/22
  12. 12. RELATÓRIO DE ANÁLISE TÉCNICAutilizados no sistema para a proteção de dados sensíveis e senhas dos usuários devem ser baseados empadrões reconhecidos do mercado. • Referências: Common Criteria: FCS_CKM.1, FCS_CKM.2, FCS_COP.1. Resultado da Análise Não foi identificada a utilização de criptografia para a proteção de dados sensíveis ou senhas, conforme a evidencia abaixo na qual o nome e senha do usuário que conecta a aplicação ao banco de dados são expostas: MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 12/22
  13. 13. RELATÓRIO DE ANÁLISE TÉCNICAComunicação de dados Interfaces desprotegidas entre um sistema e outros são pontos vulneráveis que podem ser explorados por um atacante. Para evitar que a visualização indevida, ou mesmo, que ocorra manipulação dos dados, deve-se cuidar para que os dados estejam protegidos quanto à confidencialidade e à integridade na comunicação entre sistemas. Assim o sistema aplicativo deve ser desenvolvido de forma que os dados enviados para outros sistemas sejam protegidos contra quebra de confidencialidade no trajeto. • Referências: Common Criteria: FCS_CKM.1, FCS_CKM.2, FCS_COP.1. Resultado da Análise A comunicação entre o servidor de aplicação e os bancos de dados é realizada através do protocolo padrão SQL sem criptografia, como também a comunicação entre o cliente web HTTP com o servidor de aplicação, da mesma forma, ocorre sem criptografia, conforme as evidências abaixo: MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 13/22
  14. 14. RELATÓRIO DE ANÁLISE TÉCNICAIdentificação e autenticação As credenciais coletadas do usuário (login e senha) precisam ser enviadas para o mecanismo de autenticação, e o resultado da autenticação (a autorização ou chave de sessão) deve ser devolvido por este. Um ataque simples consiste em interceptar uma autenticação correta e obter a chave de sessão ou gravar os dados trafegados entre cliente e servidor e, em seguida, enviar novamente estes dados obtendo como resposta uma chave de sessão válida. Um caso particular ocorre quando as credenciais são enviadas em claro para o servidor, o que, evidentemente, torna este ataque ainda mais simples. Assim a senha deve ser verificada por meio de mecanismo que impeça fraudes de repetição, interceptação ou quebra de integridade na comunicação entre o cliente e o servidor. • Referências: Common Criteria: FIA_UAU.3, FIA_UAU.4. Resultado da Análise Por não termos acesso ao código fonte do sistema, não foi possível determinar a implementação correta e adequada desta recomendação. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 14/22
  15. 15. RELATÓRIO DE ANÁLISE TÉCNICAA comunicação com servidores e outros componentes do sistema, em particular quando estacomunicação passa por redes sem o devido controle, ou por servidores intermediários de terceiros, podelevar a desvios de rota, conduzindo as informações a um sistema que simule a outra parte dacomunicação, possibilitando a obtenção ou alteração indevida de informações. Assim todos os demaiscomponentes do sistema devem ser autenticados pelo aplicativo antes da comunicação em sistemasdistribuídos. • Referências: Common Criteria: FTP_ITC.1, FTP_TRP.1. Resultado da Análise Não foram identificados mecanismos que garantam a autenticação dos componentes do sistema antes da comunicação.O usuário ou atacante pode alegar desconhecer o caráter legal e confidencial das informações ao acessaro sistema. A exibição de uma mensagem de advertência durante a autenticação tem como propósitodeixar claro que o sistema em questão pertence à empresa e é de uso restrito pelos usuáriosautorizados, informando também que os acessos serão gravados em registros de auditoria (logs).A mensagem também ajuda a aumentar a consciência dos usuários sobre a importância da segurançadas informações armazenadas no sistema e de sua responsabilidade sobre a segurança. Do ponto devista legal, é recomendável deixar claro que o uso do sistema ou serviço é restrito e que o acessoindevido poderá ter conseqüências. Desta forma, uma mensagem de advertência precisa ser exibida aosusuários durante a autenticação no sistema. • Referências: Common Criteria: FTA_TAB.1 Resultado da Análise Não foram observadas tais mensagens de advertência durante o processo de logon dos usuários ou em qualquer outro momento do uso do sistema. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 15/22
  16. 16. RELATÓRIO DE ANÁLISE TÉCNICAApós a autenticação do usuário, deve ser apresentada a data e a hora da última autenticação bemsucedida e se houve falhas de autenticação desde então. Este controle permite que o usuário identifiquese houve algum acesso indevido a sua conta, pois ele pode confrontar a hora do último acesso bemsucedido indicado com seu último acesso real. O usuário poderá também identificar se houve tentativasmal sucedidas de acesso a sua conta, pois na eventualidade dele mesmo ter errado a senha, saberá distoe poderá confrontar a informação. • Referências: Common Criteria: FTA_TAB.1 Resultado da Análise Durante o processo de autenticação, não foi observada a apresentação da data e hora da última autenticação bem sucedida ou de tentativas de logon mal sucedidas desde então.Mensagens trocadas entre sistemas ou internamente ao sistema, entre seus diversos componentes,podem estar sujeitas a posterior negação de sua autoria. O caso mais típico é o usuário que altera umainformação sensível no sistema e depois nega ter feito esta alteração. Este tipo de repúdio pode ocorrerentre instituições e mesmo entre equipes em uma mesma empresa, provocando constrangimentos ouconseqüências piores. Assim o sistema aplicativo deve ser desenvolvido de forma que as transaçõescríticas do sistema possuam mecanismos que identifiquem inequivocamente sua autoria. • Referências: Common Criteria: FCO_NRO.1, FCO_NRR.1, FTP_ITC.1, FTP_TRP.1. Resultado da Análise Não foram identificados quaisquer tipo de mecanismo e/ou registro de auditoria que identifiquem a autoria das ações e transações críticas no sistema. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 16/22
  17. 17. RELATÓRIO DE ANÁLISE TÉCNICAPrivilégios de usuário Em sistemas utilizados por vários usuários, é importante adotar um prazo de validade do privilégio de acesso, para evitar que os usuários mantenham tais privilégios após terem sido movidos de área ou quando desligados da empresa ou ainda, quando o gestor da área é substituído. Assim os privilégios do usuário devem ser configurados para expirar periodicamente, sendo necessário requisitar renovação. • Referências: Common Criteria: FMT_SAE.1, FMT_MOF.1, FMT_MSA.1. Resultado da Análise Não foram identificadas funcionalidades de expiração de contas no sistema.Tolerância a falhas O sistema aplicativo deve ser desenvolvido de forma a possuir capacidade de tolerância a falhas e retorno à operação. Falhas de hardware, de software, de sistemas de comunicação e do usuário são eventos esperados, em maior ou menor grau, na vida útil de qualquer sistema. Estes incidentes podem provocar paralisações indesejáveis nas operações no negócio, causar retrabalhos, constrangimentos junto a clientes, e outras conseqüências indesejáveis. O sistema deve portanto, ser dotado de recursos que garantam os aspectos básicos de segurança, como a confidencialidade e a integridade dos dados críticos, e quaisquer outros aspectos de segurança importantes. Deve-se também buscar o retorno do sistema a um estado seguro e operacional no menor tempo possível. • Referências: Common Criteria: FPT_PHP.1, FPT_PHP.2, FPT_FLS.1, FPT_RCV.1, FDP_ROL.1. Resultado da Análise Não foram identificados no sistema funcionalidades ou características de arquitetura que garantam a alta disponibilidade da aplicação ou do banco de MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 17/22
  18. 18. RELATÓRIO DE ANÁLISE TÉCNICA dados. Por não termos acesso ao código fonte do sistema, não foi possível determinar se existem controles no banco de dados e na aplicação que garantam a integridade das informações em caso de falha de hardware e software, tais como funções que verifiquem os parâmetros de entrada e o retorno das funções chamadas internamente e controles de transação em banco de dados (Begin Trans, Commit, rollback).Documentação A especificação de um sistema documenta os requisitos do mesmo e sua arquitetura básica, e deve ser produzida durante o planejamento. Um planejamento ineficaz acarreta problemas na arquitetura da segurança do sistema, com ausência de funções de controle de segurança necessárias para o atendimento aos objetivos de segurança. Portanto, é importante que todas as necessidades de segurança específicas sejam avaliadas, consideradas e formalizadas na especificação do sistema. Além disto, esta documentação será útil para o aceite do sistema e para futuras auditorias de segurança. A documentação deve possuir as características abaixo: Os objetivos e especificação da segurança no projeto do sistema; As principais ameaças ao sistema; A legislação e as normas de segurança pertinentes ao sistema; Uma estratégia para atingir cada objetivo de segurança indicado; Um manual do administrador contendo informações de segurança; Descrição de quais partes do código do sistema aplicativo, caso alteradas, exigem revisão da segurança; MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 18/22
  19. 19. RELATÓRIO DE ANÁLISE TÉCNICA Um manual do administrador contendo procedimentos para o caso de incidentes ou falhas de segurança; Os requisitos de arquitetura e implementação para o atendimento de cada objetivo de segurança; Os testes mínimos necessários para garantir que os objetivos de segurança estão atendidos no sistema; Os procedimentos de instalação e configuração do sistema aplicativo ressaltando os aspectos de segurança.• Referências: Common Criteria: ADV_FSP.1, ADV_HLD.1, ADV_RCR.1, Classe ASE, CEM 1.0. Resultado da Análise Não foi apresentada documentação que possua as características descritas acima, ou parte delas.MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 19/22
  20. 20. RELATÓRIO DE ANÁLISE TÉCNICACONCLUSÃOIniciamos o trabalho colhendo as experiências vividas na operação diária do sistema ElógicaRH instaladoe operado pela SEGESP. Junto a este trabalho, buscamos informações sobre a empresa desenvolvedora,a Elógica, através do site oficial da empresa (http://www.elógica.com), com o intuito de compreender otempo existência da empresa, do software e o grau de maturidade em desenvolvimento e fornecimentode soluções para Recursos Humanos e Administração de Pessoal.Trata-se de uma empresa que relata ter mais de 30 anos de atuação em TI, possuindo uma equipecomposta por 130 colaboradores e algumas centenas de clientes. O sistema ElógicaRH está instalado emsua versão 16 na SEGESP, demonstrando que, desde 1996, o sistema passa por um processo evolutivo.Entendemos então, que as credenciais fornecidas pela empresa ao mercado associam os seus produtos aum alto nível de qualidade e garantia de segurança, dada a experiência relatada.O sistema atende a área de Recursos Humanos e Administração de Pessoal, lidando com informaçõesconfidenciais e pessoais. Por estas características, o sistema atende a áreas extremamente cautelosasquanto a divulgação das informações por elas custodiadas e que, se divulgadas, podem trazerrepercussões de diversas ordens e prejuízos às partes envolvidas, como o constrangimento porexposição de informações pessoais, e ações legais contra a empresa usuária do sistema.Ainda no que tange a área de Administração de Pessoal, toda a folha de pagamento da empresa écontrolada pelo sistema ElógicaRH, significando que a confiabilidade dos dados do sistema é umacaracterística fundamental. Os salários dos funcionários são controlados pelo sistema desde o seucadastramento até o envio dos arquivos de pagamento aos bancos.Espera-se que a empresa fornecedora de um sistema com tais atribuições exerça um controle dequalidade com forte foco em segurança das informações, garantindo que seus clientes não sejamexpostos a riscos oriundos de sua operação.Entretanto, através de análise criteriosa no sistema ElógicaRH, dentro dos limites impostos pela falta doacesso ao código-fonte, foi-nos possível identificar que: O sistema expõe credenciais de acesso do usuário administrador do banco de dados (usuário e senha) em mais de um ponto. o Seja por uma falha de arquitetura de aplicação, por uma definição para o desenvolvimento de sistemas ou por um descuido ou falta de zelo de sua equipe, estas MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 20/22
  21. 21. RELATÓRIO DE ANÁLISE TÉCNICA informações não podem ser expostas pelo sistema. Desta forma ferem-se os preceitos de confidencialidade dos dados armazenados no sistema. O sistema armazena, em texto claro, as credenciais de acesso ao banco de dados. o Desta forma, o sistema permite que usuários mal intencionados façam acessos indevidos com credenciais de acesso de administrador do sistema. O sistema não possui um registro de transações em formato de log, que permita a identificação dos passos executados pelos usuários. o Não é possível recompor as ações executadas pelos usuários nem tampouco identificar as alterações efetuadas no sistema ou nos dados pelos usuários. O sistema não oferece claramente características de alta disponibilidade. o Esta característica é fundamental quando se administra o pagamento de funcionários de uma instituição. A indisponibilidade do sistema, seja por uma falha de hardware ou software, traz prejuízos a empresa cliente e a seus funcionários.Lembramos que a Módulo Security Solutions não é especializada em Recursos Humanos ouAdministração de Pessoal mas sim especializada em Segurança da Informação, com larga experiência emContingência e Continuidade de Negócios, Gestão de Riscos, Governança de Segurança, Governança deTI, Leis e Regulamentações, entre outras. Este relatório não aborda as funcionalidades do sistema masapenas suas características de segurança observáveis ao armazenar e lidar com as informações.Ante o exposto neste relatório, somos levados a concluir que o sistema ElógicaRH não atende àscaracterísticas esperadas de um sistema que se propõe a atender as áreas de Recursos Humanos eAdministração de Pessoal. Mesmo possuindo as funcionalidades necessárias para a execução destasatividades, em diversos pontos pudemos observar que informações que deveriam ser resguardadas eacessadas apenas pelos usuários gestores e administradores do sistema eram disponibilizadas aosusuários normais enquanto operavam o sistema.É sabido que a melhor forma de se implementar segurança é durante o planejamento e concepção dasolução. Assim, todos os mecanismos agirão de forma proativa, dentro de cenários previamentevisualizados pelos arquitetos da solução. O que observamos durante a análise indica que o MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 21/22
  22. 22. RELATÓRIO DE ANÁLISE TÉCNICAdesenvolvimento do sistema não adotou esta prática e que o seu controle de qualidade não capturou esanou as falhas apresentadas, ainda existentes no sistema.As exposições de senha e falhas encontradas no sistema ElógicaRH propiciam um ambiente de granderisco para a empresa contratante. Neste cenário, pessoas mal intencionadas podem facilmente e semdeixar traços de suas atividades, alterarem dados, modificarem informações sensíveis e exporeminformações confidenciais.Todo este cenário se traduz em um alto risco operacional para a SEGESP, uma empresa pública, usuáriado sistema avaliado e a todos os funcionários suportados pelo sistema. MÓDULO GRC METAFRAMEWORK SEGESP DATA: 17/12/2008 22/22

×