Resumo CompTIA Security+ Study Guide: Capítulo 6

Domain 1.0 – Threats, Attacks, and Vulnerabilities

1.3 Given a scenario, analyzes potential indicators associated with application attacks.

Domain 2.0 – Architecture and Design

2.1 Explain the importance of security concepts in an enterprise environment

2.3 Summarizes secure application development, deployment, and automation concepts

Domain 3.0 – Implementation

3.2 Given a scenario, implements host or application security solutions

Secure Coding

De pequenos scripts a aplicações voltadas para clientes, softwares estão presentes em toda a organização. Desenvolver, criar, suportar e manter o software durante todo o período de vida é conhecido como SDLC (Software Development Life Cycle).

Importante incorporar conceitos de segurança em todas as fases do desenvolvimento.

The Software Development Life Cycle

O desenvolvimento de software não segue necessariamente um modelo formal, mas muitas empresas de desenvolvimento de software, pelo menos para aplicações maiores, seguem algum modelo. Podem até usar o SDLC mesmo sem perceber.

SDLC = Planning > Requirements > Design > Coding > Testing > Training and Transition > Ongoing Operations and Maintenance > End of Life / Decommissioning

Software Development Phases

Independentemente do SDLC ou outro processo escolhido, algumas fases são comuns:

1. Feasibility: investigação inicial para saber se “vale a pena”. Pode buscar alternativas e estimativas de custo. Resulta na recomendação de seguir ou não em frente.

2. Analysis and Requirements Definition: Sendo possível a execução, o cliente explica as funcionalidades que deseja, quais funções existem ou não existem no software em uso.

3. Design: É o desenho do software, arquitetura, pontos de integração, dataflows, e outros detalhes.

4. Development: A codificação/escrita do software.

5. Testing: Alguns testes ocorrem na fase de desenvolvimento, mas a maior parte ocorre na fase de teste, inclusive com a integração com outros elementos.

6. Training and Transition: Esta fase é dedicada ao treinamento dos usuários no novo software. Algumas vezes esta fase é chamada de acceptance, installation e deployment.

7. Ongoing operations: Fase mais duradoura, que inclui atualizações, modificações menores e outras operações de suporte.

8. Disposition: Quando um software atinge o fim de vida é importante “desligar a aplicação”.

Code Deployment Environments

A organização pode ter vários ambientes para o desenvolvimento, e embora os nomes possam variar, normalmente são:

• Development:  usado pelos desenvolvedores durante o desenvolvimento do software. Pode ser indiviudal para cada desenvolverdor ou compartilhado.

• Test: Onde o software pode ser testado, sem gerar impacto no ambiente de produção. Quality Assurance (QA) ocorre neste ambiente.

• Staging: É a transição para o código que passou com sucesso pela fase de teste e aguarda implantação na produção.

• Production: O sistema é colocado em produção para ser utilizado.

Software Development Models

Os modelos SDLC podem ser bastante detalhados, mas muitas organizações acabam escolhendo elementos de mais de um modelo, para atender às suas próprias necessidades.

• Waterfall: É um modelo sequencial, onde cada fase é seguida pela próxima fase. Composto por seis fases (Gather requirements, Design, Implement, Test/Validate, Deploy e Maintain), tem sido substituído porque é pouco flexível, mas ainda usado para o desenvolvimento de software complexos, com escopo fixo.

• Spiral: Usa modelo linear, como o Waterfall, mas adiciona um processo interativo de revisão de fases, múltiplas vezes, durante todo o ciclo de desenvolvimento. E dá ênfase a fase de Risk Assessment. É bastante flexível, permitindo trabalhar mudanças durante todo o processo. Fases: Identification, Design, Build e Evaluation.

• Agile: Método iterativo e incremental, baseado no manifesto Agile, que consiste de 4 premissas básicas:

  • indivíduos e intereações são mais importantes que processos e ferramentas

  • Software funcionando é preferível a uma documentação compreensiva

  • A colaboração do cliente substitui negociação de contrato

  • Responder às mudanças é importante, mais do que seguir um plano

  • Agile normalmente quebra o trabalho em partes menores, permitindo serem feitos mais rapidamente e tem 12 princípios.

DevSecOps and DevOps

DevOps combina o desenvolvimento de software e as operações de TI. Visa otimizar o SDLC e usa ferramentas para melhora o código, testes, atualizações e configurações, monitoramento e elementos do ciclo de vida do desenvolvimento de software.

DevSecOps descreve a parte de segurança como parte do DevOps, compartilhando a responsabilidade do desenvolvimento ao suporte (todo o ciclo).

Envolve threat analysis, comunicação, planejamento, teste e melhorias. É necessário entender o quanto a organização está disposta a correr risco.

Continuous Integration and Continuous Deployment

Continuous Integration (CI) é o desenvolvimento de práticas que verificam o código de maneira consistente. De maneira automatizada, pode-se verificar várias vezes ao dia, sem impactar na entrega do código.

Continuous Deployment (CD) ou Continuous Delivery, é a prática de fazer as mudanças em produção assim que elas forem testadas com sucesso.

O uso do CI e CD pode resultar em novas vulnerabilidades indo para produção, e por isso é importante ter logs, relatórios e continuous monitoring durante todo o processo.

Designing and Coding for Security

O primeiro momento para ajudar na segurança das aplicações é na fase de levantamento de informações. Depois, na fase de desenvolvimento, com técnicas de programação, revisão de código e teste, para melhorar a qualidade e segurança do código desenvolvido.

Secure Coding Practices

Um dos melhores recursos para melhores práticas de programação é o Open Web Application Security Project (OWASP), que tem vários padrões, guias e práticas de testes documentados, bem como várias ferramentas open sources.

Top Proactive Controls de 2018, no OWASP:

• Define Security Requirements:

• Leverage Security Frameworks and Libraries:

• Secure Database Access:

• Encode and Escape Data:

• Validade All Inputs

• Implement Digital Identity

• Enforce Access Controls

• Protect Data Everywhere

• Implement Security Logging and Monitoring

• Handle all Erros and Exceptions

API Security

Application Programming Interfaces (APIs) são interfaces entre clientes e servidores ou aplicações e sistemas operacionais que definem como o cliente deve perguntar sobre informações e como o servidor vai responder.

Se não propriamente seguradas, podem ser pontos de vulnerabilidade.

A segurança de API é baseada na autenticação, autorização e escopo adequado de dados, garantindo que dados não necessários não sejam exibidos, rate limiting, filtros de entrada, monitoração e logging.

Obviamente, a segurança do sistema operacional, rede e de endpoint também são importantes.

Code Review Models

A revisão do código, permite compartilhar o conhecimento sobre o código melhor do que a documentação, ajuda detectar problemas enquanto aplica melhores práticas e padrões.

Existem modelos de revisão formal, Agile (Pair Programming, Over the Shoulder) e o Fagan.

• Pair Programming: Modelo Agile de técnica de desenvolvimento, onde dois desenvolvedores usam uma estação de trabalho, com um escrevendo e o outro revisando (fazem o rodízio das funções). Isso proporciona revisão de código em tempo real, e o compartilhamento do código entre múltiplos desenvolvedores. Aumenta o custo, pois precisa de mais desenvolvedores.

• Over the Shoulder: Também requer dois desenvolvedores, sendo que o que escreveu o código apresenta para o segundo desenvolvedor para revisão.

• Pass-Around Code Review/Email Pass-Around Code Review: Modelo formal de revisão, onde o programador envia o código completo para o revisor verificar. Pode ter mais de um revisor, com diferentes conhecimentos/experiências e é mais flexível que o anterior, mas menos interativo (tem que aprender sobre o código lendo o próprio código).

• Tool-Assisted Reviews: Revisão baseada no uso de softwares, como o Atlassian’s Crucible Collaborative Code Review, Docady’s Static Code Review e Phabricator’s Differential Code Review.

• Formal Code Review: Quando é necessário uma revisão mais profunda, o modelo Formal é mais indicado, mas ele também consome mais tempo e requer um time de experts. Um exemplo de modelo formal é o Fagan Inspection.

• Fagan Inspection: De forma estruturada, inclui seis fases (Planing, Overview, Preparation, Meeting, Rework, Follow-up), e específica entrada e saída para cada processo, garantindo que um processo não inicie antes da diligência adequada ter sido efetuada.

Software Security Testing

Testes de segurança de software são cruciais, considerando que mesmo os melhores desenvolvedores podem introduzir falhas. A Veracode relatou que em 2019, 83% das aplicações verificadas tinham problemas de segurança. Diversos métodos, tanto manuais quanto automáticos, estão disponíveis para essa finalidade.

A análise e teste do código são essenciais para compreender seu funcionamento e identificar falhas potenciais. A análise pode ser estática, revisando o código, ou dinâmica, executando o software para testá-lo. Métodos como fuzzing, que envolve enviar dados randômicos para testar o processamento de entradas, são eficazes e normalmente automatizados.

Vulnerabilidades de injeção representam ameaças significativas, incluindo SQL Injection Attacks, Cross-site scripting e Command Injection Attacks, podendo levar à execução de código malicioso.

As vulnerabilidades de autenticação são exploradas por ataques como Password Authentication e Sessions Attacks, que podem resultar em acesso não autorizado. Redirecionamentos não validados também representam uma ameaça, permitindo que os atacantes redirecionem os usuários para sites maliciosos.

Explointing Authorization Vulnerabilities

Vulnerabilidades de autorização e explorações em aplicativos web representam uma ameaça significativa à segurança cibernética. A exploração dessas vulnerabilidades pode permitir que indivíduos obtenham acesso não autorizado a sistemas e informações sensíveis. Além disso, a falta de controle adequado sobre quem pode acessar o quê pode resultar em brechas de segurança graves.

Entre as vulnerabilidades comuns de autorização, destacam-se:

1. Insecure Direct Object References (IDOR): Isso ocorre quando um aplicativo web permite que um usuário acesse objetos específicos diretamente através de referências não seguras, sem a devida autorização. Por exemplo, um usuário malicioso pode alterar parâmetros de URL para acessar dados de outros usuários.

2. Directory Traversal: Servidores web mal configurados podem permitir que usuários naveguem em diretórios que normalmente seriam restritos, potencialmente expondo informações sensíveis, como senhas de usuários.

3. File Inclusion: Esta vulnerabilidade permite que um atacante inclua arquivos remotos ou locais no contexto de um aplicativo web. Isso pode resultar na execução de código arbitrário no servidor, abrindo a porta para uma série de ataques, incluindo a instalação de backdoors.

Além disso, ataques de Privilege Escalation buscam elevar os privilégios de um usuário comum para níveis mais altos, concedendo acesso a recursos e informações sensíveis que normalmente estariam fora de alcance.

Quanto às vulnerabilidades específicas de aplicativos web, estas incluem:

1. Cross-Site Scripting (XSS): Os atacantes exploram falhas nos aplicativos para injetar scripts maliciosos que são executados no navegador dos usuários, permitindo roubo de cookies de autenticação e outras informações confidenciais.

2. Request Forgery: Este ataque envolve induzir os usuários a executar ações indesejadas em um aplicativo no qual eles estão autenticados, sem o conhecimento deles.

3. Server-Side Request Forgery (SSRF): Os atacantes exploram vulnerabilidades em aplicativos web para fazer com que o servidor faça solicitações a outros sistemas em nome do aplicativo, potencialmente expondo informações sensíveis ou recursos internos.

Para mitigar essas vulnerabilidades, é crucial implementar controles de segurança robustos, como:

• Validação de Entrada: Verificar e validar todos os dados de entrada fornecidos pelos usuários para evitar ataques de injeção.
• Firewalls de Aplicativos da Web (WAF): Monitorar e filtrar o tráfego HTTP/HTTPS entre um aplicativo web e a Internet para bloquear ataques conhecidos.
• Segurança do Banco de Dados: Implementar práticas de segurança, como normalização, consultas parametrizadas e criptografia, para proteger os dados armazenados.

Essas medidas de segurança são fundamentais para garantir a integridade e confidencialidade dos dados em aplicativos web e sistemas de informação.

Code Security

Desenvolvedores devem se preocupar com a criação, armazenamento e entrega do código, e existem diversas opções para isso.

• Code Signing: Utilizado para confirmar a autenticidade do código, através da assinatura digital com uma chave privada.
• Code Reuse: É comum utilizar códigos internos e externos, sendo importante identificar e corrigir vulnerabilidades.
• Software Diversity: Identificação e redução da dependência de um único código ou bibliotecas.
• Code Repositories: Armazenamento centralizado de arquivos de código, garantindo controle de versão e prevenindo “dead code”.
• Integrity Measurement: Verificação da integridade do código para garantir que o que vai para produção seja o mesmo previamente aprovado.
• Application Resilience: Considerações de design visando a resiliência da aplicação.
• Scalability: Projeto que permite adição de recursos para atender ao crescimento da demanda.
• Elasticity: Capacidade de provisionamento automático de recursos conforme a necessidade.

Secure Coding Practices

Independente da linguagem, framework ou estilo, é importante seguir as melhores práticas para garantir a segurança do software.

• Source Code Comments: Comentários estratégicos no código, evitando vazamento de informações sensíveis.
• Error Handling: Tratamento adequado de entradas inesperadas para evitar falhas e vazamento de informações.
• Hard-Coded Credentials: Evitar armazenamento direto de credenciais no código para prevenir acessos não autorizados.
• Memory Management: Gerenciamento adequado da memória para evitar vazamentos e crashes.
• Memory Leak: Liberação adequada da memória após o uso para prevenir exaustão de recursos.
• Point De-Referencing: Controle para evitar crashes e vazamento de informações sensíveis.
• Buffer Overflows: Prevenção contra manipulação de dados para sobrescrever instruções na memória.
• Race Conditions: Evitar dependências entre condições que podem causar falhas de segurança.
• Unprotected APIs: Autenticação e acesso seguro às APIs para evitar acesso indevido.
• Driver Manipulation: Prevenção contra inserção de malware em drivers através de técnicas como shimming.

Até a próxima.