aula 7 - segurança e auditoria de sistemas - seg no ciclo de vida desenv aplic - turma b

Análise e Desenvolvimento de Sistemas

4º semestre – Turma B

Aula nº 7

Prof. Paulo Rangel

[email protected]

Segurança e Auditoria de Sistemas


Alerta sobre o cronograma de aulas

16/04/2014 – Prova de Avaliação Continuada

30/04/2014 – Apresentação de Seminário

30/04/2014 – Entrega da Resenha do Livro

Lembrar que o cronograma de aulas pode ser alterado pela FMU ou pelo

Professor.


Conteúdo Previsto

Segurança no Ciclo de Vida de Desenvolvimento da Aplicação.

Acompanhamento das tarefas básicas do projeto. Boas

práticas.

Segurança da Aplicação – Garantia

Métricas de Segurança. Monitoração das vulnerabilidades.

Segurança no Ciclo de Vida de

Desenvolvimento da Aplicação

Recomenda-se a adoção de um método de desenvolvimento bem

definido, que no mínimo, possua as atividades de Planejar,

acompanhar as tarefas básicas do projeto e definir milestones para

checagem. O CMMI, o RUP ou o PMBOK, entre outros, podem

ser adotados.



Padrões de Desenvolvimento:

Visam melhorar a estrutura interna de um programa dando: Melhor legibilidade do código,

Padronização da codificação,

Documentação interna organizada,

Codificação flexível e reutilizável,

Facilidades na manutenção,

Maior produtividade,

Rapidez no desenvolvimento,

Aumento da qualidade de códigos e

Facilidades na identificação de erros.

Tais padrões devem ser aplicados também nas etapas de

manutenção e testes.



Boas Práticas de Programação: Mesmo sem se considerar a segurança

em si, garantem um código mais robusto, confiável e, desta forma mais seguro;

Código seguro é escrito para enfrentar atacantes maliciosos;

Por vezes, código seguro implica em queda de desempenho na aplicação, o que deve ser compensado por equipamentos mais poderosos;

Segue nos próximos slides algumas recomendações que são consenso entre diversos autores:



Criar funções intrinsicamente seguras:

Segundo Lyra, devem checar os dados de entrada

para impedir perda de controle do sistema, falhas

gerais de proteção ou outros tipos de falhas. Foco o

estouro de buffer (buffer overflow)

Usar funções intrinsicamente seguras:

Como exemplificado por Lyra, uma função

intrinsicamente insegura é a strcpy (em C e

C++) que faz a cópia de uma string recebendo

como parâmetros os dois ponteiros e copia todo o

conteúdo, de um para o outro, até encontrar 0

(zero), caso isso não ocorra, podemos rejeitar o

comando ou o conteúdo.


Desenvolvimento da Aplicação Testar o retorno de funções:

O retorno de funções precisam ser verificados e for possivelmente suspeito, deve-se dar um tratamento dentro da perspectiva de segurança.

Documentar funções corretamente: Evitam-se mal-entendidos a respeito

da interpretação do seu uso.

Tratar as entradas de dados: Feitas pelos usuários ou por outro

sistema devem ser validadas, mesmo que todas as funções sejam intrinsecamente seguras. Identificar caracteres especiais evitam ataques como SQL Injection.



Ter uma política de versão consistente:

Seja por Gerenciamento de Configuração ou por backup,

facilita a identificação de problemas e melhora o resultado final.

Podem ser adotadas soluções de software tipo VCS (version

control system) ou SCM (source code management), p.e.: Entre os

mais comuns encontram-se as soluções livres: CVS, Mercurial, Git

e SVN; e as comerciais: SourceSafe, PVCS (Serena) e ClearCase.



VCS (version control system) ou SCM (source code management),



Usar componentes e bibliotecas

confiáveis:

Deve-se assegurar, por meio de testes

de segurança, que as bibliotecas

utilizadas não comprometem a

segurança do sistema.

Evitar informações sensíveis em

arquivos temporários:

Em geral, os arquivos temporários não

recebem cuidados rigorosos quanto a

segurança. Usa-lo com dados sensíveis,

fragiliza a segurança da aplicação.


Desenvolvimento da Aplicação Não armazenar Senhas e Chaves criptográficas

no código: Se armazenadas em código, podem ser reveladas

por engenharia reversa. O seu armazenamento, bem como os algoritmos utilizados devem ser objetos de analise criteriosa.

Operar com o Privilégio Necessário: Operar com privilégios limitados ao estritamente

necessário, reduz o impacto em caso de falhas sérias, como p.e., estouro de buffer.

Tratar todas as entradas do sistema como não segura: Todos os dados de entrada, independente de sua

origem, devem ser verificados quanto a sua integridade e consistência.

Garantia da Segurança da Aplicação

Kent Beck, citado em Lyra, afirma que:

O desenvolvimento dirigido a teste parte do pressuposto de que

se o código for bem escrito, mais chance ele terá de ser bem

sucedido. O desenvolvimento dirigido a teste ajuda a enfocar o

fator correto no momento oportuno, de forma que se possa criar

design limpo, aperfeiçoando-o progressivamente.


Testes de Software


Testes de Software

Histórico dos testes de software:

Antes de 1990

Realizado no final do desenvolvimento pelos desenvolvedores;

Não haviam técnicas e metodologias estruturadas;

Buscava-se avaliar se o sistema funcionava e encontrar erros.

Em 1979

Glenford Myers em seu livros destaca que testar era procurar defeitos e não provar que o sistema funcionava.


Em 1988

David Gelperin e Bill Hetzel, descrevem um processo de evolução de testes, chamado de Plano de Testes;

O Plano de teste, deveria ser escrito a partir dos requisitos do sistema, buscando reduzir o número de defeitos, estabelecendo objetivos a serem atingidos pelos desenvolvedores durante as atividades de testes.

Com o tempo, embora integrados, os testes passaram fazer parte de um processo independente do desenvolvimento.


O modelo de realização de testes em todas as etapas do desenvolvimento, busca garantir padrões, qualidade e segurança do produto final;

Foca em reduzir erros no desenvolvimento, agindo desde o inicio, ainda nos requisitos, até na fase de homologação do produto.

Os testes podem ser divididos basicamente em verificação e validação:


Testes de verificação:

Avaliação de documentos e informações

coletadas em cada fase do

desenvolvimento do sistema:

Verificar requisitos

Verificar a modelagem funcional

(requisitos estão incluídos)

Verificação da modelagem interna (reflete

a modelagem interna)

Verificação de código (obedecem padrões

e normas)


Testes de validação:

Avaliação do sistema ou seus componentes, visando garantir a qualidade do produto final:

Validação da unidade (unidades de software completas com todas as linhas de código)

Validação da Integração (componentes de software não apresentem erro quando integrados)

Validação de funcionalidade (comportamento do software de acordo com os requisitos funcionais )



Validação de sistemas (Identificar erros não funcionais. Testar recursos tecnológicos)

Carga e Stress (Limite máximo que o software suporta)

Configuração (Testar as configurações de hardware e software)

Segurança (Formas de quebra de segurança do software)

Desempenho (Situação normal e pico estão dentro dos requisitos)

Confiabilidade e disponibilidade (Medidas)

Recuperação (comportamento após ocorrência de erro ou condições anormais



Validação de usabilidade (acesso, navegação, clareza e terminologia dentro das especificações)

Validação de Aceite (Cliente executa testes para validar funcionalidade, usabilidade e sistemas mitigando problemas na entrada em produção) Os métodos de testes são:

Método caixa-branca – Busca identificar problemas nas estruturas internas dos programas.

Método caixa-preta – Garantir que os requisitos de negócios estão atendidos.


http://qtsw.wordpress.com/tipos-de-testes-de-software/











Modelos de avaliação de maturidade dos processos de testes:

TPI – Test Process Improvement (Europa)

TMM – Test Maturity Model (EUA)

TCMM – Test Capability Maturity Model (EUA)


Gestão do Desenvolvimento de Software Seguro:

Implantar um processo de qualidade é um passo importante para chegarmos a um software seguro, embora o primeiro não seja pré-requisito e o nem o segundo consequência.

O que não pode se controlar, não pode ser medido.

Métrica de custos, tempo e prazo, são comuns na Engenharia de Software, as métrica de Segurança ainda são pouco utilizadas.

Deve ser acompanhada a questão da ocorrência de incidentes e divulgação da vulnerabilidade com as respectivas correções.


Métrica de Segurança:

Dois tipos de métricas podem ser adotadas: No Nível de Código

Número de bugs encontrados ou corrigidos de uma versão para outra

No Nível de Sistema

Número de vezes que um sistema é citado nos avisos de sites como CERT, MITRE Common Vulnerabilities and Exposures e Microsoft Security Bulletins


Superfície de Ataque:

Considera ações do sistema externamente visíveis aos usuários com os recursos do sistema acessados ou modificados por cada ação;

Quanto maior a superfície de ataque, maiores as chances de ataques com sucesso.

Propõe reduzi-la e assim melhorar a segurança do sistema, através: Reduzir a quantidade de códigos em

execução (Regra 80/20) Reduzir o acesso a pontos de entrada

não confiáveis. Reforçar os princípios e critérios de autenticação;


Superfície de Ataque: Reduzir privilégios para limitar o potencial de dado;

Caminhos de código anônimo. (Analise do DFD ou diagramas de interação da UML,

identificar pontos de entrada e reforça-los);

Reduzir a superfície de ataque preventivamente. Registrar na fase de projeto em um

documento especifico.

Medir a superfície de ataque e medi-la durante o desenvolvimento;

Quanto maior a superfície de ataque maior o trabalho de segurança. Se isso for inevitável,

o código deve ser de boa qualidade , conservador e defensivo.


Outras Métricas:

Trabalhos desenvolvidos com foco nas vulnerabilidades de um sistema como uma medida de segurança:

Brocklehurst, citado por Lyra, mede a segurança operacional de um sistema estimado o esforço despendido por um atacante para descobrir uma brecha de segurança e o beneficio obtido a partir dela.

Voas, citado por MANADHATA, propôs o MTTI Minimum Time To Intrusion (Tempo Mínimo para Intrusão). Métrica baseada no tempo estimado antes de qualquer intrusão. Para o cálculo MTTI, se requer conhecimento sobre as vulnerabilidades do sistema.


Monitorização de Vulnerabilidades: Todo comportamento fora do normal deve ser registrado e analisado para que possa ou

não ser considerado como um incidente de segurança. Este procedimento deve fazer

parte da politica de segurança.


Divulgação de Vulnerabilidade: Modelo de documento que descreva detalhadamente a vulnerabilidade (Exemplo, boletim

de vulnerabilidades da Microsoft) com divulgação automática para toda base instalada /

usuários.


Resposta a Incidentes: Ter um grupo responsável por receber, analisar e responder as notificações

e atividades relacionadas a incidentes de segurança em computadores;

CSIRT Computer Security Incident Response Team- Grupo de Resposta a

Incidentes de Segurança;

Pode atender uma empresa, um órgão governamental ou uma organização

acadêmica;

Deve ocorrer a troca de experiência e integração entre diversos CSIRT´s.


CSIRT Computer Security Incident Response Team

http://www.enisa.europa.eu/activities/cert/support/guide2


CSIRT Computer Security Incident Response Team

http://www.microsoft.com/security/msrc/whatwedo/history.aspx

http://www.microsoft.com/security/msrc/whatwedo/history.aspx

REFERENCIAS

LYRA, M. R. Segurança e auditoria em sistema de infomarçã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.

http://cascavel.cpd.ufsm.br/tede/tde_arquivos/12/TDE-2010-06-08T143755Z-2677/Publico/KROLL, JOSIANE.pdf






























http://www.dtic.mil/dtic/tr/fulltext/u2/a476799.pdf



Glossário

PMBOK (Project Management Body of Knowledge) é um conjunto de

práticas em gerenciamento de projetos, publicado pelo PMI - Project

Management Institute e constitui a base do conhecimento em gerenciamento de

projetos do PMI. Estas práticas são compiladas na forma de um guia,

chamado de o Guia PMBOK.

SQL Injection, é uma técnica utilizada, por exemplo, para atacar bases de

dados através de um site. Isto é feito através da inclusão de instruções SQL

em um campo de entrada de formulário web em uma tentativa de obter que

o site passe um comando SQL para o banco de dados (por exemplo,

disponibilizar o conteúdo do banco de dados para o atacante). Ela explora

uma vulnerabilidade de segurança no software do site. A vulnerabilidade

acontece quando a entrada do usuário não é adequadamente validada.

Glossário

VCS (version control system) ou SCM (source code management), é um software

com a finalidade de gerenciar diferentes versões no desenvolvimento de um

documento qualquer. Esses sistemas são comumente utilizados no

desenvolvimento de software para controlar as versões — histórico e

desenvolvimento - dos códigos-fontes e documentação.

Presente em empresas e instituições de tecnologia e de software, também são

comuns no desenvolvimento de software livre. Entre os mais comuns

encontram-se as soluções livres: CVS, Mercurial, Git e SVN. Muitas empresas

preferem soluções comerciais em razão da garantia, optando pelo ClearCase

(IBM) ou SourceSafe (Microsoft).

Controle obrigatório para Certificações, por exemplo, CMMI.


DÚVIDAS

aula 7 - segurança e auditoria de sistemas - seg no ciclo de vida desenv aplic - turma b

Documents