Introdução e Conceitos Flashcards
Trinity of trouble:
- Complexidade – Milhões de linhas de código
- Extensibilidade – Device drivers, plugins, modules, DLLs
- Conectividade – Internet (novos bugs propagam-se mais facilmente/ataques automatizados)
Objetivo da segurança consiste em garantir 3 atributos
- Confidencialidade → ausência de divulgação não autorizada de informação;
- Integridade → ausência de alterações não autorizadas ao sistema ou à informação em causa;
- Disponibilidade → prontidão do sistema para fornecer um serviço ou da informação para ser acedida.
Políticas de segurança
definem o que é ou não autorizado, ou seja, um conjunto de requisitos de segurança que têm
de ser satisfeitos pelo sistema.
Tipos de vulnerabilidades
- Design/Projeto → introduzida durante a fase de projeto do software (Exemplo: decisão de usar mecanismos
de autenticação fracos ou esquecer que as comunicações podem ser observadas na rede); - Codificação/Implementação → introduzida durante a programação do software, ou seja, um bug com
implicações de segurança (Exemplo: falta de verificação de limites de escrita num buffer); - Operacional → causada pelo ambiente no qual o software é executado pela sua configuração (Exemplo:
existência de contas sem senha num sistema de gestão de base de dados)
Zero Day
É um ataque executado contra uma ou mais vulnerabilidades previamente desconhecidas.
São muitas vezes vendidas na dark web, para combater estes ataques algumas empresas oferecem recompensas (bug
bounties) a quem descobre bugs e vulnerabilidades no seu software.
Ataque vs Exploit
Ataque é uma ação maliciosa que visa ativar uma ou mais vulnerabilidades de modo a subverter a política de
segurança. Caso o ataque seja bem-sucedido existe uma intrusão.
Exploit → Um trecho de código capaz de ativar determinada vulnerabilidade OU ação de realizar um ataque.
Patch?
Software que resolve os exploits e por consequência remove as vulnerabilidades.
Para o fabricante o patch é uma declaração publica de que o seu produto tem problemas.
Para o utilizador, instalar o remendo tem custos de administração e pode deixar o sistema instável.
Path pode ser reserse engineered.
Patch?
Software que resolve os exploits e por consequência remove as vulnerabilidades.
Para o fabricante o patch é uma declaração publica de que o seu produto tem problemas.
Para o utilizador, instalar o remendo tem custos de administração e pode deixar o sistema instável.
Path pode ser reserse engineered.
Vetor de Ataque
Pode ser caracterizado por:
- Como o ataque é realizado. (vírus/rede)
- Tipo de vulnerabilidade (SQl injection/BO)
Superfície de ataque
É a soma dos diferentes pontos onde um atacante pode tentar entrar ou extrair dados.
Objetivos para desenvolver software seguro são contraditórios
- Funcionalidade
A necessidade de fornecer meios para realizar um conjunto de tarefas. Qualidade pode ser ligada à quantidade. - Usabilidade
Facilidade de um utilizador tirar partido do produto de software. - Desempenho
Mais alto melhor. Pode ser comprometido devido aos mecanismos de segurança. - Simplicidade
Mais simples melhor. - Time to market
Colocação rápida do produto no mercado. Segurança pode aumentar o tempo, com testes
Fatores afetam grau de vulnerabilidade
a. A existência de vulnerabilidades de projeto, de codificação e operacionais;
b. Os mecanismos (ou controlos) de segurança implementados
c. O nível de maturidade dos processos de segurança da organização que utiliza o software
d. A incerteza em relação aos conhecimentos listados acima.
Software Development Life Cycle
Porque devemos incluir?
É uma metodologia formar ou informal de desenhar, criar ou realizar manutenção de software.
A maior parte dos SDLC não têm em conta a segurança do software.
Devemos incluir a segurança nos SDLC para:
a. Reduzir o número de vulnerabilidades
b. Mitigar potencias impactos das vulnerabilidades existentes
c. Entender e resolver as causas roots das vulnerabilidades para prevenir recorrências.
Waterfall model
Fase 1 – Requisitos do sistema → Devem ser considerados os requisitos gerais de segurança dos sistemas nos quais o
software fará parte. Como a legislação em vigor (Sarbanes-Oxley Act; Health Insurance Portability and Accountability
Act) e as recomendações e normas internacionais (ISO 27000).
Fase 2 – Requisitos do software → Os requisitos definidos na fase 1 devem ser traduzidos em requisitos específicos
para o software a desenvolver. Uma forma é definindo os misuse cases (casos de abuso) que são casos nos quais as
interações são causadas por um atacante e não por um utilizador normal. Podemos usar fontes de informação como:
lista de problemas comuns em softwares similares, lista recursos que o software vai lidar.
Fase 3 – Análise & Fase 4 – Desenho → Os requisitos definidos nas duas primeiras fases devem ser traduzidos para
mecanismos que os concretizem. Exemplos: mecanismos de autenticação, de proteção de confidencialidade dos dados,
e integridade dos dados.
Fase 5 – Codificação → A programação deve ser realizada de modo a não criar vulnerabilidades de codificação.
Fase 6 – Teste → Devem ser realizadas validações e testes de segurança.
Fase 7 – Operação → Medidas de segurança posteriores ao desenvolvimento. (paths)
NIST
Organizado em 4 grupos?
Descreve um subset de práticas de alto nível baseados no estabelecimento de standards e guias para práticas de
desenvolvimento de software seguro. Pode ser integrado nos SDLC.
Organizado em 4 grupos:
1. Preparar a organização → Garantir que os colaboradores, processos e tecnologias estão preparados para
desenvolver software seguro.
2. Preparar o software → proteger todos os componentes do software de manipulação ou acesso não autorizado.
3. Produzir software seguro → Objetivo é produzir software seguro que têm vulnerabilidades mínimas.
4. Responder a reports de vulnerabilidades → Identificar vulnerabilidades no software e responder de forma
apropriada a essas vulnerabilidades e prevenir vulnerabilidades similares.
