A tríade CIA: confidencialidade, integridade e disponibilidade

A tríade CIA é o modelo que a área de segurança usa para dizer o que um controle protege. Ela nomeia três propriedades da informação e dos sistemas: confidencialidade, integridade e disponibilidade. A maioria dos controles de segurança existe para manter uma ou mais dessas propriedades verdadeiras. Se você consegue dizer qual propriedade um evento quebrou, já sabe que tipo de dano ele causou e que tipo de controle deveria tê-lo impedido.

Este artigo continua de onde O que é cibersegurança? termina. Esse texto disse que segurança é proteger informação e sistemas contra danos. Este aqui reduz a ideia a três objetivos e mostra como separar eventos reais por eles.

#O que é a tríade CIA

Cada propriedade responde a uma pergunta diferente:

• Confidencialidade: quem pode ler isto?
• Integridade: isto está inalterado, e de fato vem de quem diz vir?
• Disponibilidade: as pessoas certas conseguem usar isto quando precisam?

O NIST usa esses três termos em várias publicações de segurança. A FIPS 199 monta sobre eles as categorias de informação do governo federal americano: cada categoria pergunta quanto dano a perda de cada propriedade causaria. As definições formais são mais longas e mais cuidadosas do que o resumo acima. As fontes no fim deste artigo levam a elas, e vale lê-las depois que o conceito básico estiver claro.

As letras são uma ajuda para a memória, não uma ordem de prioridade. O C não vem primeiro porque é o mais importante. Um sistema de agendamento de hospital pode tratar a disponibilidade como preocupação principal, enquanto um livro-razão de pagamentos pode dar mais peso à integridade. A prioridade certa depende do sistema e do que acontece quando ele falha.

#Por que três propriedades e não uma

"Manter seguro" esconde os trade-offs. Um sistema pode guardar bem seus segredos e ser inútil porque ninguém consegue acessá-lo. Pode estar no ar o tempo todo e servir dados errados. Pode ser exato e sempre disponível e, mesmo assim, vazar registros para as pessoas erradas. Nomear três propriedades permite fazer uma pergunta precisa sobre cada uma e escolher controles que respondam a ela.

Outros referenciais acrescentam termos, como autenticidade, responsabilização e não repúdio. Algumas definições colocam autenticidade e não repúdio dentro da integridade. A FIPS 199 faz isso. Qualquer que seja a definição, o modelo de três propriedades é o ponto de partida comum, então aprenda ele primeiro.

#Confidencialidade: o arquivo vazado

Imagine que uma empresa exporta a lista de clientes para uma planilha e salva o arquivo em uma pasta compartilhada. Todo mundo na empresa consegue abrir essa pasta. Um prestador de serviço que deveria ver apenas um projeto baixa o arquivo inteiro. Nada foi alterado. O serviço continuou no ar. A informação, porém, saiu do lugar onde deveria ficar, e a confidencialidade foi perdida.

Confidencialidade trata de quem pode ler os dados. Ela cobre dados em repouso (em um disco, em um banco), dados em trânsito (circulando pela rede) e dados em uso (abertos na memória ou na tela).

#Controles típicos para confidencialidade

• Criptografia torna os dados ilegíveis sem uma chave. Protege discos roubados e tráfego interceptado, mas não impede quem já tem a chave ou está autorizado a ler os dados.
• Controle de acesso e privilégio mínimo dão a cada pessoa apenas as permissões que o trabalho exige. O prestador do exemplo não deveria conseguir acessar a pasta inteira.
• Autenticação multifator faz uma senha roubada ter menos utilidade sozinha.

#Verificação opcional: a criptografia na prática

Os comandos abaixo rodam em um arquivo de rascunho. Eles mostram o que a criptografia faz na prática. É uma ilustração, não um laboratório avaliado, e a senha usada é só para esta demonstração. Nunca coloque segredos reais na linha de comando nem no histórico do shell.

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

Na máquina onde isto foi executado (Windows 11, Git Bash, OpenSSL 3.2.4), a saída foi:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

As três primeiras linhas são o começo do texto cifrado. Os bytes depois do cabeçalho Salted__ parecem aleatórios e mudam a cada execução, porque o OpenSSL escolhe um novo salt toda vez. Então o seu hexadecimal será diferente. A senha certa devolve a linha original. A errada falha com bad decrypt, e esse erro é tudo o que a chave errada produz. O texto do erro não revela o conteúdo. O código de oito caracteres no início da mensagem também varia entre execuções.

#Integridade: o download adulterado

Alguém baixa um instalador de um site espelho. Se o arquivo foi alterado, ele pode rodar perfeitamente. A pergunta não é se ele roda. A pergunta é se os bytes batem com o que o fornecedor publicou.

Integridade também cobre dados de um banco editados sem autorização, um log apagado depois de uma invasão e um arquivo de configuração alterado por um script que ninguém aprovou. Em todos esses casos, o dano é que você não pode mais confiar no que o dado diz.

#Hashes: detectar uma alteração

Uma função hash lê um arquivo e produz uma impressão digital de tamanho fixo. Mude um byte e a impressão muda por completo. Comparar impressões permite verificar que duas cópias são idênticas sem ler os dois arquivos lado a lado.

Os comandos abaixo criam um arquivo, registram o hash SHA-256 e alteram o conteúdo:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

Saída observada:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

O segundo hash não tem nada em comum com o primeiro, mesmo que a mudança tenha sido apenas um zero a mais. A verificação fica útil quando você guarda o hash esperado e compara com ele. Salve o hash original em release.sha256 e depois verifique:

sha256sum -c release.sha256

Para o arquivo original, a saída foi release.txt: OK. Depois que o arquivo foi adulterado, apareceu isto:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

O comando termina com status 1, então um script pode parar nele.

Hash tem um limite. Se o atacante troca o arquivo e também troca o hash publicado na mesma página, a comparação passa e não prova nada. O hash só diz que o arquivo bate com o hash que você recebeu, então você precisa de uma cópia confiável desse hash.

#Assinaturas digitais: provar quem publicou

A assinatura digital resolve esse problema. O publicador assina o arquivo com uma chave privada. Quem tem a chave pública correspondente consegue verificar a assinatura. Um atacante sem a chave privada não consegue produzir uma assinatura válida para um arquivo alterado.

Os próximos comandos usam uma chave RSA descartável, criada em uma pasta de rascunho. Não reutilize essa chave para nada real.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

No arquivo original, a verificação imprimiu Verified OK. Depois da alteração, a mesma verificação imprimiu Verification failure, seguida de linhas de erro do OpenSSL com caminhos de código-fonte. Essas linhas foram omitidas aqui.

Uma assinatura válida mostra que o arquivo foi assinado por quem tem a chave privada. Ela não mostra que essa chave pertence ao fornecedor que você esperava. Esse vínculo vem de outra etapa: um certificado, uma distribuição confiável de chaves ou uma impressão digital conferida por outro canal.

#Controles típicos para integridade

• Hashes publicados por um canal separado do download, para que um atacante que edita o arquivo não consiga editar a referência também.
• Assinaturas digitais em pacotes de software, atualizações e documentos.
• Logs de auditoria e controle de mudanças que registram quem mudou o quê e quando. Os logs também precisam de proteção, ou um invasor pode apagar o registro.
• Controle de versão para código e configuração, para que cada mudança deixe um diff e um revisor.

#Disponibilidade: o site que caiu

Uma clínica roda o sistema de agendamento em um único servidor. Um disco falha numa segunda-feira de manhã. Os pacientes não conseguem marcar consultas por um dia. Nada foi roubado e nada foi alterado. O serviço simplesmente não estava lá quando as pessoas precisaram.

Ataques causam o mesmo resultado. Um ataque de negação de serviço distribuída (DDoS) inunda um serviço com tráfego até que os usuários legítimos não consigam passar. Um ransomware pode bloquear arquivos para que a equipe não consiga trabalhar, mesmo quando nenhum dado sai da organização. A disponibilidade também cobre o caminho das pessoas: uma conta bloqueada depois de muitas tentativas de login é uma pequena perda de disponibilidade.

#Controles típicos para disponibilidade

• Backups copiados para um local separado. Um backup que você nunca restaurou é uma esperança, não um controle, então teste a restauração periodicamente.
• Redundância e failover: um segundo servidor, um segundo caminho de rede ou um banco em espera que assume quando o primeiro falha.
• Planejamento de capacidade e limitação de taxa para absorver picos normais e frear tráfego abusivo.
• Proteção contra DDoS do seu provedor de hospedagem ou de rede, que filtra o tráfego antes que ele chegue aos seus servidores.
• Um plano de recuperação por escrito que diga quanto tempo o serviço pode ficar fora do ar (tempo de recuperação) e quanto dado recente você pode perder (ponto de recuperação).

Backup tem um porém. Ele pode proteger a integridade quando permite restaurar uma cópia limpa depois de uma invasão, mas só se o backup foi feito antes da invasão e ficou fora do alcance do atacante. Backup também é dado confidencial, então precisa de criptografia e controle de acesso.

#Como as três propriedades se ligam aos controles

A maioria dos controles toca mais de uma propriedade. A pergunta útil é de qual propriedade você depende para um determinado risco.

#Um método que você pode reutilizar

1. Nomeie o ativo: um arquivo, um banco, um sistema de login, um site.
2. Para cada propriedade, pergunte qual seria o dano se o ativo fosse exposto, alterado ou ficasse indisponível.
3. Classifique cada dano como baixo, moderado ou alto. É o mesmo tipo de raciocínio que a FIPS 199 aplica a sistemas federais.
4. Escolha controles para os danos mais altos primeiro.
5. Pergunte como você saberia que o controle falhou. Um backup precisa de teste de restauração, uma assinatura precisa de verificação e uma política de senhas precisa de um jeito de notar abuso.

#Exercício no papel: classifique dez incidentes

Leia cada descrição e escreva uma letra: C (confidencialidade), I (integridade) ou A (disponibilidade). Se duas propriedades se encaixarem, escolha a que a descrição mais enfatiza e anote a outra entre colchetes. Você não precisa de computador. Tente todos os dez antes de ler o gabarito.

1. Um notebook é roubado de dentro de um carro. O disco não está criptografado, e a lista de clientes nele pode ser lida.
2. Um site espelho serve um instalador modificado. Os usuários que comparam o hash SHA-256 com o valor publicado pelo fornecedor encontram uma divergência.
3. Um ransomware criptografa o servidor de arquivos da empresa. A equipe não consegue abrir arquivos compartilhados por três dias.
4. Um funcionário envia por engano uma planilha da folha de pagamento para um endereço pessoal.
5. Uma enxurrada de tráfego atinge o site público da empresa. Os clientes veem timeouts por seis horas.
6. Um funcionário interno edita um registro de transferência para que o valor apareça como 1.000 em vez de 10. Nenhum log registra a mudança.
7. Um atacante faz phishing da senha de um administrador de banco de dados e baixa a tabela de clientes.
8. O serviço de agendamento de um hospital roda em um único servidor, sem reserva. A falha de um disco o deixa fora do ar por um dia.
9. Uma página de checkout envia o preço do navegador para o servidor, e o servidor aceita. Um usuário altera o preço de 100 para 1, e o pedido é registrado por 1.
10. Um portal de suporte mostra nomes e endereços de outros clientes para qualquer usuário logado.

#Gabarito

1. C. Quem tinha o notebook conseguia ler os dados. Criptografia em repouso teria protegido.
2. I. O arquivo alterado não bate mais com o hash publicado. A comparação do hash detectou a mudança.
3. A. A equipe perdeu acesso aos arquivos. A criptografia feita pelo ransomware também altera os arquivos, então você poderia marcar [I] também. A descrição, porém, foca na indisponibilidade.
4. C. Dados da folha chegaram a um endereço fora da empresa. É um erro de divulgação e continua sendo perda de confidencialidade.
5. A. O tráfego impediu clientes legítimos de chegar ao site.
6. I. O registro foi alterado sem autorização, e a falta de log ainda enfraquece a responsabilização.
7. C. Uma senha roubada levou à divulgação da tabela de clientes. A autenticação é um controle de confidencialidade, então o roubo da senha é o primeiro impacto.
8. A. O servidor único não tinha failover, então a falha de um disco parou o serviço.
9. I. O servidor confiou em um valor controlado pelo usuário, e o pedido registrado não bate com o preço real. Nunca deixe o cliente definir um preço.
10. C. Dados pessoais de outros clientes ficaram visíveis para usuários que não tinham autorização para vê-los.

Pontuação: acertar oito ou mais significa que você já consegue classificar incidentes. Se errou vários do grupo de integridade, releia a seção de hashes. Alguns incidentes se encaixam em duas propriedades, então aceite uma resposta fundamentada que escolha outra propriedade principal, desde que você explique o motivo.

#Erros comuns

• Tratar a tríade como um ranking. Qual propriedade importa mais depende do sistema. Decida por ativo.
• Achar que criptografia resolve tudo. Ela protege os dados de quem não tem a chave. Não faz nada contra uma conta que já está autorizada a ler os dados.
• Confundir hash com criptografia. Um hash mostra que algo mudou. Ele não esconde o conteúdo, e o hash de um valor curto e fácil de adivinhar pode ser descoberto por tentativa.
• Confiar em um backup que nunca foi testado. Muitos planos de recuperação falham na primeira restauração de verdade.
• Chamar todo incidente de invasão. Muitas falhas graves vêm de configuração errada, disco com defeito ou exclusão por engano. A tríade ajuda a enxergar esses casos também como problemas de disponibilidade ou de integridade.
• Esquecer que um hash publicado precisa de uma fonte confiável. A verificação só é tão forte quanto o lugar de onde você tirou a referência.

#Como continuar

Leia por completo as seções introdutórias do NIST SP 800-12 Rev. 1 e as definições de impacto da FIPS 199. Eles usam as palavras que você acabou de aprender, e isso facilita a leitura dos documentos formais.

Depois, leia O que é uma vulnerabilidade? para ver como uma fraqueza se transforma na perda de uma dessas três propriedades. Para entender a mecânica por trás de criptografia e hashes, leia O que é criptografia?.

Para praticar sem tocar em sistemas de terceiros, pegue alguns arquivos seus, registre os hashes, altere um caractere e rode a verificação de novo. Depois criptografe uma cópia com uma senha descartável, descriptografe e teste uma senha errada. Apague os arquivos de rascunho quando terminar. O objetivo é ver as propriedades funcionando, não montar um sistema seguro com comandos de shell.

Por fim, leia um relatório público de incidente e classifique o evento principal com o mesmo método. Pergunte qual propriedade ele atingiu primeiro e, depois, qual controle teria mudado o resultado.

#Fontes

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, junho de 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, fevereiro de 2004: https://csrc.nist.gov/pubs/fips/199/final