Capítulo 15 — Fundamentos de segurança
Mapa da aula
Aula 15 publicada. Mapa, exemplo, EX043.
flowchart TD
N0["15.1 As três propriedades"]
N1["15.2 Ameaças, vulnerabilidades, controles"]
N2["15.3 Funções do CSF 2.0"]
N3["15.4 Prevenção e detecção"]
N4["15.5 Defesa em profundidade"]
N5["15.6 Menor privilégio"]
N6["15.7 Mapeamento do caso"]
N7["O risco como organizador"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX043"]
Desenho lógico
flowchart LR
N0["15.1 As três propriedades"]
N1["15.2 Ameaças, vulnerabilidades, controles"]
N2["15.3 Funções do CSF 2.0"]
N3["15.4 Prevenção e detecção"]
N4["15.5 Defesa em profundidade"]
N5["15.6 Menor privilégio"]
N6["15.7 Mapeamento do caso"]
N7["O risco como organizador"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]
[15.1 As três propriedades]
|
v
[15.2 Ameaças, vulnerabilidades, controles]
|
v
[15.3 Funções do CSF 2.0]
|
v
[15.4 Prevenção e detecção]
|
v
[15.5 Defesa em profundidade]
|
v
[15.6 Menor privilégio]
|
v
[15.7 Mapeamento do caso]
|
v
[O risco como organizador]
|
v
[Exemplo resolvido] --> [Exercício EX043]
Objetivos de aprendizagem
Você vai (1) explicar confidencialidade, integridade e disponibilidade; (2) relacionar ameaças, vulnerabilidades e controles; (3) situar as operações de segurança nas funções do NIST CSF 2.0; (4) distinguir prevenção de detecção e resposta.
15.1 As três propriedades
A confidencialidade mantém a informação longe de pessoas não autorizadas; a integridade a mantém exata e inalterada; a disponibilidade mantém os sistemas utilizáveis. O incidente do portal tocou as três: dados de clientes podiam ser vistos, endereços foram alterados e o serviço de login ficou lento. Pensar nas três mantém a resposta equilibrada. Uma equipe focada apenas na confidencialidade poderia não perceber que os endereços de entrega dos clientes podiam ter sido alterados, um problema de integridade capaz de desviar encomendas. A disponibilidade também sofreu, já que clientes legítimos enfrentaram logins lentos durante a rajada. As notas de incidente de Amara registram o efeito sobre cada propriedade separadamente.
15.2 Ameaças, vulnerabilidades, controles
Uma ameaça é uma possível causa de dano; uma vulnerabilidade é uma fraqueza que ela pode explorar; um controle reduz o risco. Senhas de clientes reutilizadas são a vulnerabilidade que o credential stuffing explora; limitação de taxa e autenticação multifator são controles. Separar os três esclarece o que cada correção faz. A Lindqvist não consegue impedir criminosos de comprar listas de senhas vazadas, a ameaça, nem consegue obrigar os clientes a parar de reutilizar senhas, a vulnerabilidade. Ela pode acrescentar controles que tornem as senhas reutilizadas menos úteis, como desacelerar tentativas repetidas e pedir um segundo fator.
15.3 Funções do CSF 2.0
O NIST Cybersecurity Framework 2.0 organiza os resultados em Govern, Identify, Protect, Detect, Respond e Recover. Um SOC entrega principalmente Detect e Respond, mas depende de Identify (conhecimento dos ativos) e alimenta Govern com informação de risco. Sem Identify, o SOC não saberia de quais sistemas o portal depende nem quem é responsável por eles. Alimentar Govern significa transformar as lições dos incidentes em informação de risco que os líderes usam para decidir, como financiar MFA para os clientes. Mapear o trabalho do SOC às funções também mostra onde a equipe depende de outros para entregar os próprios resultados.
15.4 Prevenção e detecção
Nenhuma prevenção é perfeita. A detecção encontra o que a prevenção deixou passar, e a resposta limita o dano. Um programa equilibrado investe nas três. Gastar tudo em prevenção deixa a organização às cegas quando um controle falha; gastar tudo em detecção deixa passar ataques evitáveis e inunda os analistas. A resposta transforma detecção em dano reduzido, então uma detecção sem ninguém capaz de agir sobre ela acrescenta pouco. Os orçamentos são defendidos com incidentes como a rajada no portal, que precisou das três. Cada função tem suas próprias medidas.
15.5 Defesa em profundidade
Várias camadas — limites de taxa, detecção de bots, MFA, monitoramento de alterações de conta — fazem com que uma única falha não leve ao comprometimento completo. Cada camada pega uma parte do que escapa da anterior. Os limites de taxa desaceleram as tentativas, a detecção de bots bloqueia clientes automatizados, o MFA impede que uma senha correta baste, e o monitoramento de alterações de conta identifica mau uso depois do login. As camadas devem falhar de forma independente, para que uma única configuração errada não possa desativar várias de uma vez. Amara lista quais camadas do portal existiam durante a rajada e quais faltavam.
15.6 Menor privilégio
As contas recebem apenas os direitos de que precisam, limitando o dano quando uma delas é mal usada. Na Lindqvist, a conta de banco de dados do portal pode ler e atualizar registros de clientes, mas não pode apagar tabelas nem ler dados de funcionários. Se um atacante controlasse o portal, o dano ficaria limitado ao que essa conta permite. Os analistas do SOC seguem a mesma regra: recebem acesso de leitura aos logs, enquanto ações de resposta, como bloqueios de conta, exigem permissões separadas. Os direitos são revisados a cada trimestre e removidos quando os papéis mudam.
15.7 Mapeamento do caso
Amara mapeia o incidente do portal: a vulnerabilidade (reutilização de senhas pelos clientes), o controle ausente (nenhuma opção de MFA para clientes), a detecção (sua regra de rajada) e a resposta (bloqueio da conta, aviso). O mapeamento mostra onde o esforço teria mais efeito. A detecção e a resposta funcionaram, mas ambas agiram depois que uma conta de cliente já havia sido acessada. Acrescentar uma opção de MFA trataria a lacuna antes que o login tenha sucesso. Amara apresenta o mapa a Paolo como uma tabela de uma página, que depois vira insumo para a discussão de risco da equipe de segurança com a direção.
O risco como organizador
O risco combina quão provável é o dano e quão grave ele seria. A Lindqvist classifica o portal do cliente como alto porque ele guarda endereços e cronogramas de entrega, então seu monitoramento tem prioridade sobre sistemas internos de teste.
Exemplo resolvido
Paolo pergunta a Amara em que função do CSF se enquadra uma nova opção de MFA para clientes. Ela responde Protect e observa que monitorar as taxas de adesão ao MFA e as falhas de segundo fator acrescentaria um resultado de Detect.
Caso sintético. O mapeamento e os controles são inventados.
Erros e limites
Os frameworks organizam o raciocínio, mas não definem prioridades; a avaliação de risco define.
Exercícios
- EX043 — CID no caso. Mostre como o incidente tocou a confidencialidade, a integridade e a disponibilidade. Rubrica: 3 = dados visíveis, endereço alterado, serviço lento; 2 = duas; 1 = uma; 0 = nada.
- EX044 — Vulnerabilidade e controle. Nomeie a vulnerabilidade e dois controles contra credential stuffing. Rubrica: 3 = reutilização de senhas; limitação de taxa e MFA; 2 = um controle; 1 = vago; 0 = nada.
- EX045 — Posição no CSF. Que funções do CSF um SOC entrega principalmente, e de quais depende? Rubrica: 3 = Detect e Respond; depende de Identify, informa Govern; 2 = parcial; 1 = uma; 0 = nada.
Síntese
Os fundamentos de segurança enquadram o trabalho do SOC: propriedades a proteger, riscos a reduzir e funções a entregar.
Continue estudando — capítulo 15 de 50
← Capítulo 14 (rascunho) · Índice de capítulos do curso · Capítulo 16 (rascunho) →