O que deve estar incluído na política de segurança da informação para desenvolvimento de software?
Uma política de segurança da informação para desenvolvimento de software é o documento em que sua organização estabelece como lida com a segurança das informações, sistemas e código. Para uma empresa de software, isso envolve duas coisas simultaneamente: a segurança do que você constrói e a segurança do ambiente em que o constrói. Ambas devem constar no mesmo documento, embora sejam tematicamente distintas.
Na prática, isso significa que a política geralmente aborda o escopo (quais sistemas e quais projetos de desenvolvimento estão incluídos), as responsabilidades (quem decide, quem gerencia, quem controla), a forma como o acesso ao código-fonte e aos ambientes de desenvolvimento é regulado, como as vulnerabilidades no seu próprio código são identificadas e corrigidas, como se lida com ambientes de teste em relação aos ambientes de produção, como os incidentes são registrados e como a política em si é mantida e revisada. Uma lista de verificação de um cliente geralmente solicita precisamente este tipo de documento como prova, não uma descrição técnica do seu código-fonte.
Duas camadas: o produto e o ambiente de desenvolvimento
A primeira camada diz respeito ao produto: o software que você entrega aos clientes. Isso inclui uma descrição de como você lida com vulnerabilidades descobertas após a entrega, como atualizações e correções chegam aos clientes, e quem dentro da organização é responsável por acompanhar relatos sobre problemas de segurança no produto.
A segunda camada diz respeito ao ambiente de desenvolvimento: o ambiente em que sua equipe trabalha. Este é o ambiente de controle de versão, o pipeline de construção e teste, e a separação entre ambientes de teste e produção. Aqui estão questões como quem pode acessar o código-fonte, como as alterações são revisadas antes de entrarem em produção, e como o acesso é revogado quando alguém deixa a equipe. Ambas as camadas podem constar no mesmo documento, mas frequentemente são descritas separadamente porque os riscos e os proprietários deles diferem.
Por que um cliente pergunta sobre isso
As organizações que estão sujeitas à obrigação de diligência são obrigadas a avaliar os riscos em seus fornecedores. Uma empresa de software que desenvolve para tal organização recebe, portanto, perguntas que não decorrem de sua própria obrigação, mas da cadeia de suprimentos. Uma política de segurança da informação é frequentemente o primeiro documento solicitado, pois mostra em um único documento como a segurança foi abordada de forma estruturada. Se estiver ausente, você deve explicar isso em uma lista de verificação, pergunta por pergunta, o que leva mais tempo e é menos convincente do que um documento já existente.
Se sua organização está sujeita à obrigação de diligência, à cadeia de suprimentos, ou a nenhuma delas, não é imediatamente aparente. em algumas questões vê onde a sua organização se situa oferece uma primeira indicação, com uma explicação do porquê.
Como esta política se relaciona com as medidas individuais
Uma política de segurança da informação não existe isoladamente. Ela descreve em linhas gerais como você lida com a segurança, enquanto as medidas individuais — controle de acesso, backups, registro de incidentes, avaliação de fornecedores — são a execução concreta delas. Quem escreve a política sem ter as medidas subjacentes em ordem tem um documento que não corresponde à prática. O oposto também é difícil: medidas individuais sem uma política abrangente parecem fragmentadas para quem as avalia. a visão geral de todos os tópicos por situação mostra como esses componentes se relacionam entre si.
O que muitas vezes falta na prática
Em muitas primeiras versões de tal política, falta um proprietário claro por componente: quem é responsável por manter a política de acesso atualizada, quem pela política de patches. Também uma data de avaliação fixa frequentemente falta, fazendo com que uma política de dois anos atrás ainda seja apresentada como atual enquanto a cadeia de desenvolvimento entretanto mudou. E um terceiro ponto que frequentemente falta: uma ligação explícita entre a política e os documentos comprovativos que demonstram que também é executada, como registos de direitos de acesso ou um resumo de patches implementados.
Avaliar sua própria situação
Quais componentes exatamente são esperados depende da função de sua organização na cadeia e do que um cliente específico solicita. Este artigo descreve a estrutura comum, não um modelo obrigatório, e o próprio texto da lei não prescreve um layout fixo. Para uma avaliação de sua situação específica, um jurista ou a autoridade supervisora competente é a parte apropriada; as perguntas frequentes sobre esses tipos de documentos fornece uma visão geral adicional do que frequentemente é solicitado.
Gostaria de ver como tal política, juntamente com as medidas subjacentes e documentos comprovativos, é mantida em um dossiê contínuo em vez de como documento separado? como secria.eu constrói e mantém a informação mostra isso. Caso contrário, comece com a verificação NIS2 gratuita, ou navegue pelo banco de conhecimento para ver quais tópicos são relevantes para sua organização.