.
Abordagem de sistemas Um refrão que você ouve com frequência é que a segurança deve ser construída desde o térreo; que adaptar a segurança a um sistema existente é a fonte de complicações de projeto ou, pior, de projetos totalmente falhos.
Embora a Internet no início fosse em grande parte silenciosa sobre a questão da segurança, suspeito que “retrofitting” seja frequentemente usado de forma pejorativa. Certamente houve tentativas complicadas e míopes para melhorar a segurança, mas a Internet também evoluiu para incluir uma arquitetura sólida para proteger a comunicação de ponta a ponta. Concentrar-se em mecanismos provisórios nunca é uma boa receita para compreender os princípios subjacentes, independentemente do aspecto do sistema de que se esteja a falar.
Na mesma linha, vale lembrar que a Internet inicial era significativamente deficiente em outros requisitos. Na escalabilidade, por exemplo, foi originalmente assumido que todas as ligações de host para endereço poderiam ser gerenciadas usando um arquivo hosts.txt centralizado que cada administrador de sistema tinha que baixar uma vez por semana, e o EGP assumiu um “catenet” simples e sem loop. ”modelo de rotas inter-redes.
Estas e limitações semelhantes foram corrigidas ao longo do tempo, por exemplo, com DNS e BGP, respectivamente. E hoje é simples explicar as técnicas de projeto de sistemas — por exemplo, agregação e hierarquia — que foram então aplicadas.
A pergunta a ser feita é: quais são os análogos para segurança?
Este exemplo destaca um segundo espantalho que irei configurar e depois derrubar: que a segurança é excepcionalmente difícil porque é preciso acertar repetidamente, em todas as camadas do sistema.
É claro que o mesmo se aplica a todos os outros requisitos do sistema.
Não existe escalabilidade ou disponibilidade em apenas um lugar e pronto. Você precisa garantir que seu sistema seja dimensionado e sobreviva a falhas em todas as camadas e em todos os componentes. É necessário apenas um gargalo ou um único ponto de falha para derrotar o sistema.
A segurança introduziu a ideia de defesa em profundidade (DiD) para capturar essa ideia. DiD diz (em parte) que você precisa construir defesas múltiplas, possivelmente sobrepostas, mas isso é essencialmente o que alguém que constrói um sistema confiável também deve fazer. (DiD tem outras implicações, às quais voltarei em breve.)
É extremamente difícil provar que algo não pode acontecer
Isto sugere a próxima possibilidade, que é a de que a segurança é mais difícil porque a definimos como um requisito absoluto sob todas as condições, ao passo que às vezes reduzimos alguma folga em termos de escalabilidade e disponibilidade. Por exemplo, podemos permitir um limite superior na carga de trabalho que esperamos servir (por exemplo, 2x o último evento flash crowd) ou os cenários de falha improváveis que podemos ignorar com segurança (por exemplo, um corte de cabo transatlântico).
Em contraste, assumimos que um adversário sempre encontra o elo mais fraco e o explora, portanto não deve haver elos fracos. Mas os cálculos de custo/risco são exatamente os mesmos nos três casos: para segurança, você decide em quais partes do sistema confiar, quais ameaças você entende, quais recursos seus adversários podem trazer para o seu lado e quais recursos você pode gastar. defender-se contra essas ameaças. Minha conclusão é que para todos os tópicos de sistemas, mas especialmente de segurança, o ponto de partida deve ser uma articulação clara de requisitos e suposições.
Isto traz-me de volta à ideia do DiD, que é mais amplo do que apenas dizer que todas as camadas ou componentes do sistema devem ser protegidos. Também implica que qualquer defesa pode ser penetrada, mas será difícil penetrar todas elas.
Saltzer e Kaashoek defendem esse ponto de forma sucinta [PDF] quando falam que a segurança é um objectivo negativo, a questão é que é extremamente difícil provar que algo não pode acontecer. Construir sistemas altamente disponíveis tem um objetivo negativo semelhante, mas de alguma forma a segurança parece qualitativamente diferente. Talvez porque sabemos que nossos adversários estão conspirando ativamente contra nós, enquanto nosso hardware falha passivamente (exceto, é claro, quando isso não acontece, apontando para a linha difusa entre segurança e disponibilidade).
Outro aspecto aparentemente único da segurança é a centralidade dos algoritmos criptográficos. Minha pesquisa inicial (e de forma alguma exaustiva) sugere que muitos livros e cursos explicam a segurança através das lentes da criptografia. Isto é compreensível, porque sem estes algoritmos não poderíamos construir os sistemas seguros que temos hoje.
Mas a criptografia é um meio, não um fim. É um alicerce necessário; você ainda precisa construir sistemas ponta a ponta em torno desses blocos de construção, que também dependem de muitos outros componentes (e tecnologias presumidas). Se errar na arquitetura geral, mesmo os algoritmos criptográficos mais poderosos não fornecerão valor. Da perspectiva dos sistemas, a chave é abstrair o algoritmo de tal forma que você possa projetar um sistema que se baseie nele.
Se errar na arquitetura geral, mesmo os algoritmos criptográficos mais poderosos não fornecerão valor
Este é um tema familiar. Em nosso trabalho para trazer uma perspectiva de sistemas para 5G, descobri que a maior parte da atenção nos tratamentos padrão de 5G é colocada no algoritmo de codificação e na teoria da informação subjacente (por exemplo, OFDMA), com a justificativa para a arquitetura do sistema de comunicação construído em torno desse algoritmo que muitas vezes falta.
Outros algoritmos complexos aparecem em sistemas grandes (por exemplo, Paxos para consistência, enfileiramento justo ponderado para agendamento de pacotes e assim por diante), mas esses algoritmos só funcionam quando o sistema geral foi levado em consideração no conjunto correto de componentes interdependentes. Se errar na fatoração, você acoplou desnecessariamente política e mecanismo, criou suposições desnecessárias ou, de alguma forma, limitou a forma como seu sistema pode evoluir ao longo do tempo.
Isso não quer dizer que os sistemas de segurança atuais sejam mal projetados, mas ao descrever esses sistemas, a ênfase também deve ser colocada no design que é capaz de tirar vantagem dos algoritmos.
A exploração destas possíveis razões pelas quais a segurança pode ser única serviu para identificar quatro critérios sobre como devemos falar sobre segurança:
- Compreender a lógica dos mecanismos individuais e não apenas as suas actuais escolhas de implementação.
- Reconheça que os sistemas evoluem e, às vezes, no meio dessa evolução, é difícil distinguir a floresta (a arquitetura) das árvores (os mecanismos de hoje).
- Seja o mais completo e detalhado possível sobre os requisitos e suposições que um sistema faz, juntamente com os riscos que se seguem.
- Decomponha o sistema em seus componentes elementares e explique como todos eles funcionam juntos de ponta a ponta.
Esses dois últimos pontos parecem ser a chave: ser explícito sobre as suposições é essencial para lidar com um objetivo negativo e, uma vez feito isso, separar preocupações e requisitos, separar recursos e separar conceitos relacionados é a pedra angular dos sistemas. abordagem. Isto parece especialmente relevante para a segurança, onde ainda procuro a clareza que deveria ser possível. ®
.
