Segurança de Aplicações e Dados

Objetivo de Aprendizagem 5.1.A: Explicar como adversários podem explorar vulnerabilidades de aplicativos e arquivos para causar perda, danos, interrupção ou destruição.

• 5.1.A.1 Um adversário pode ler quaisquer arquivos não criptografizados se tiver acesso ao dispositivo ou drive que armazena os arquivos.
• 5.1.A.2 Computadores têm usuários padrão e usuários administrativos. Usuários administrativos têm acesso para controlar configurações do sistema e podem normalmente acessar qualquer arquivo ou aplicativo em um sistema. Se usuários regulares forem concedidos privilégios administrativos em um computador, e um adversário puder comprometer a conta de um usuário, então o adversário terá privilégios elevados no sistema.
• 5.1.A.3 Quando as configurações de controle de acesso são fracas, muitos usuários frequentemente têm permissão para visualizar e às vezes até editar arquivos em um sistema. Adversários podem aproveitar configurações fracas de controle de acesso para roubar ou destruir arquivos ou interromper um aplicativo.

Objetivo de Aprendizagem 5.1.B: Explicar como ataques de aplicativo exploram vulnerabilidades.

• 5.1.B.1 Aplicativos são programas que executam instruções em computadores; são dados executáveis. Alguns aplicativos rocam localmente no computador do usuário, enquanto outros aplicativos, como aplicativos web, rocam em um servidor e são acessados por usuários através de uma rede.
• 5.1.B.2 Muitos aplicativos aceitam entrada de usuário através de campos de entrada abertos onde usuários podem digitar caracteres (ex.: letras, números, pontuação). Desenvolvedores devem incluir verificações de entrada de usuário em seu aplicativo, como entrada numérica quando solicitado um número de itens, para garantir que a entrada do usuário corresponda ao que é esperado; o aplicativo deve rejeitar entradas fora dos parâmetros esperados. Esse processo de verificar se a entrada do usuário atende aos critérios esperados antes de processá-la é chamado de validação de dados. Aplicativos que falham em validar a entrada do usuário são vulneráveis a ataques do tipo injeção, onde adversários inserem strings de caracteres inesperadas em campos de entrada para alterar o comportamento de um programa.
• 5.1.B.3 Linguagem SQL (Structured Query Language) é uma linguagem de computador usada para solicitar informações de bancos de dados e fazer alterações em bancos de dados ou entradas em bancos de dados. Aplicativos que consultam um banco de dados usando entrada não validada ou não limpa dos usuários são vulneráveis.
• 5.1.B.4 Um ataque de injeção SQL coloca comandos SQL e caracteres de controle em um campo de entrada de usuário em um aplicativo, o que pode levar a uma violação de confidencialidade causando o retorno de mais informações do que deveria, ou uma violação de integridade modificando ou excluindo dados no banco de dados.
• 5.1.B.5 Sites são escritos usando HTML (Hypertext Markup Language), e muitos sites usam Javascript para criar conteúdo dinâmico em sites ou aplicativos web. Como os comandos Javascript rocam no navegador do usuário que visita o site, esses comandos podem acessar dados sensíveis armazenados no navegador como nomes de usuário, senhas e chaves criptográficas.
• 5.1.B.6 Um ataque XSS (Cross Site Scripting) injeta código malicioso em um site que o navegador do usuário então executa. O código malicioso pode ser embutido em um link que o usuário clica (um ataque XSS Tipo I ou Refletido) ou pode ser inserido em um site através de um campo de comentário, post de fórum ou log de visitante, o que afetaria qualquer usuário visitando aquele site (um ataque XSS Tipo II ou Armazenado).
• 5.1.B.7 Quando aplicativos aceitam entrada de usuário, essa entrada é escrita em um buffer. Um buffer é uma seção designada de memória do computador com tamanho fixo. Se a quantidade de dados que o usuário entra excede o tamanho do buffer, ela pode transbordar para locais de memória adjacentes e sobrescrever outras partes da memória do computador.
• 5.1.B.8 Um ataque de overflow de buffer envia mais dados para a memória do que foi alocado, o que pode causar um travamento do sistema ou a execução de código fora do escopo da política de segurança de um programa, permitindo efetivamente que o adversário realize ações não autorizadas em um computador, como acessar, modificar ou excluir arquivos.
• 5.1.B.9 Os arquivos que executam aplicações web são armazenados em diretórios em servidores. Quando usuários acessam aplicações web, seus navegadores enviam solicitações GET usando o protocolo de transferência de hipertexto (HTTP). Uma solicitação GET acessa um arquivo em qualquer lugar no sistema de arquivos do servidor.
• 5.1.B.10 Em um ataque de travessia de diretório, adversários modificam URLs e solicitações GET para tentar acessar dados sensíveis (p. ex., nomes de usuário e senhas) no sistema de arquivos de um servidor.
  • Exemplos ilustrativos para 5.1.B.10:
    • Um servidor web armazena imagens para um site que ele hospeda no diretório /var/www/images/. Um adversário modifica uma URL solicitando uma imagem para ../../../etc/passwd. O .. move um diretório acima no sistema de arquivos; assim, os três .. consecutivos retornam o caminho para a raiz, e a partir daí o adversário está tentando acessar o arquivo passwd que retornaria uma lista de todos os usernames autorizados no dispositivo.

Objetivo de Aprendizagem 5.1.C: Avaliar e documentar riscos decorrentes de vulnerabilidades de aplicativos e dados.

• 5.1.C.1 Riscos de segurança de dados podem envolver a violação da confidencialidade quando pessoas não autorizadas podem acessar dados sensíveis, integridade quando os dados podem ser manipulados ou alterados em relação ao seu estado pretendido, e disponibilidade quando os dados podem ser destruídos ou criptografados para impedir que outros os acessem.
• 5.1.C.2 Riscos elevados decorrentes de vulnerabilidades de dados frequentemente envolvem dados altamente sensíveis (p. ex., dados regidos por leis ou regulamentos) que poderiam ser comprometidos através de uma exploração altamente provável.
  • Exemplos ilustrativos para 5.1.C.2:
    • A empresa desenvolvendo o próximo motor a jato que será usado pela Força Aérea em seus aviões está armazenando as especificações técnicas do motor em uma unidade sem criptografia.
• 5.1.C.3 Riscos moderados decorrentes de vulnerabilidades de dados frequentemente envolvem dados sensíveis que não possuem criptografia forte ou controles de acesso estritos o suficiente.
  • Exemplos ilustrativos para 5.1.C.3:
    • Uma empresa armazena os PII (Informações Pessoais Identificáveis) de seus clientes em uma planilha, e a planilha é criptografada usando uma chave pequena.
• 5.1.C.4 Riscos baixos decorrentes de vulnerabilidades de dados frequentemente envolvem informações menos sensíveis sendo criptografadas com chaves menores ou tendo controles de acesso que não são estritos o suficiente.
  • Exemplos ilustrativos para 5.1.C.4:
    • O CEO de uma organização armazena seus memos privados para sua equipe executiva em uma pasta compartilhada da empresa que é descriptografada e não possui controles de acesso.

Objetivo de Aprendizagem 5.2.A: Explicar como o estado ou a classificação de dados impacta o tipo e o grau de segurança aplicado a esses dados.

• 5.2.A.1 Organizações implementam controles de segurança específicos para cumprir requisitos legais baseados nos tipos de dados que coletam, armazenam, processam e transmitem.
• 5.2.A.2 Os dados podem ser classificados por seu estado.
  • Dados em repouso estão armazenados em um disco. É importante proteger o disco físico que armazena os dados contra destruição ou roubo. Dados em repouso também podem ser criptografados para que, se um adversário os roubar, ele não possa ler imediatamente os dados.
  • Dados em trânsito estão sendo enviados de um dispositivo para outro. Se os dados estiverem sendo transferidos por meio de mídia física (p. ex., cabos), é importante proteger a mídia. Dados em trânsito também podem ser criptografados para que, se um adversário interceptá-los, ele não possa ler imediatamente os dados.
  • Dados em uso estão sendo processados por software ou uma pessoa. Controles de acesso podem ser usados para limitar quem ou o quê tem a capacidade de usar dados de diferentes maneiras (p. ex., visualizar ou editar). Os dados devem estar descriptografados para serem usados.
• 5.2.A.3 As organizações frequentemente categorizam dados de acordo com sua sensibilidade e priorizam um maior grau de segurança para informações mais sensíveis.
• 5.2.A.4 Leis e regulamentos podem exigir que certos tipos de dados sejam armazenados, transmitidos e manuseados de acordo com regras específicas.
  • Informações pessoais identificáveis (PII) são quaisquer dados que permitem que alguém seja identificado e incluem (mas não se limitam a): nome, assinatura, número de telefone, endereço, dados biométricos (p. ex., impressões digitais), número de seguro social, data de nascimento e endereço de e-mail. A proteção desses dados é coberta por muitas leis, mas mais notavelmente pelo Privacy Act de 1974 e, para crianças abaixo dos 13 anos, pelo Children’s Online Privacy Protection Act de 1998.
  • Informações de saúde protegidas (PHI) são quaisquer dados relacionados à saúde, tratamento, pagamento por cuidados de saúde a qualquer momento e incluem (mas não se limitam a): resultados de exames, registros de tratamento, registros hospitalares, anotações de consulta médica e registros de pagamento de provedores de saúde. A proteção do PHI está incluída na Health Insurance Portability and Accountability Act de 1996.
  • Informações de cartão de pagamento (PCI) são os dados coletados por organizações para processar pagamentos via cartões (p. ex., cartões de crédito) e incluem os seguintes: nome, número da conta, data de vencimento, endereço e código CVV. A proteção desses dados é regulamentada pelo Payment Card Industry Data Security Standard (PCI-DSS).
• 5.2.A.5 Organizações que coletam dados regulamentados os rotularão e terão políticas que cumprem os requisitos legais ou regulatórios para o armazenamento seguro, transmissão e manuseio desses dados.

Objetivo de Aprendizagem 5.2.B: Identificar controles gerenciais relacionados à segurança de aplicativos e dados.

• 5.2.B.1 Uma política de criptografia descreverá os protocolos de criptografia e parâmetros de chave aceitáveis para uma organização e pode incluir:
  • Uma lista de algoritmos de criptografia aprovados para usos específicos
  • Comprimentos mínimos ou máximos de chave
  • Requisitos e parâmetros de geração de chaves criptográficas
  • Requisitos de armazenamento de chaves criptográficas
• 5.2.B.2 Uma política de segurança de aplicativo web delineará os requisitos e parâmetros para testar e mitigar vulnerabilidades de aplicativos web em uma organização, e pode incluir:
  • Parâmetros sobre quando um aplicativo está sujeito a uma avaliação de segurança
  • Prazos para remediação de vulnerabilidades com base no nível de risco
  • Parâmetros sobre como uma avaliação de segurança de aplicativo deve ser realizada (p. ex., usando ferramentas específicas ou de acordo com frameworks específicos)

Objetivo de Aprendizagem 5.2.C: Determinar um modelo de controle de acesso apropriado para proteger aplicativos e dados.

• 5.2.C.1 O controle de acesso impõe quais usuários ou aplicativos (chamados sujeitos) podem acessar, modificar, adicionar ou remover (chamadas operações) quais arquivos ou aplicativos (chamados objetos). Os modelos de controle de acesso descrevem como determinar quais subjects têm que tipo de acesso a quais objetos.
• 5.2.C.2 O controle de acesso baseado em funções (RBAC) atribui cada subject a uma função e define quais funções têm que tipo de acesso a quais objetos.
  • Exemplos ilustrativos para 5.2.C.2:
    • Um exemplo de uma função em uma empresa pode ser "contador", e um tipo de objeto pode ser o software de folha de pagamento. O controle de acesso baseado em funções pode ser usado para garantir que apenas subjects atribuídos à função de "contador" tenham acesso ao objeto de software de folha de pagamento.
• 5.2.C.3 O controle de acesso baseado em regras (RuBAC) verifica um conjunto de regras para determinar que tipo de acesso um subject deve ter para um objeto específico e, em seguida, permite ou nega tipos de acesso com base nas regras. Este modelo de controle de acesso geralmente é camado sobre outro modelo de controle de acesso.
  • Exemplos ilustrativos para 5.2.C.3:
    • Existe uma regra que proíbe subjects (mesmo aqueles que normalmente teriam acesso) de acessar um determinado banco de dados (o objeto) fora do horário comercial local. Quando um subject tenta acessar o banco de dados, mesmo que esteja autorizado a acessá-lo, ele será negado o acesso se for fora do tempo designado pela regra.
• 5.2.C.4 O controle de acesso discricionário (DAC) dá aos subjects individuais a capacidade de definir o tipo de acesso que outros subjects têm em objetos que eles possuem. Nos modelos DAC, alguns subjects são designados como administradores ou superusuários, e eles têm a capacidade de sobrescrever os controles de acesso estabelecidos por outros subjects.
  • Exemplos ilustrativos para 5.2.C.4:
    • Bob cria um arquivo (um objeto) e decide dar a Alice permissão para editar o arquivo, dar a Frank permissão para visualizar o arquivo apenas, e negar a todos os demais acesso ao arquivo completamente.
• 5.2.C.5 O controle de acesso obrigatório (MAC) segue regras estritas sobre que tipos de acesso cada nível de subject tem para objetos que estão acima, no mesmo nível ou abaixo de seu nível. Os níveis de subject e objeto são atribuídos por um administrador externo.
• 5.2.C.6 O modelo Bell-LaPadula é um modelo MAC que é frequentemente usado por governos e organizações militares para controlar a segurança das informações. Este modelo tem as seguintes duas propriedades importantes:
  • i. A Propriedade de Segurança Simples afirma que subjects não podem ler objetos que estão acima de seu nível.
  • ii. A Propriedade de Segurança * (Estrela) afirma que subjects não podem escrever em objetos abaixo de seu nível.
  • Essas regras tomadas em conjunto são frequentemente resumidas como "escreva cima, leia baixo" (WURD).
• 5.2.C.7 O princípio do menor privilégio é a ideia de que entidades devem receber exatamente tanto acesso quanto precisam para realizar sua função e nada mais.

Objetivo de Aprendizagem 5.2.D: Configurar configurações de controle de acesso em um sistema baseado em Linux.

• 5.2.D.1 Autorização é quando uma entidade é concedida permissão para ter um certo tipo de acesso a um recurso. Os controles de acesso são implantados para controlar quais usuários têm que tipos de acesso a quais dados.
• 5.2.D.2 Existem três tipos de acesso a um arquivo no Linux que podem ser definidos, e eles sempre vêm na seguinte ordem:
  • i. O acesso de leitura permite a um usuário visualizar o conteúdo de um arquivo.
  • ii. O acesso de escrita permite a um usuário fazer alterações em um arquivo.
  • iii. O acesso de execução permite a um usuário executar um arquivo binário, como um programa.
  • Eles são abreviados rwx, respectivamente. Se um usuário tiver apenas permissões de leitura e execução (não de escrita), isso seria exibido como r-x. O símbolo - indica a ausência dessa permissão.
• 5.2.D.3 Existem três entidades padrão para as quais as permissões são definidas e sempre nesta ordem: (1) o proprietário do arquivo, (2) o grupo do arquivo e (3) todos os outros usuários. Os três conjuntos são exibidos sem espaços (p. ex., rwxrwxrwx).
• 5.2.D.4 Para visualizar as configurações de permissão atuais de um arquivo, use o comando ls -l, que mostrará as configurações atuais para as entidades padrão. Se houver um símbolo + no final das permissões, isso significa que outras permissões foram definidas para esse arquivo e podem ser visualizadas com o comando getfacl.
• 5.2.D.5 Para modificar as configurações de permissão de um arquivo, use o comando chmod. Este comando pode ser usado com o método numérico ou o método simbólico.
• 5.2.D.6 Para usar chmod no método numérico, a sintaxe é chmod ### filename. Cada um dos três ### representa uma das três entidades mencionadas acima (o proprietário, o grupo, outros usuários não pertencentes ao grupo).
  • O primeiro # = o proprietário
  • O segundo # = o grupo
  • O terceiro # = outros usuários não do grupo
  • A permissão para cada entidade é determinada somando-se os valores dos tipos de acesso a serem concedidos:
  • 0 = sem permissões
  • 1 = executar
  • 2 = escrever
  • 4 = ler
  • Portanto, 3 define permissão para escrever e executar, 5 define permissão para ler e executar, 6 define permissão para ler e escrever, e 7 define permissão para ler, escrever e executar.
  • Exemplos ilustrativos para 5.2.D.6:
    • O comando chmod 750 test definiria as permissões para o proprietário como leitura, gravação e execução, para o grupo como leitura e execução, e para todos os outros como nenhum acesso.
    • O comando chmod 543 test definiria as permissões para o proprietário como leitura e execução, para o grupo apenas leitura, e para todos os outros como gravação e execução.
    • O comando chmod 777 test definiria as permissões para todas as três entidades como leitura, gravação e execução para o arquivo test.
• 5.2.D.7 Para usar chmod no método simbólico, a sintaxe é chmod entity +(or –) permission filename. As entidades são o proprietário do usuário, o grupo e outros usuários não pertencentes ao grupo. Cada entidade é representada por uma única letra.
  • u = usuário proprietário
  • g = grupo
  • o = outros
  • a = todos
  • A permissão pode ser adicionada ou removida a qualquer combinação de entidades.
  • • = adicionar a permissão
  • – = remover a permissão
  • As permissões que podem ser definidas são ler, escrever e executar.
  • r = ler
  • w = escrever
  • x = executar
  • Entidades e permissões podem ser combinadas em um único comando. Para adicionar as permissões de leitura e execução para o grupo e proprietário do usuário para um arquivo chamado testfile, o comando seria chmod ug+rx testfile.

Objetivo de Aprendizagem 5.3.A: Explicar como a criptografia pode ser usada para proteger arquivos.

• 5.3.A.1 O propósito da criptografia é ocultar informações. Um algoritmo criptográfico define um processo para criptografar e descriptografar informações. Criptografia é o processo de ocultar a informação, e descriptografia é o processo de reverter a criptografia para recuperar a informação original.
• 5.3.A.2 Um algoritmo de criptografia define um processo para combinar a informação a ser criptografada com uma chave predefinida. A informação a ser criptografada é chamada de texto claro. A saída do algoritmo de criptografia é chamada de texto cifrado.
• 5.3.A.3 O número de chaves possíveis que podem ser usadas em um algoritmo de criptografia é chamado de espaço de chaves. Quanto maior o espaço de chaves, mais tempo levará para um adversário descobrir a chave correta por acaso aleatório.
• 5.3.A.4 Algoritmos criptográficos são classificados quanto ao uso de uma chave ou duas chaves.
  • Algoritmos de criptografia simétrica usam a mesma chave para criptografar e descriptografar informações.
  • Algoritmos de criptografia assimétrica usam duas chaves diferentes — uma para criptografar informações e a outra para descriptografar informações.
• 5.3.A.5 Algoritmos criptográficos também são classificados quanto ao processamento de informações bit a bit ou em blocos de tamanho fixo de bits.
  • A criptografia em bloco lida com informações em blocos de tamanho fixo chamados blocos, produzindo um bloco de saída para cada bloco de entrada.
  • A criptografia em fluxo lida continuamente com informações de entrada, produzindo saída elemento por elemento.

Objetivo de Aprendizagem 5.3.B: Aplicar algoritmos de criptografia simétrica para criptografar e descriptografar dados.

• 5.3.B.1 Algoritmos de criptografia baseados em computador operam sobre dados binários. O algoritmo de criptografia simétrica mais comum é o Advanced Encryption Standard (AES). A criptografia AES é usada para proteger transmissões Wi-Fi, navegação na internet, criptografia de arquivos em discos e criptografia em nível de hardware em processadores.
• 5.3.B.2 O AES é um cipher em bloco de chave simétrica que criptografa dados em blocos de 128 bits (16 bytes). O AES pode operar com chaves de comprimentos variáveis. Chaves mais longas produzem criptografia mais segura, mas exigem mais tempo para criptografar e descriptografar.
• 5.3.B.3 A criptografia e descriptografia simétricas podem ser realizadas usando linha de comando, software especializado ou ferramentas web.
  • Em uma interface de linha de comando, usuários podem criptografar ou descriptografar com OpenSSL.
  • Software especializado como o AES Crypt é uma ferramenta de código aberto que pode criptografar e descriptografar arquivos.
  • Existem muitas ferramentas web para criptografar e descriptografar arquivos.
• 5.3.B.4 Usando o OpenSSL em uma CLI, um usuário pode criptografar e descriptografar um arquivo usando os seguintes comandos (note que a chave de criptografia é derivada da senha fornecida):
  • Para criptografar um arquivo chamado test usando AES com uma chave de 128 bits, use o comando: openssl enc -aes-128-cbc -e -in test -k password -out test.enc
  • Para descriptografar o arquivo criptografado usando a mesma chave, use o comando: openssl enc -aes-128-cbc -d -in test.enc -k password -out text

Objetivo de Aprendizagem 5.4.A: Determinar a chave assimétrica adequada a ser usada ao enviar ou receber dados criptografados.

• 5.4.A.1 A criptografia assimétrica permite que usuários se comuniquem de forma segura sem pré-acordar uma chave secreta compartilhada.
• 5.4.A.2 Ao usar criptografia assimétrica, cada entidade que receber dados deve primeiramente gerar um par de chaves. Pares de chaves são strings binárias de comprimento igual geradas simultaneamente através de um processo matemático. Uma chave é designada como chave pública e a outra como chave privada. As chaves são inversas matemáticas uma da outra — cada chave inverte seu parceiro. Qualquer chave pode ser usada para criptografar informações, mas apenas a outra chave no par de chades será capaz então de descriptografá-la.
• 5.4.A.3 Após o receptor gerar o par de chaves, a chave privada deve ser armazenada com segurança. Se a chave privada for exposta, compartilhada, roubada, corrompida ou comprometida, o par de chaves deve ser excluído e um novo par de chaves deve ser gerado, pois a segurança do algoritmo de criptografia repousa na segurança da chave privada. A chave pública é publicada para qualquer um visualizar e usar.
• 5.4.A.4 Para enviar informações de forma segura a alguém, o remetente usará a chave pública do receptor para criptografar os dados e enviá-los. Apenas o receptor que possui a chave privada poderá descriptografar e ler a informação.

Objetivo de Aprendizagem 5.4.B: Explicar por que o comprimento de uma chave impacta a segurança dos dados criptografados.

• 5.4.B.1 Chaves mais longas resultam em espaços de chaves maiores. Para chaves binárias, uma chave de comprimento n-bits tem um espaço de chaves de $2^n$.
• 5.4.B.2 Usando um aplicativo para adivinhar aleatoriamente uma chave de criptografia de comprimento n-bits significa que, em média, um adversário conseguirá adivinhar a chave correta em $2^n \div 2$ (ou $2^{n-1}$) tentativas.
• 5.4.B.3 Embora chaves mais longas sejam mais seguras, elas também exigem mais tempo para criptografar e descriptografar mensagens.
• 5.4.B.4 O poder computacional e a eficiência continuam melhorando, permitindo que softwares adivinhem chaves mais rapidamente. As recomendações de comprimento de chave para ambos os algoritmos de criptografia simétrica e assimétrica são aumentadas periodicamente para considerar o aumento do poder computacional.
• 5.4.B.5 A comparação de comprimento de chave só é válida ao comparar chaves para o mesmo algoritmo criptográfico.
  • Exemplos ilustrativos para 5.4.B.5:
    • Uma chave AES de 256 bits é mais segura do que uma chave AES de 128 bits.
    • Uma chave RSA de 4096 bits é mais segura do que uma chave RSA de 2048 bits.
    • Chaves RSA e AES não podem ser comparadas diretamente entre si para determinar o nível de segurança.

Objetivo de Aprendizagem 5.4.C: Aplicar algoritmos de criptografia assimétrica para criptografar e descriptografar dados.

• 5.4.C.1 Algoritmos comuns de criptografia assimétrica incluem RSA e criptografia de curva elíptica (ECC). Algoritmos assimétricos são usados em muitas aplicações, incluindo assinaturas digitais e certificados digitais.
• 5.4.C.2 Assim como na criptografia simétrica, a criptografia e descriptografia assimétricas podem ser realizadas usando linha de comando, software especializado ou ferramentas web.
  • Em uma interface de linha de comando, usuários podem criptografar ou descriptografar com OpenSSL.
  • Software especializado como o RSA Encryption Tool é uma ferramenta de código aberto que pode criptografar e descriptografar arquivos.
  • Existem muitas ferramentas web para criptografar e descriptografar arquivos.
• 5.4.C.3 Em uma CLI, um usuário pode gerar um par de chaves assimétrico e criptografar ou descriptografar arquivos conforme necessário.
  • Para gerar um par de chaves RSA de 2048 bits e salvar a chave em um arquivo chamado rsa.pem, use o comando: openssl genrsa -out rsa.pem 2048
  • Para extrair a chave pública de rsa.pem para um arquivo chamado public.pem, use o comando: openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem
  • Para criptografar o arquivo test usando criptografia RSA e o arquivo de chave public.pem, use o comando: openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc
  • Para descriptografar o arquivo test.enc usando o arquivo rsa.pem, execute o comando: openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test

Objetivo de Aprendizagem 5.5.A: Identificar os princípios de segurança de aplicações de seguro por projeto e seguro padrão.

• 5.5.A.1 Seguro por projeto é uma iniciativa que incentiva empresas a incluir segurança em todas as fases do desenvolvimento de produtos, incluindo o design. Quando organizações implementam seguro por projeto, a segurança é um princípio de design e não apenas uma característica técnica.
• 5.5.A.2 Seguro por projeto inclui três princípios de design:
  • i. As empresas devem assumir a responsabilidade pelos resultados de segurança dos clientes. As empresas devem construir produtos que atendam às necessidades de segurança de seus clientes.
  • ii. As empresas devem abraçar a transparência radical e a prestação de contas. Compartilhar rapidamente notícias e atualizações relevantes sobre produtos relacionados à segurança aumenta significativamente a segurança para todos.
  • iii. As empresas devem construir estrutura organizacional e liderança para implementar o conceito de 'seguro por design'. As empresas precisam de líderes focados em segurança e com uma postura de prioridade na segurança.
• 5.5.A.3 O conceito de 'seguro por design' inclui a ideia de 'seguro por padrão', que estabelece que os recursos de segurança de software e dispositivos devem estar ativados por padrão. Dispositivos e software devem ser seguros para uso imediato, com recursos de segurança já habilitados.

Objetivo de Aprendizagem 5.5.B: Explicar como a sanitização da entrada do usuário protege aplicações.

• 5.5.B.1 Quando usuários inserem dados em uma aplicação, a aplicação geralmente envolve essa entrada em caracteres especiais para processá-la. Os caracteres que envolvem a entrada do usuário são chamados caracteres de controle e incluem as aspas simples, as aspas duplas e o ponto e vírgula.
• 5.5.B.2 Ao criar um programa que recebe entrada do usuário, programadores devem usar uma função para verificar se a entrada atende aos critérios esperados e não inclui nenhum caractere de controle que possa ser usado para manipular o sistema. Essa função de verificação pode sanitar a entrada do usuário removendo caracteres potencialmente maliciosos, ou pode apresentar um erro ao usuário e forçar a fornecimento de uma entrada diferente. Isso pode proteger contra muitos tipos de ataques a aplicações, incluindo:
  • Ataques de injeção SQL
  • Ataques XSS
  • Ataques de travessia de diretório

Objetivo de Aprendizagem 5.6.A: Explicar como detectar ataques em dados.

• 5.6.A.1 Dispositivos registram e criam logs quando os dados são acessados e por quem. O processo de registrar e monitorar atividades de usuários é chamado de contabilidade (accounting). A análise desses logs pode revelar atividade maliciosa quando um adversário tenta acessar, copiar, mover ou excluir dados. Atividade suspeita pode incluir:
  • Acesso a arquivos que não são tipicamente acessados
  • Acesso a arquivos ou aplicativos fora dos padrões normais do usuário (incluindo horário do dia, localização e tipo de dispositivo)
  • Tentativas de excluir ou copiar arquivos sensíveis
• 5.6.A.2 Uma honeypot (caça-macacos) é um arquivo que aparenta conter dados valiosos (ex.: informações de cartão de crédito, PII, senhas), mas os dados no arquivo são falsos. Um sistema pode alertar os defensores se alguém tentar acessar a honeypot. Como a honeypot é um arquivo falso, não há motivo legítimo para acessá-lo, e qualquer tentativa de acesso seria um indicador de atividade maliciosa.
• 5.6.A.3 Funções de hash criptográficas podem gerar um digest para dados e revelam se os dados foram alterados. Se um arquivo mudou inesperadamente, isso pode ser um sinal de atividade maliciosa.

Objetivo de Aprendizagem 5.6.B: Determinar controles para detectar ataques contra aplicações ou dados.

• 5.6.B.1 O custo é um critério na determinação de controles detectivos. Controles detectivos como honeypots e o uso de valores de hash para verificar a integridade dos dados são de baixo custo. Algumas organizações investem em serviços terceirizados de prevenção à perda de dados (DLP), que monitoram o acesso, uso e transmissão de dados por usuários em toda a organização para detectar atividade suspeita; esses serviços oferecem fortes capacidades de detecção a um custo mais elevado.
• 5.6.B.2 A sensibilidade ou criticidade dos dados ou aplicações é um critério na determinação de controles detectivos. Dados ou aplicações mais sensíveis ou críticos são alvos mais prováveis de um adversário e devem ser monitorados mais de perto.
• 5.6.B.3 A classificação de dados é um critério na determinação de controles detectivos. Dados classificados como privados, educacionais, de saúde ou financeiros frequentemente possuem requisitos legais ou regulatórios de detecção e monitoramento.

Objetivo de Aprendizagem 5.6.C: Avaliar o impacto de um método para detectar ataques contra uma aplicação ou dados.

• 5.6.C.1 Para operar com velocidade eficaz, a análise de logs precisa ser augmentada com alguma automação. Honeypots oferecem capacidades de detecção quase instantâneas.
• 5.6.C.2 Alguns ferramentas DLP, honeypots e análise de logs automatizada em tempo real fornecem alertas enquanto um ataque está ocorrendo. Essas ferramentas permitem uma resposta rápida que pode interromper um ataque antes que cause mais danos. A análise retrospectiva de logs e o uso de hashes criptográficos para verificar a integridade dos dados identificam ataques após eles terem ocorrido.
• 5.6.C.3 Falsos negativos podem ocorrer na detecção de ataques a aplicações e dados. Funções de hash criptográficas apenas detectam se os dados foram alterados. Um adversário poderia visualizar e roubar dados sem alterá-los, e uma função de hash criptográfica não detectaria isso. Honeypots não podem detectar adversários que não tentam acessá-las.

Objetivo de Aprendizagem 5.6.D: Identificar se um arquivo foi alterado verificando seu hash.

• 5.6.D.1 Funções de hash criptográficas podem ajudar a identificar alterações em um arquivo porque são repetíveis: a mesma entrada sempre produz a mesma saída para uma dada função de hash.
• 5.6.D.2 Hashes podem ser calculados usando a linha de comando em um computador, um site ou software especializado.
  • No Windows PowerShell, se um usuário quisesse gerar o hash SHA256 para um arquivo chamado testfile, ele usaria o comando: Get-FileHash testfile -Algorithm SHA256
  • No BASH, o mesmo poderia ser feito com o comando: sha256sum testfile
  • No zsh, terminal comum de linha de comando em computadores Apple, isso poderia ser feito com o comando: shasum -a 256 testfile
• 5.6.D.3 Um arquivo pode ser hashed e sua saída de hash registrada. Em seguida, pode ser hashed novamente mais tarde, e a segunda saída de hash pode ser comparada à saída de hash anterior do mesmo arquivo. Se o hash de um arquivo mudar, então o arquivo foi alterado entre o momento em que o primeiro e o segundo hashes foram gerados.

Objetivo de Aprendizagem 5.6.E: Aplicar técnicas de detecção para identificar e relatar indicadores de ataques a aplicações analisando arquivos de log.

• 5.6.E.1 Ataques de injeção SQL podem ser detectados revisando logs de aplicação e servidor quanto à entrada do usuário para palavras-chave e símbolos de controle SQL, tais como:
  • Um caractere de aspa simples (') ou aspa dupla (")
  • Condições booleanas como OR 1=1
  • Dois traços duplos (que indicam um comentário em SQL): --
  • Palavras-chave de controle SQL (sempre em letras maiúsculas) como WHERE, IN, FROM
• 5.6.E.2 Ataques XSS podem ser detectados revisando a entrada do usuário quanto a tags suspeitas, particularmente a tag .
• 5.6.E.3 Para aplicações web, transbordamentos de buffer (buffer overflows) podem ser detectados verificando a quantidade de dados que o usuário está enviando para a aplicação web em sua solicitação. Os campos comumente verificados são o comprimento da URL, comprimento do cookie, comprimento da string de consulta e comprimento total da solicitação. Cadeias longas em qualquer um desses campos podem ser um indicador de uma tentativa de ataque de transbordamento de buffer.
• 5.6.E.4 Ataques de travessia de diretório podem ser detectados revisando logs de aplicação e servidor. Solicitações HTTP GET que incluem caminhos com sequências de ../ são indicadores de um adversário tentando realizar uma travessia de diretório.