Rhand Leal Segurança é algo que todos querem ter, mas ninguém quer usar. E este pensamento pode trazer muitos problemas.
A menos que o propósito de um Sistema seja relacionado a segurança (ex.: firewall, sistema de controle de acesso, etc.), os usuários dão pouca atenção a como a segurança é embutida no produto, e como ela é testada para assegurar que ela funcionará adequadamente quando necessário. Sistemas críticos de um avião e um carro acessadosatravés de sistemas de entretenimento, devido a implementação e verificação inadequada da segurança, são dois exemplos divulgados pela mídia ano passado.
Hoje eu apresentarei a você como a ISO 27001 e ISO 27002 podem ajudar a esclarecer que a segurança de um sistema, usado pela própria organização ou fornecido a clientes como serviço, deveria ser levada em conta durante a especificação de requisitos e preparação de procedimentos de teste.
O que é um requisito? E por que eu deveria me importar?
Um requisito é qualquer declaração elaborada de uma forma que torna possível usá-lo para avaliar um resultado. Por exemplo, quando você pede por “água gelada”,você declara a substância (água) e a temperaturaque você quer (gelada). Quanto mais detalhado o requisito, mais fácil é verificar os resultados.
Contudo, quanto mais detalhado o requisito, maior o esforço necessário para define-lo e testá-lo, e algumas vezes este esforço é negligenciado para evitar aumentar os custos – resultando em falta de informações necessárias para atender ou verificar a solicitação. No exemplo anterior, qual é a quantidade necessária? Como o pagamento será feito? Como será demonstrado que a “água gelada” é aceitável?
E, se este exemplo simples pode se tornar tão complexo, o que falar sobre requisitos de sistemas? A falta de declarações claras é o que leva um produto com desempenho ou segurança deficiente.
Como especificar requisitos de segurança
O controle A.14.1.1 (Análise e especificação de requisitos de segurança) da ISO 27001 declara que requisitos para proteger informações deveriam ser incluídos nos requisitos para sistemas de informação. Um exemplo de um requisito de proteção é o acesso controlado a informação, de acordo com o nível de liberação.
Para se obter boas declarações de requisito a ISO 27002 recomenda:
Adoção de métodos para identificar requisitos: formas sistemáticas de identificação podem prevenir alguns aspectos de serem esquecidos ou ignorados. Exemplos de métodos são avaliações de políticas e regulamentações, modelagem e ameaças ou revisão de incidentes.
Revisão dos resultados por partes interessadas: quem melhor para avaliar requisitos documentados do que as pessoas que usarão o produto? Escolha pessoas em vários papéis envolvidos (ex.: usuários finais, clientes, administradores de sistema, etc.).
Avaliação de requisitos de acordo com o valor da informação para o negócio: segurança adequada reflete o valor que a informação / sistematem para o negócio. Assim, requisitos deveriam ser priorizados de acordo com os propósitos de negócio que eles estão destinados a proteger.
Integração da gestão de requisitos nos estágios iniciais de um projeto: quanto mais cedo a segurança é considerada, mais opções estarão disponíveis para tratar situações de riscos. Pense sobre políticas e o próprio processo de desenvolvimento de projetos.
Definição de critérios para aceitação de produto: em algum momento você deve mostrar que o que foi proposto para o Sistema pode ser realmente feito, e que os procedimentos estabelecidos foram corretamente seguidos. E como você pode fazer isso? A principal recomendação do controle 14.2.9 – Teste de aceitação de sistemas da ISO 27002,é definir parâmetros e resultados claros a serem atingidos. Estas são as bases para o desenvolvimento de procedimentos e rotinas de teste, detalhados na próxima seção.
Teste de requisitos
Uma definição clara sobre o quevocê deveria esperar como resultado, você deveria considerar comoassegurar que seu sistema está em conformidade com os requisitos. De acordo com a ISO 27001, você pode usar o controle A.14.2.8 (Teste de segurança de sistemas) para elaborar atividades sistemáticas para assegurar o atingimento de critérios de aceitação previamente definidos. Mais detalhes podem ser encontrados na ISO 27002, que recomenda:
Estabelecimento de condições que requerem um teste: novos sistemas são uma condição óbvia, mas você deveria considerar também sistemas atualizados, novas versões e componentes, uma vez que funcionalidades novas ou alteradas podem trazer riscos ao Sistema e ao ambiente.
Estabelecimento de rotinas sistemáticas de teste: considereuma rotina de atividades a serem realizadas, com suas respectivas entradas e saídas. Desta forma você pode assegurar que um teste pode ser repetido e erros facilmente encontrados.
Use múltiplos níveis de teste: os primeiros testes deveriam ser realizados pela equipe de desenvolvimento, para verificar os requisitos mais básicos de operação, e rapidamente corrigir erros de código simples. Para definir a garantia da segurança (que o sistema trabalha como esperado e apenas como esperado), testes independentes deveriam ser realizados.
Testes em ambiente realístico: quanto mais similar ao ambiente de produção, melhor para a identificação de vulnerabilidades e confiabilidade do teste. Este item pode ser crítico quando os testes envolvem o uso de bases de dados, uma vez que dados reais em teste podem adicionar riscos por si só não relacionados ao produto. Para minimizar isso, considereas recomendações do controle 14.3.1 (Proteção de dados de teste), evitando o uso de Informações de Identificação Pessoal (Personally Identifiable Information – PII), ou usando controles específicos no processo de desenvolvimento para controlar de forma rígida o acesso a tais bases de dados.
Note que os controles A.14.2.8 e A.14.2.9 diferem entre si pelo fato de que o controle A.14.2.8 cobre a necessidade de testes de segurança, enquanto que o controle A.14.2.9 cobre quais resultados os testes deveriam atingir para um sistema ser aceito.
Boa segurança = requisitos claros + testes apropriados
Riscos vêm de incertezas. Todas as vezes que você elabora um requisito sem considerar todos os elementos relevantes e partes interessadas, você adiciona, até de forma desnecessária, mais incertezas e riscos ao seu negócio. Evite isso pelo uso de práticas sistemáticas e realização de testes para assegurar que os resultados são o que você planejou. Os benefícios virão na forma de menos incidentes e melhor desempenho.
Para saber mais sobre a ISO 27001, incluindo todos os requisiots e melhores práticas para conformidade, assista gratuitamente o ISO 27001 Foundations Online Course.
Nós agradecemos a Rhand Leal pela tradução para o português.
