Arquiteto de segurança

Pelo que responde

• Um desenho cujos modos de falha foram considerados antes da construção.
• Escolhas de controle justificadas contra uma ameaça declarada, e não contra um recurso de produto.
• Padrões que os times que vão construí-los conseguem de fato implementar.

Como é medido

• Desenhos que sobrevivem ao primeiro incidente real sem redesenho.
• Adoção dos padrões, que é a única prova de que eram usáveis.
• Exceções solicitadas, que medem se a arquitetura cabe na organização que ela serve.

Quem mais tem interesse

• Os times que vão operar o resultado muito depois de o arquiteto ter ido para o próximo desenho.
• Compras, cuja aquisição fica limitada por uma decisão arquitetural de que não participou.
• Quem herda o registro de exceções, que é o verdadeiro histórico de onde a arquitetura cedeu.

O que exige

• Profundidade suficiente em redes, identidade e plataformas para errar diante de especialistas e se recuperar.
• Discernimento para aceitar um risco de propósito, em vez de escalar tudo.
• Escrita. Uma arquitetura que só existe em conversa não é uma arquitetura.
• Tolerância a ser vencido comercialmente, e disciplina para registrar a decisão assim mesmo.

As fontes publicadas

• NICCS, CISA - the NICE Workforce Framework for Cybersecurity, which defines the work roles, tasks and skills used across public, private and academic sectors
• NIST SP 800-53 Rev. 5 - the control catalogue that security architecture and policy work is written against in practice

Para onde leva

• Security engineerQuem defende
• Network security engineerQuem defende
• Security leaderQuem defende
• Network consulting engineerQuem implanta

Papéis que levam até aqui

• Governance, risk and compliance analystQuem defende

O trabalho em si

A Prática cobre como este trabalho é feito — triagem, escalação, evidência, passagem de bastão — em todo o corpus.

• Lendo um projeto que não foi você quem fezHerdar um sistema projetado por outra pessoa é uma das situações mais comuns deste trabalho, e o primeiro ato não é julgar o projeto: é recuperar as restrições a que ele respondia. Quase tudo que parece errado é uma decisão cuja razão já saiu do prédio, e as partes genuinamente erradas são indistinguíveis das que não são até você saber qual é qual.
• Para que serve, de fato, o teste de aceitaçãoTeste de aceitação não é uma demonstração de que o sistema funciona. A função real dele é registrar o que ficou acordado como "funcionando", enquanto as duas partes ainda querem concordar — para que a discussão que chega dezoito meses depois tenha um documento em vez de duas memórias.
• O runbook que ninguém consegue seguir, e por quêRunbooks falham quando são escritos pela pessoa que menos precisa deles, no momento em que ela mais entende o sistema, para um leitor que ela imagina ser ela mesma. A correção não é mais detalhe — é escrever para um leitor específico em um estado específico, e então deixar esse leitor quebrar o documento antes de você precisar dele.
• Passagem: o momento em que um projeto vira operaçãoA passagem é tratada como transferência de documentos e é, na verdade, transferência de julgamento — e julgamento é a única coisa que não se transfere numa reunião. O que dá para transferir é o raciocínio por trás das decisões, a lista do que ficou por fazer, e o nome de alguém que vai atender o telefone.
• Linha de base — saber como é o normal antes de precisarUma linha de base não é monitoração nem documentação. É a resposta à única pergunta que importa nos primeiros dez minutos de um incidente — isso sempre foi assim? — e é o único artefato que só pode ser feito quando nada está errado.
• O que uma linha de base não consegue dizerUma linha de base registra o que aconteceu durante o período em que foi tirada e promove, em silêncio, as condições daquele período ao status de normal. Ela responde se algo mudou, o que já vale muito — mas não consegue dizer se aquilo que registrou algum dia esteve certo, e a diferença entre essas duas perguntas é de onde saem as respostas erradas ditas com confiança.
• Janelas de mudança, e a aritmética do rollbackUma janela de mudança não é o tempo que a mudança leva. É o tempo da mudança mais o tempo para descobrir que deu errado mais o tempo para desfazer — e o terceiro número é o que ninguém mede, razão pela qual janelas estouram e rollbacks são abandonados pela metade.
• Nomenclatura, endereçamento e o custo de errar cedoNomenclatura e endereçamento são decididos numa tarde por quem estiver livre, e sobrevivem a todas as outras decisões do parque — não porque sejam tecnicamente difíceis de mudar, mas porque todo o resto passa, em silêncio, a depender deles. A conta é paga anos depois, por outra pessoa, numa moeda que ninguém orçou.

Ler A Prática