Análise e Desenvolvimento de Sistemas4º semestre Aula nº 06 Prof. Paulo Rangel
[email protected] Segurança e Auditoria de Sistemas Segurança e Auditoria de Sistemas Conteúdo Previsto Modelos de especificação de Segurança Especificação da Segurança desejada Modelos de especificação de Segurança – Padrão Internacional ISO/EIC 15408 (Common Criteria) Vários países europeus e americanos (EUA, Canadá, França, Inglaterra, Alemanha, entre outros) estavam criando seus padrões para desenvolver sistemas e aplicações seguras; Os países europeus decidiram unificar seus critérios, criando o Information Technology Security Evaluation Criteria (ITSEC); Em 1990 houve a unificação dos padrões europeu e norte americano, criando-se o Common Criteria (CC); A versão 2.1 do CC se tornou o ISO/IEC 15408 (Evaluation Criteria for Information Technology on Techonology Security Evaluation) Modelos de especificação de Segurança – Padrão Internacional Histórico do IT Security Criteria http://www.cotsjournalonline.com/articles/view/100651 ISO/EIC 15408 (Common Criteria) É uma norma para definir e avaliar requisitos de segurança de sistema e aplicações; Conjunto de 3 volumes (aprox. 400 páginas): O 1º discute DEFINIÇÕES e METODOLOGIA; O 2º lista um conjunto de REQUISITOS DE SEGURANÇA; O 3º trata das metodologias de AVALIAÇÃO; ISO/EIC 15408 (Common Criteria) Conjunto de critérios para a especificação da segurança de uma aplicação, baseado nas características do ambiente de desenvolvimento. O Common Criteria, é um framework de critérios para especificação, implementação e avaliação de requisitos e propriedades de segurança em SI e produtos de TI. Objetiva: Que os usuários especifiquem suas exigências de segurança, Que os desenvolvedores especifiquem os atributos de segurança de seus produtos Dá aos avaliadores as condições de auditar se os produtos atendem tais reinvindicações. Aplicável aos riscos decorrentes de atividades humanas ou não, maliciosas ou não. ISO/EIC 15408 (Common Criteria) O Common Criteria, pode ser aplicado para desenvolver um sistema seguro ou avaliar a segurança de um pronto. Ele estabelece que para um sistema ser considerado seguro, necessita da elaboração do seu Security Target (Objetivo de Segurança), que formaliza quais aspectos de segurança foram considerados importantes para o sistema em questão. ISO/EIC 15408 (Common Criteria) http://www.ipa.go.jp/security/english/second.html ISO/EIC 15408 (Common Criteria) Sete níveis de garantia de segurança. Cada nível aumenta o rigor nos testes para aumentar a garantia que o sistema atende aos requisitos de segurança; Esses níveis são chamados de EAL (Evaluation Assurance Level ou Nível de Garantia da Avaliação), variando de EAL1 até EAL7, sendo este último o nível mais alto de garantia; http://www.eetimes.com/document.asp?doc_id=1274224 ISO/EIC 15408 (Common Criteria) EAL1 – Funcionalmente Testado É aplicável quando algum nível de confiança é necessária, mas as ameaças à segurança não são vistas como grave. Será útil quando uma garantia independente é necessária para apoiar a afirmação de que existe o cuidado em relação ao respeito à proteção de informações pessoais ou similar. Pretende-se que uma avaliação EAL1 possa ser realizada com sucesso sem a assistência do desenvolvedor, e por um custo mínimo. EAL2: Estruturalmente Testado Requer a cooperação do desenvolvedor em termos de fornecimento de informações do projeto e os resultados dos testes, mas não deve exigir mais esforço por parte do desenvolvedor do que é consistente com as boas práticas comerciais. Assim, não deve exigir um aumento significativo em custos ou tempo. É aplicável naquelas circunstâncias onde os desenvolvedores ou usuários requerem de baixo a moderado nível de segurança assegurada, mesmo na ausência da disponibilidade dos registros de desenvolvimento. Por exemplo, na avaliação de sistemas legados. ISO/EIC 15408 (Common Criteria) EAL2: Estruturalmente Testado ISO/EIC 15408 (Common Criteria) EAL3: Metodicamente Testado e verificado Permite ao desenvolvedor alcançar a maior segurança possível na fase de projeto, sem alterar as boas práticas de desenvolvimento, sendo aplicável quando requerido pelos desenvolvedores e usuários, um nível moderado de segurança assegurada, exigindo um processo completo de testes e verificação. ISO/EIC 15408 (Common Criteria) EAL4: metodicamente projetado, testado e Avaliado Permite que um desenvolvedor obtenha a certeza de segurança máxima baseado em boas práticas de desenvolvimento comercial que, embora rigorosa, não requerem conhecimento especializado substancial, habilidades e outros recursos. EAL4 é o mais alto nível em que é economicamente viável adaptar uma linha de produto existente. Sendo aplicável em circunstâncias onde os desenvolvedores ou usuários necessitam de um moderado a alto nível de segurança garantida e que estão dispostos a incorrer em custos específicos para isso. ISO/EIC 15408 (Common Criteria) EAL4: metodicamente projetado, testado e Avaliado Exemplos: AIX, HP-UX, FreeBSD, Novell NetWare, Solaris, SUSE Linux Enterprise Server 9, SUSE Linux Enterprise Server 10, Red Hat Enterprise Linux 5, O Windows 2000 Service Pack 3, Windows 2003, Windows XP, o Windows 7, Windows Server 2008 R2, e z/VM versão 5.3. ISO/EIC 15408 (Common Criteria) EAL4: metodicamente projetado, testado e Avaliado ISO/EIC 15408 (Common Criteria) EAL5: Semi-formalmente projetados e testados Permite ao desenvolvedor obter um nível máximo de segurança com base em rigorosas práticas de desenvolvimento comercial suportados pela aplicação de técnicas especializadas de engenharia de segurança. Deverá ser projetado e desenvolvido com a intenção de alcançar a garantia EAL5. Implicará em aumento de custos em segurança. Exemplos: dispositivos de smart card. ISO/EIC 15408 (Common Criteria) EAL6: Projetos Semi-formalmente verificados e testados Permite aos desenvolvedores obter alta garantia da aplicação de técnicas de engenharia de segurança em um rigoroso ambiente de desenvolvimento, buscando proteção contra riscos significativos. Aplicável ao desenvolvimento de aplicação em situações de alto risco, em que o valor do ativo protegido justifica os custos adicionais. ISO/EIC 15408 (Common Criteria) EAL7: Projetos Formalmente verificados e testados Aplicável ao desenvolvimento de segurança para aplicação em situações de risco extremamente elevado e/ou onde o alto valor dos bens justificam os custos. Aplicação prática da EAL7 está atualmente limitada em funcionalidades de segurança bem focadas onde é possível analise formal extensa. ISO/EIC 15408 (Common Criteria) Acredita-se que um maior EAL significa nada mais do que uma avaliação completa de um conjunto mais rigoroso dos requisitos de garantia de qualidade. Assumindo desta forma que um sistema que atingir um maior EAL terá seus aspectos de segurança mais confiáveis, considerando que exigirá a análise de terceiros e testes realizados por peritos de segurança e assim teríamos uma evidência importante nesta direção, porém há pouca ou nenhuma evidência publicada para confirmar essa suposição. ISO/EIC 15408 (Common Criteria) Em 2006, os EUA Government Accountability Office publicou relatório que resume uma série de custos e prazos para avaliações realizadas em níveis EAL2 até EAL4. Uma proposta de modelo simplificado Segundo Lyra, não é necessário a aplicação completa da ISO/IEC 15408 para obter-se uma aplicação segura e garantir sua segurança. Afirma que “É possível vislumbrar que atingir o nível 7 de maturidade em segurança leva tempo e dinheiro. O nível 3 traz uma segurança bastante significativa para a maioria dos sistemas comerciais”. Propõe um processo simplificado a partir da proposta de Ricardo Albuquerque e Bruno Ribeiro, por considera-la completa e aplicável à maioria dos sistemas comerciais. Uma proposta de modelo simplificado Para uma aplicação a ser desenvolvida: 1. Especifique a segurança da aplicação na fase de analise, gerando um documento de especificação de segurança do sistema usando a ISO/IEC 15408 como roteiro, adotando os mesmos requisitos descritos na norma, a mesma estrutura de análise de ambiente, mas não necessariamente seguir o padrão do Security Target; 2. Mantenha um ambiente de desenvolvimento e testes suficientemente seguros e capazes de atender ao EAL3 da norma. Considerado bastante seguro para a maioria das aplicações comerciais; 3. Desenvolva utilizando boas práticas de programação e seguindo os requisitos de segurança, ou seja, crie um processo de desenvolvimento bem definido e planeje apropriadamente a implantação dos requisitos especificados; 4. Teste seu sistema internamente, gerando as evidências para verificação da aderência às especificações do EAL3. Uma proposta de modelo simplificado Para uma aplicação já desenvolvida: 1. Levante a especificação de segurança para a aplicação usando a ISO/IEC 15408 como base; 2. Levante quais requisitos de segurança a aplicação possui e quais estão presentes em seu ambiente de desenvolvimento; 3. Verifique se os requisitos implementados atendem à necessidade de segurança verificada na especificação inicial; 4. Escolha um nível de garantia de segurança (após o EAL3, não é possível fazer verificações mais detalhadas em aplicações prontas, pois os níveis 4 a 7 exigem testes e procedimentos durante a implementação) e faça os testes para garantir a segurança da aplicação. Especificação da Segurança desejada Segurança não é um parâmetro único; Necessário conhecer necessidades do cliente e do usuário da aplicação quanto aos aspectos de segurança; Motivadores: Legislações, normas e politicas de segurança que devem ser observadas; Ameaças ao negócio ou ao objetivo da aplicação que devem ser eliminadas ou mitigadas Especificação da Segurança desejada http://eciti.wordpress.com/2012/07/02/iso-15-408-e-ciencia-da-informacao/ Especificação da Segurança desejada Estabelecendo os objetivos de Segurança: Levantar as necessidades legais e as politicas de segurança; Verificar e levantar os tipos de ameaças que o sistema está sujeito; Consolidar as informações levantadas estabelecendo os Objetivos de Segurança de forma que cada objetivo esteja ligado a pelo menos uma ameaça ou legislação. Os objetivos de segurança serão os requisitos básicos da segurança que precisam ser atendidos pelo sistema para que as legislações e ameaças sejam tratadas corretamente. Objetivos de Segurança Levantar Necessidades Legais e Politicas Levantar Ameaças Consolidar as informações Especificação da Segurança da Aplicação 1º passo é o levantamento e avaliação do ambiente na qual será implantada: Ameaças, pontos críticos, legislação aplicável e medidas de contingências que já existem; Necessidades de segurança do usuário. A ISO/IEC 15408 recomenda levantamento minucioso para cobrir os seguintes aspectos: Política de segurança: diretrizes, normas, regulamentos, padrões e legislações; Ameaças: mecanismos de ataque e agentes e ativos a serem controlados; Objetivos de segurança: formalização das necessidades de segurança do usuário; Premissas: fatos sobre o uso do sistema e sobre seu ambiente, que são considerados verdadeiros para o levantamento. Especificação da Segurança da Aplicação Legislações e normas referentes à privacidade, confidencialidade, disponibilidades e outros aspectos da segurança devem ser estritamente observados. Demais requisitos de segurança bem como necessidades de segurança dos usuários podem e devem ser negociados e/ou flexibilizados para melhor uso dos recursos disponíveis. Segundo a ISO/IEC 15408, teremos ao final deste trabalho a lista de requisitos de segurança e os motivos destes requisitos existirem. Especificação da Segurança da Aplicação Levantamento das ameaças: Focar nas significativas ou com maior probabilidade e impacto; Criar dificuldades para desestimular atacantes menos decididos. Objetivos da segurança: Deve ser explicita. É a segurança que será implementada. Log de transações (Ligar a ação ao executor); Mesmo o administrador deve ter seu log de transações registrado; Capacidade de resiliência; Auditabilidade conforme exigências legais Premissas de Segurança: Devem tratar do ambiente esperado para a construção e produção do sistema. Devem ser claras, explicitas, consideradas e aprovadas já que afetarão diretamente sua construção e operação. Especificação da Segurança da Aplicação Estratégia de segurança: Escolher para cada objetivo de segurança, uma forma de atendê- lo, levando em conta sua ameaça ou legislação de origem, premissas associadas e ferramentas disponíveis. Segurança do Ambiente de Desenvolvimento Desenvolver aplicação segura implica em um ambiente seguro; Ambientes de desenvolvimento críticos, requerem controles mais rigorosos; Controles em uma fábrica de software são maiores do que em uma empresa de manufatura; Devemos levar em consideração, não apenas a ISO/IEC 15408, mas também as normas ISO 27001 e 27002 para servir como guia na elaboração e gerência de uma politica de segurança conforme passos seguintes: Segurança do Ambiente de Desenvolvimento Gerência de Configuração: Deve garantir que a integridade do sistema esta preservada; Previne mudanças. Acréscimos e exclusões não autorizadas na documentação do sistema; Ajuda a o processo de desenvolvimento a ser menos suscetível a erros ou negligência humana; Distribuição: Garantir que a versão distribuída tem os atributos de segurança especificados; As medidas, procedimentos e padrões relacionados à distribuição, instalação e operação segura devem estar de acordo com as especificações. Segurança do Ambiente de Desenvolvimento Desenvolvimento: Devem ser representadas desde o projeto lógico até a implementação do produto final, todas as funcionalidades de segurança. Foco na decomposição das funcionalidades de segurança em subsistemas, da decomposição desses em módulos, do projeto de implementação desses módulos e da demonstração de evidências da correspondência entre todas as camadas de decomposição. Documentação: Documentação de ajuda: Administrador: Configuração, manutenção e administração; Usuários: Funcionalidades de segurança, instruções e guias para uso seguro do sistema. Segurança do Ambiente de Desenvolvimento Suporte ao Ciclo de Vida: Adotar um modelo, ajuda a garantir que os aspectos relacionados à segurança sejam tratados corretamente durante o ciclo de desenvolvimento e manutenção. As normas ISO recomendam modelos aprovados por grupos de especialistas reconhecidos, tais como CMMI, RUP, etc. Testes de Segurança: Visam garantir o atendimento dos requisitos funcionais de segurança; Técnicas que podem ser utilizadas: Teste de Unidade, Teste de Integração, Teste de Sistema, Teste de Instalação e testes de aceitação. Segurança do Ambiente de Desenvolvimento Avaliação de Vulnerabilidades: Envolve analisar: Possibilidade de um mau uso ou de configuração incorreta; Possibilidade de falha dos mecanismos de segurança se expostos à força e a exploração de vulnerabilidades eventualmente introduzidas durante o desenvolvimento ou operação do sistema. Uso inapropriado do sistema também é um aspecto que a avaliação de vulnerabilidades deve identificar; Orientações erradas ou falhas na documentação de ajuda devem ser identificadas Referencias Bibliográficas LYRA, M. R. Segurança e auditoria em sistema de informação. 1ª Edição. Rio de Janeiro: Ciência Moderna, 2008 KROLL, Josiane. Um modelo conceitual para especificação da gestão de riscos de segurança em sistemas de informação. Santa Maria – RS, UFSM: 2010. Dissertação de mestrado em engenharia de produção. Disponível em < http://cascavel.cpd.ufsm.br/tede/tde_arquivos/12/TDE-2010-06-08T143755Z- 2677/Publico/KROLL,%20JOSIANE.pdf >. Acesso em 14 set 2012. MANADHATA, P.K. KAYNAR, D.K., WING, J.M. A Formal Model for A System´s Attack Surface. Pittsburgh, PA: Carnegie Mellon University, 2007 http://www.dtic.mil/dtic/tr/fulltext/u2/a476799.pdf acesso em 16/09/2012. WOODY, Carol, Strengthening ties between process and security, Carnegie Mellon University 2005-2012 https://buildsecurityin.us-cert.gov/articles/knowledge/sdlc-process/strengthening-ties-between- process-and-security SANTOS, Marcelo Alves, ISO 15.408 e Ciência da Informação, 2012 http://eciti.wordpress.com/2012/07/02/iso-15-408-e-ciencia-da-informacao/ Glossário CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.Foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. Glossário RUP (Rational Unified Process ou Processo Unificado Racional), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente. É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos. Segurança e Auditoria de Sistemas DÚVIDAS ?