Desenvolvimento de software seguro
Por: velkin_dansro • 5/10/2015 • Trabalho acadêmico • 1.334 Palavras (6 Páginas) • 228 Visualizações
Kelvin Sandro RA: 6059018200
Bruno Umberlino RA:?
ETAPA 1
2.1 RELATÓRIO 1: DESENVOLVENDO SOFTWARES SEGUROS
O fato de que dados/informações representam algo invisível, abstrato, colabora para que a maioria das empresas não os considere algo a ser protegido embora, dependam deles para sobreviver. Outro argumento é de que segurança da informação não gera receita direta. Contudo, investir em segurança da informação é importante. São custos justificados quando levados em conta os benefícios agregados. É necessário cuidar das informações de uma empresa porque o conjunto desta forma um bem de grande valor. Como em um seguro de veículos, onde a relação entre o custo da apólice e o prejuízo evitado no caso de ocorrer um sinistro, segurança da informação também vale o quanto pesa.
O sucesso de um programa de segurança da informação reside em se tomar uma posição preventiva contra as ameaças e riscos de segurança, reduzindo os pontos vulneráveis para evitar que estas fraquezas sejam utilizadas contra a organização. Profissionais da área de segurança da informação estão sempre sob a constante pressão de ter que demonstrar que projetos de segurança produzem retorno sobre investimento, ou seja, que a execução de projetos de segurança da informação trará algum benefício financeiro para a empresa. Entretanto, a natureza das atividades relacionadas à segurança da informação faz com que projeções financeiras desse tipo tornem-se, no mínimo, difíceis de serem realizadas. A atual moda entre fornecedores de equipamentos e prestadores de serviço relacionados à segurança da informação é de que projetos nessa área geram retorno claro sobre seu investimento. Adicionalmente, a lógica imediatista sugere que agora que a segurança da informação está ganhando ampla aceitação como um importante aspecto do negócio, o próximo passo seria haver algum tipo de cálculo ou projeção de retorno que justifique seu investimento em termos negociais. Se os empresários (ou patrocinadores de um projeto de segurança da informação) passarem a adotar esse conceito, eles contarão com algo que simplesmente não existe em sua essência. Os resultados esperados são geralmente calculados com base na prevenção de alguns futuros eventos hipotéticos que, se viessem a ocorrer, teriam alguma implicação financeira igualmente hipotética. Os benefícios são muito teóricos e incertos para que as empresas possam levá-los a sério como justificativa de investimento por si só. Portanto, não se deve investir em segurança da informação tendo como objetivo ganho financeiro, mas para se impedir que o ganho financeiro que a empresa obtém a partir de sua atividade fim não fique comprometido devido à ocorrência de um incidente de segurança que tenha comprometido as informações de que necessita para conduzir seus processos de negócio.
A segurança, assim como todas as outras áreas de TI, deve ser ampla e holística. Para alcançar este objetivo, as organizações devem iniciar com uma estrutura de políticas básicas sobre a qual todas as outras áreas se apoiarão. Todos os componentes de um programa de segurança devem aderir a essa estrutura.·.
Princípios de Segurança da Informação:
- Confiabilidade: Proteger uma informação para evitar que seja divulgada sem autorização de uma pessoa responsável pela mesma. Na fase de documentação de requisitos que contem informações de todos os processos de negócios envolvidos é importante que as informações sejam protegidas para a utilização somente pela equipe do projeto. Na fase de desenvolvimento é importante que o código-fonte fique restrita a empresa responsável pelo desenvolvimento do código. As aplicações que serão acessadas externamente não devem expor informações confidencias da empresa.
- Disponibilidade: garantir os serviços prestados pelo sistema sempre que solicitados. Na fase de projeto, analisar pontos de fragilidade das aplicações. No desenvolvimento, tratar exceções para evitar possíveis problemas. Fazer teste de stress na aplicação. Na implementação Viabilizar soluções para possíveis problemas que venha acontecer e recuperações de dados.
- Integridade: Controlar modificações em informações proprietárias. No desenvolvimento, manter atenção no acesso aos bancos de dados, que deve ser efetuado de maneira que não comprometa qualquer elemento do mesmo. A utilização de um SGBD bem configurado é imprescindível. Quando o sistema estiver em funcionamento, verificar sempre de maneira periódica o log de alterações de objetos críticos.
- Autenticidade: identificar de maneira correta todo e qualquer elemento em um sistema de informação. No projeto, definir o papel de cada ator e em cada processo para estruturar os perfis de acesso ao sistema. Na fase de implementação, envolver a equipe de comunicação da empresa na conscientização dos usuários para a segurança da informação.
- Conformidade: Evitar que recursos tecnológicos estejam em desacordo com as legislações vigentes. No projeto , junto aos gestores de direito, tributos e auditoria ver quais requisitos deem ser respeitados no desenho do software.
2.2 RELATÓRIO 2: EVITANDO ESTOURO DE BUFFER
Estouros de buffer ocorrem quando um processo tenta armazenar dados fora dos limites de um buffer de comprimento fixo. Quando isso acontece, todos os tipos de comportamento erráticos do sistema podem ocorrer e alguns podem ser prejudiciais para a segurança do sistema. O resultado é que os dados extras sobrescrevem os locais da memória adjacente. Os dados sobrescritos podem incluir outros buffers, variáveis, dados de fluxo do programa, etc. Sobrescrever esses dados pode causar problemas como comportamento errático de programas, exceções de acesso de memória, finalização/travamento de programas, resultados retornados incorretamente ou uma quebra de segurança.
Estouros de buffer causam muitos defeitos de software e, portanto, são a base de explorações dolosas. Sistemas C/C++ são especialmente propensos a estouros. Eles não fornecem nenhuma proteção para parar o acesso aos dados em qualquer parte da memória e não verificam automaticamente se os dados gravados em uma matriz de buffer interna estão dentro dos limites dessa matriz. Por isso você deve sempre suportar um sistema que execute verificação de limites por você ou pelo compilador e o tempo de execução.
A causa dos estouros é a manipulação incorreta de memória de dados/instruções em um código-fonte, principalmente em strings e estruturas de dados dinâmicas. Shellcode (instruções que podem ser executadas enquanto outro programa está rodando) é uma porta para o controle de aplicações vulneráveis.
Solucionar problemas causados por estouros de buffer é uma tarefa árdua. Alterar trechos de código perigosos, utilizando bibliotecas seguras, ou optar por linguagens de programação com autoproteção contra acessos indevidos. Também é possível efetuar configurações no kernel do sistema operacional para que o buffer seja parcialmente inutilizado. Outra ação é instalar patches de proteção de memória (OpenWall, Pax, etc.).
Formas de prevenir estouro de buffer
...