Arquivos
Diretrizes Para Um Projeto Seguro
Existem diretrizes gerais que têm aplicabilidade ampla quando se projetam soluções de proteção de sistema que encapsulam boas práticas de projeto para sistemas seguros. As dez diretrizes de projeto que Sommerville (2007) orienta, tem como objetivo tanto de conscientizar os pontos críticos de segurança, como também ser um checklist de revisão que pode ser usada no processo de validação de sistema. Vamos a elas:
Diretriz 1: Basear as decisões de proteção em uma política de proteção explícita
Uma política de proteção deve definir o “que” da proteção, no lugar de “como”. A política não deve definir mecanismos usados para prover e fazer cumprir a proteção. Os projetistas devem, portanto, consultar a política de proteção quando ela provê um framework para tomar e avaliar decisões de projeto.
Diretriz 2: Evitar um ponto único de falha
Num sistema crítico é uma boa prática evitar um ponto único de falha. Pois uma falha única, numa parte do sistema, pode resultar na falha geral de sistemas. Em termos de proteção, isso significa que você não deve contar com um único mecanismo para assegurar a proteção, mas deve empregar várias técnicas distintas. Pode-se chamar isso de “defesa em profundidade”.
Para proteger a integridade de dados o sistema, você poderia manter um log de todas as mudanças feitas nos dados, de modo que, se ocorrer uma falha, você poderá examinar o log para recriar o conjunto de dados.
Diretriz 3: Falhar de maneira protegida
Nenhuma falha de sistema deve possibilitar a um agressor acesso aos dados que não seria normalmente permitido. Portanto, embora as falhas de sistema sejam inevitáveis, os sistemas críticos de segurança devem sempre falhar de maneira segura (fail-safe) e sistemas críticos de proteção devem sempre falhar de maneira protegida (fail-secure).
Um uso dessa filosofia seria, por exemplo, a técnica de numa aplicação cliente/servidor deixar um pequeno arquivo no computador cliente para facilitar o acesso aos dados. Uma vez utilizado do serviço, esse arquivo é eliminado. No entanto, em caso de falha esse arquivo poderá ficar inseguro. Uma estratégia seria de manter essa mesma técnica, mas com o arquivo criptografado, impossibilitando a leitura desses dados por pessoas não autorizadas.
Diretriz 4: Equilibrar proteção e facilidade de uso
À medida que um sistema aumenta suas características de proteção, é inevitável que ele se torne menos fácil de usar. Um bom exemplo seria os atuais sistemas bancários na Internet. Exigem tantas chaves para acessarmos os dados, que muitas vezes provocam irritação, e perda de tempo.
Portanto, chega-se a um ponto em que é contraproducente manter a adição de novas características de proteção à custa da facilidade de uso. Por exemplo, se você exigir que os usuários insiram várias senhas ou alterem suas senhas com uma constância muito pequena, eles simplesmente escreverão suas senhas em algum lugar. Um agressor poderá, então, encontrar as senhas e obter acesso ao sistema.
Diretriz 5: Estar ciente da possibilidade de Engenharia Social
Em Segurança da informação, chama-se Engenharia Social as práticas utilizadas para obter acesso à informações importantes ou sigilosas em organizações ou sistemas por meio da enganação ou exploração da confiança das pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra personalidade, fingir que é um profissional de determinada área, etc. É uma forma de entrar em organizações que não necessita da força bruta ou de erros em máquinas. Explora as falhas de segurança das próprias pessoas que, quando não forem devidamente treinadas para esses ataques, podem ser facilmente manipuladas.
Do ponto de vista de projeto, enfrentar a Engenharia Social é muito difícil. Mecanismos de registro que acompanham a localização e a identificação dos usuários e os programas de análise de registros podem também ser úteis, na medida em que permitem detectar brechas de proteção.
Diretriz 6: Usar redundância e diversidade para reduzir riscos
Redundância significa que você mantém mais de uma versão de software ou de dados no sistema. Diversidade, quando aplicada ao software, significa que versões diferentes não devem ser baseadas na mesma plataforma ou usar as mesmas tecnologias. Portanto, uma vulnerabilidade de plataforma ou de tecnologia não afetará todas versões e, dessa maneira, conduzirá a falhas de modo comum.
Um aplicação dessa diretriz seria utilizar sistemas operacionais diferentes no cliente e no servidor (por exemplo Linux no servidor e Windows no cliente). De modo a assegurar que um ataque baseado na vulnerabilidade de algum desses sistemas operacionais não afete o servidor e o cliente simultaneamente.
Diretriz 7: Validar todas as entradas
Um ataque comum ao sistema envolve o fornecimento de entradas inesperadas ao sistema que causam um comportamento imprevisto. Pode-se evitar muito desses problemas ao se projetar uma validação de entradas no sistema. Essencialmente, nunca deve-se aceitar nenhuma entrada sem aplicar alguma verificação sobre ela.
Por exemplo, ninguém possui um sobrenome com mais de 70 caracteres e nenhum endereço é maior do que 100 caracteres. Se usar menus para apresentar as entradas permitidas, pode-se evitar alguns dos problemas de validação de entradas.
Diretriz 8: Compartilhar seus ativos
Deve-se organizar a informação no sistema de modo que os usuários somente tenham acesso à informação de que necessitam, no lugar de toda a informação do sistema. Pode-se também precisar de mecanismos no sistema para conceder acessos inesperados. Nessas circunstâncias, pode-se usar um mecanismo de proteção alternativo para ignorar a compartimentalização do sistema.
Diretriz 9: Projetar para implantação
Muitos dos problemas de proteção surgem porque o sistema não está configurado corretamente quando é implantado no seu ambiente operacional. Deve-se, portanto, projetar sempre os sistemas de modo que os recursos sejam incluídos para simplificar a implantação e para verificar erros potenciais de configuração e omissões do sistema implantado.
Diretriz 10: Projetar para capacidade de recuperação
Independentemente de quanto esforço você dispense na manutenção de proteção do sistema, você deve sempre projetar o seu sistema com a hipótese de que uma falha de proteção possa ocorrer. Portanto, você deve pensar em como se recuperar de possíveis falhas e restaurar o sistema para um estado operacional seguro.
Por exemplo, suponhamos um ataque externo aonde uma pessoa não autorizada tenha obtido uma combinação válida de login e senha. Você precisa, portanto, projetar seu sistema para negar acesso a qualquer pessoa até que todos usuários tenham alterado suas senhas e autenticar usuários reais. Uma maneira de fazer isso seria usar um mecanismo do tipo desafio/resposta, no qual os usuários precisam responder a questões para as quais possuam respostas pré-registradas. Isso seria invocado somente quando as senhas fossem alteradas.
Material Engenharia de Software no MBA – Esab
leia também Protegendo seu Servidor de Banco de Dados
Política de Segurança da Informação – Parte 3
3) Elaboração e Implementação
Determinado os requisitos
Uma política deve endereçar o que se chama em inglês 5W1H (Who, What, When, Where, Why e How). As políticas são compostas de uma série de documentos, sendo que cada um deles tem características particulares que variam de acordo com o nível de detalhes e a audiência para qual foi criado. A variação desses fatores faz também com que a importância desses seis requisitos básicos varie de um documento para o outro.
À medida que as políticas são desenvolvidas, a recomendação de controles desponta como um dos seus principais propósitos. Muitos controles têm um ganho inquestionável em relação ao seu custo de adoção. Por conta disso, normalmente são recomendados nas políticas para que a adoção em toda a organização, isto é torna-se padrão para toda a organização
Haverá situações particulares onde o AAR vai mostrar que o contexto é especial , fazendo com que o risco seja agravado, seja por maior numero de Ameaças /Vulnabilidades , seja por um impacto maior que pode ser trazido por conta do calor do ativo em questão. AAR pode recomendar a adoção de controles específicos para está situação, sem que os mesmos necessariamente sejam padronizados para adoção em toda a organização.
Diversificando as Audiências
A política é dividida em vários documentos, que são agrupados e estruturados em virtude do nível de detalhes requerido. Isso facilita o desenvolvimento e posteriormente a manutenção. Os documentos são desenvolvidos levando em consideração nível de detalhes, uma prática recomendada é adaptar os documentos de acordo com a audiência. Basicamente existe duas grandes audiências:
* Técnicos – Serão responsáveis pela implementação e manutenção dos controles detalhados nas políticas
* Usuários – Farão uso dos sistemas, sujeitando-se aos controles implementados.
Equipe de Desenvolvimento
Normalmente, a responsabilidade principal pelo desenvolvimento das políticas é do Security Officer ou Gestor de Segurança e seu departamento. Caso a organização não possua esse profissional a responsabilidade fica a cargo de quem tiver suas atribuições.
O Comitê Executivo de Segurança da Informação é responsável por condensar os princípios de segurança que a alta direção da empresa considera importantes e fundamentais para o negócio da empresa. Em locais em que não existe comitê o papel deve ser feito pelos principais gestores responsáveis pelo negócio da organização lógico envolvendo de profissionais técnicos.
Estruturação
Os documentos da política são divididos em três categorias:
- Diretrizes – São as regras de alto nível, visão estratégica da alta direção. Servem como base para que as normas e os procedimentos sejam criados e detalhados da maneira como as ares responsáveis (Segurança e Tecnologia ) acharem mais adequadas e eficaz.
- Normas – Plano Tático, as escolhas tecnológicas e os controles que deverão ser implementado para alcançar a estratégica definida nas diretrizes
- Instruções e Procedimentos – As instruções detalham, no plano operacional, as configurações de um determinado produto ou funcionalidade que devem ser feitas para implantar os controles e tecnologias estabelecidas nas normas. Já os procedimentos detalham atividades passo a passo, que normalmente envolvem a interação entre áreas e/ou pessoas. .
Recomendações e Cuidados
- Estilo - Faça as escolhas cabíveis em relação ao estilo que será para a reação das políticas e mantenha-se fiel do começo aso final do documento. A falta de estilo pode dar a impressão de que o documento é um misto de informações elboradas de forma desconexa por diversas pessoas e transmite a impressão de falta de propósito.
- Formal X Informal – O excesso de formalidade na escrita da política faz com que ela pareça estar em uma esfera diferente das colaboradores de uma organização. O excesso de informalidade , faz com que o documento perca credibilidade .
- Clareza e simplicidade – Use uma linguagem clara e concreta, evitando o uso de abstrações. Advérbios como freqüentemente, periodicamente, regulamente etc , Utilize linguagem simples, que facilite o entendimento e ajude na fluidez da leitura
- Sentenças negativas – Palavras muitos fortes devem ser evitadas. O propósito da política é estabelecer aquilo que é ou não permitido, de forma clara , suave e indolor. O uso de sentença negativa muito forte pode parecer que a política pareça com uma monarquia.
- Inserir apenas o necessário - Evite colocar nos documentos dados, embasamentos, opiniões ou coisas do tipo.
