Serviços
Ajudamos a levar um produto do estado de protótipo que funciona ao estado de produto que pode ser vendido na Europa com segurança. O hardware é o veículo. O trabalho a sério é a conformidade, a engenharia de segurança e a prova documental que o CRA exige.
Aplicámos este trabalho ao nosso próprio produto, em público.
Primeira leitura, sem custo e por escrito
Descreva-nos o produto por email, o que é, o que faz, como se liga e em que fase está, e em cinco dias úteis devolvemos uma nota técnica escrita, de duas páginas, com quatro coisas: a classificação provável no CRA e a razão que a sustenta, o caminho de avaliação de conformidade que daí resulta, as três decisões mais urgentes para esse produto em concreto, e as datas do regulamento que se aplicam ao caso.
Sem chamada e sem reunião. Sem seguimento comercial, a não ser que o peça. A nota é uma amostra do nosso trabalho, e se for útil já sabe onde nos encontrar.
Para que fique claro à partida. A leitura baseia-se apenas na informação que nos enviar. Não é uma auditoria, não é um parecer jurídico e não é uma avaliação de conformidade. Não envie código, credenciais nem documentação confidencial; uma descrição funcional chega bem.
Para pedir: oi@folhas.io com o assunto "Primeira leitura".
Trabalho a partir daí
- Análise de conformidade CRA
O ponto de partida de qualquer produto ligado é perceber onde ele está face aos requisitos do Anexo I e o que lhe falta. O relatório vai requisito a requisito, com o estado de cada um, a evidência que o sustenta e a natureza da correção.
- Cada requisito essencial do Anexo I avaliado contra o produto real
- Evidência concreta para cada requisito
- A natureza de cada correção identificada, seja código, infraestrutura, processo, fabrico ou documentação
a prova: a auditoria completa do nosso próprio protótipo, com as falhas todas à vista
para ler: o guia do CRA para fabricantes · a classificação do produto
- Plano de conformidade e sequência de engenharia
Define por que ordem resolver os requisitos do regulamento, porque resolvê-los fora de ordem obriga a repetir trabalho.
- A sequência do protótipo até ao produto, com as fases e as dependências explícitas
- Um modelo de custos que inclui a parte do trabalho que não é código
- O fabrico, a infraestrutura, a documentação e a organização no mesmo plano que o firmware
- Engenharia de segurança de firmware e sistema
As correções técnicas concretas, feitas pela ordem que a arquitetura de identidade dos aparelhos impõe.
- Identidade dos aparelhos, autoridade de chaves e primeiro arranque com segredo próprio por unidade
- Atualização OTA assinada e verificada, e comunicação cifrada e autenticada
- Arranque verificado e eliminação segura de dados no fim de vida
a prova: as entradas técnicas do diário, à medida que resolvemos cada uma no nosso próprio produto
- Documentação, SBOM e avaliação de conformidade
É a parte que a autoridade de fiscalização do mercado pode exigir e que o organismo notificado lê quando o caminho de avaliação passa por ele. Sem ela, um produto seguro continua na mesma fora do mercado.
- SBOM gerada no build e arquivada por versão
- Documentação técnica do Anexo VII e instruções de segurança para o utilizador
- O processo que sustenta a marcação CE
a prova: as decisões de SBOM e de período de suporte da entrada 001, tomadas antes de existir produto
para ler: SBOM para firmware embebido · o período de suporte
- Divulgação coordenada e resposta a vulnerabilidades
O canal, a política e o processo de resposta, montados antes de aparecer a primeira vulnerabilidade.
- security.txt, chave PGP e política de divulgação coordenada
- Processo de triagem e de resposta, com donos definidos
- Os modelos de notificação do artigo 14.º, ensaiados antes de fazerem falta
para ler: a divulgação coordenada · as notificações de 24 h e 72 h
Avaliações ofensivas
Viemos do pentest e do red team, e é esse o olhar que aplicamos a produtos. Estas avaliações são o mesmo ofício, com âmbito, autorização e regras de intervenção escritos antes de qualquer ação.
- Pentest whitebox de firmware, sistema e aplicação
Com acesso ao código, aos binários e à arquitetura, seguimos o caminho que um atacante faria e mostramos onde chega. Em ambientes de desenvolvimento e de pré-produção, sobre material fornecido pelo cliente.
- Modelação de ameaças e revisão de arquitetura
Antes de haver código para atacar: os ativos, os caminhos de ataque plausíveis e as decisões de desenho que os fecham, na fase em que ainda são baratas.
- Intrusão física em instalações
Uma tentativa autorizada de entrar nas instalações e chegar a um ativo definido (uma sala, um armário de rede, um posto de trabalho), com o relatório do caminho percorrido, do que o tornou possível e das correções, do controlo de acessos ao comportamento das pessoas. Quatro padrões que encontramos, em exemplos construídos.
O que não fazemos. Não realizamos testes de intrusão sobre sistemas informáticos em produção. O trabalho técnico decorre em ambientes de desenvolvimento e de pré-produção, sobre material fornecido pelo cliente.
Intrusão física, para que fique claro. Só com autorização escrita de quem tem poder sobre as instalações, âmbito, horários e ativos-alvo definidos, uma carta de autorização com contacto de emergência levada por quem executa, e regras que excluem danos e qualquer risco para pessoas. A cobertura de seguro aplicável é confirmada antes de cada intervenção.
Sobre conformidade. A declaração de conformidade é do fabricante e é da sua responsabilidade. Apoiamos na preparação e reduzimos o risco técnico; não garantimos nem podemos garantir o resultado de uma avaliação.
Âmbito e valores são definidos por proposta, depois de uma primeira conversa técnica sobre o produto e a fase em que está.
Além da consultoria, desenvolvemos o Aeromate, o nosso próprio ecossistema de controlo ambiental, que serve de caso de estudo público a todo este trabalho.
Não sabe qual destes se aplica ao seu caso? Descreva o produto e a fase em que está, e dizemos-lhe com franqueza se e onde fazemos falta. oi@folhas.io