Por que a conformidade com a conformidade é outra forma de dívida técnica

Den Rise / Shutterstock. com

A dívida técnica vem em três formas. Equipamentos legados que não podem atender às necessidades de hoje, projetos de software onde os cantos foram cortados e estruturas de governança mal implementadas ou completamente ignoradas. O fio condutor? Risco.

Dívida técnica

A dívida técnica é o déficit entre o desempenho assumido de algo e o que ele realmente entrega. Por causa da disparidade, há um desempenho inferior inevitável. A dívida técnica não envelhece bem. Conforme a disparidade aumenta, sua exposição ao risco também aumenta.

A dívida técnica pode aumentar lentamente. Hardware e sistemas operacionais antigos acabam ficando para trás em relação aos fabricantes &’ ciclos de suporte. O problema técnico é o crescente risco de segurança ao qual você está expondo sua organização ao executar sistemas que não recebem patches de segurança.

Às vezes, você pode herdar dívidas técnicas por meio de uma fusão ou aquisição. Você também pode adquirir dívidas técnicas do fabricante, principalmente em projetos de desenvolvimento de software. As decisões de design e implementação — muitas vezes forçadas na equipe de desenvolvimento devido a restrições de orçamento ou prazos irrealistas — podem introduzir dívida técnica que é embutida no aplicativo e existe, totalmente formada, no lançamento.

Estruturas de governança de TI, como políticas e procedimentos de segurança cibernética e proteção de dados, podem acumular dívida técnica, podem ser criadas com dívida técnica já embutida nelas ou podem sofrer com ambas.

Publicidade

em todos os casos, a dívida técnica equivale diretamente ao risco. É um indicador seguro de que é necessário dar atenção ao problema.

Equipamento de TI e dívida técnica

Todos os equipamentos de TI devem ser mantidos. Os patches de segurança devem ser aplicados ao software e firmware, e os sistemas operacionais devem ser atualizados à medida que se tornam obsoletos e sem suporte. Os discos rígidos precisam ser substituídos no final de sua vida útil esperada ou nos primeiros sinais de aviso de erros de desenvolvimento. Se o disco rígido em questão não fizer parte de uma matriz RAID, não espere pelos sinais de aviso. Atue quando a unidade tiver cumprido seu ciclo de trabalho projetado.

Eventualmente, todos os equipamentos e sistemas operacionais se tornam obsoletos. O funcionamento de equipamentos antigos e sem suporte é um risco à segurança. Apesar disso, pode ser difícil vender para o lado comercial do negócio substituir algo que, para eles, ainda está funcionando bem. E mesmo quando algo está marcado para ser atualizado e substituído, o débito técnico persiste até que a substituição realmente ocorra.

Às vezes, a execução de sistemas operacionais expirados ou hardware antigo está além do seu controle imediato. Os PCs de controle industrial e de laboratório são particularmente propensos ao bloqueio do sistema operacional. Isso pode acontecer se um software crucial de terceiros não tiver sido atualizado desde que foi lançado. Isso pode forçá-lo a executar o sistema operacional atual quando o produto foi lançado. pode ser um problema de hardware. Se o software só funciona com uma placa de interface antiga e específica que é compatível apenas com um determinado tipo de hardware de PC que você está preso aos sistemas operacionais que esses POCs podem suportar.

A substituição completa de hardware e software antigos não é tão fácil quanto parece. Pode controlar a produção ou outras máquinas ou processos de missão crítica. Você não pode simplesmente descartar o material antigo se o que está disponível hoje não se integra aos seus sistemas de produção.

Quanto mais antigos os sistemas, mais provável é que as pessoas que os implementaram tenham deixado a empresa. Pode não haver conhecimento profundo dos sistemas antigos em suas equipes de suporte. Freqüentemente, quando se descobre que esses sistemas antigos estão mais profundamente interconectados e incorporados do que se pensava anteriormente.

Projetos de desenvolvimento e dívida técnica

Projetos de desenvolvimento não triviais têm muitas demandas colocadas sobre eles. Seja a aplicação para consumo interno ou um produto que será comercializado, os pontos de estresse são semelhantes. A maioria deles gira em torno de prazos, especificações e orçamentos.

Publicidade

A especificação é uma lista de funcionalidades e conteúdo que o software deve fornecer. A especificação deve ser mais do que uma longa lista de desejos. O tempo disponível para desenvolvimento, teste e documentação dita qual conteúdo pode ser alcançado de forma realista com o recurso de desenvolvimento que você tem disponível e as tecnologias com as quais eles estão familiarizados.

Uma especificação muito otimista ou uma fase de desenvolvimento muito curta resultam na mesma coisa. O trabalho não cabe no tempo disponível. O impacto que isso tem na equipe de desenvolvimento é profundo. Se eles se encontrarem sob o controle, técnicas, metodologias e tecnologias conhecidas terão preferência em vez de dedicar tempo para avaliar novas plataformas, frameworks ou o que quer que seja.

Quando você está na marcha da morte para um prazo final, você não tem tempo para começar a experimentar novas tecnologias e, potencialmente, introduzir riscos. Esse risco pode ser problemas funcionais no software que afetam os usuários ou podem ser questões insidiosas que dão origem a vulnerabilidades de segurança.

Às vezes, o desenvolvimento sofre pressão do lado comercial da empresa. Eles podem estipular que uma nova tecnologia seja usada para garantir que seu produto seja comparável à concorrência. Isso significa que você é forçado a tentar aprender a nova tecnologia e ainda assim cumprir o prazo.

Esses tipos de feridas autoinfligidas afetam a arquitetura do produto e a qualidade do código. Você não obterá o melhor de uma nova estrutura, linguagem ou mesmo paradigma de desenvolvimento até que seus desenvolvedores estejam suficientemente familiarizados com ele para compreender seus idiomas e práticas recomendadas. No mínimo, é provável que produza código com baixo desempenho e difícil de manter. Na pior das hipóteses, pode apresentar riscos de segurança.

Publicidade

Bibliotecas e kits de ferramentas de terceiros aceleram o desenvolvimento, mas podem conter vulnerabilidades de segurança e sua própria dívida técnica. Usar código de terceiros simplifica o desenvolvimento, mas pode complicar as coisas para sua equipe de segurança.

Os lados comercial e de negócios da organização precisam estar envolvidos nas primeiras conversas com o desenvolvimento para que uma descrição e especificação de produto realistas, mas mutuamente satisfatórias, possam ser elaboradas, levando em consideração prazos e tecnologias atuais e de ponta. Sua equipe de segurança também precisa estar envolvida. E como sua equipe de desenvolvimento nunca fica sem fazer nada, deve haver provisões para pesquisas. Caso contrário, isso não acontecerá.

Programar formalmente tempo e recursos para pesquisa — incluindo treinamento — é a única maneira de garantir que pesquisas essenciais ocorram. Você pode ter que recrutar para conseguir isso. sem pesquisa, você nunca será capaz de migrar para novas tecnologias de maneira controlada. E sem controle, você fica com o risco.

Governança e dívida técnica

O endividamento técnico pode se insinuar na criação de estruturas de governança de forma semelhante ao que acontece com o desenvolvimento de software. Em vez de desenvolver software, você está criando políticas e procedimentos, como governança de TI ou sistemas de proteção de dados. Você não daria um projeto de desenvolvimento para uma equipe que nunca escreveu um código antes. A mesma coisa se aplica à documentação de governança.

Você não pode esperar grandes resultados se entregar a tarefa a alguém que não tem o conjunto de habilidades apropriado. Escrever documentos de boa governança é difícil. Sem esse conjunto de habilidades, é tentador copiar pedaços de outras organizações &’ políticas e procedimentos e tente editá-los em um todo coeso, mas não funciona. O resultado é uma colcha de retalhos de pedaços de documentos projetados para outras organizações.

Seus autores de governança devem conhecer e compreender a legislação ou norma que você está tentando satisfazer ou abordar e ter experiência na produção de documentos de governança e política. Se esse não for você, converse com alguém que tenha essas habilidades.

Publicidade

Outra falha comum é tornar os documentos de governança impressionantes, em vez de torná-los reais. Eles precisam ser um verdadeiro reflexo do que você faz e precisa controlar, e como você vai fazer isso para cumprir a legislação ou o padrão com o qual está trabalhando. É impossível ser aprovado em uma auditoria se os documentos com os quais você está sendo auditado não refletem seus processos, fluxos de trabalho e salvaguardas reais.

Ter documentos de governança precisos e aplicáveis ​​resulta em muito pouco se eles não estiverem sendo usados. Complacência de conformidade é quando você tem as políticas e procedimentos, mas ninguém os usa. Eles devem ser adotados e usados ​​por sua força de trabalho, caso contrário, seus procedimentos não serão conduzidos de acordo com suas políticas. Isso é ruim o suficiente, mas também significa que seus processos não gerarão uma trilha de auditoria. Pior ainda, não seguir os procedimentos pode levar a falhas de segurança e violações de dados.

Manter um sistema de governança requer tempo e recursos também. Você precisa realizar auditorias internas, por exemplo, e deve monitorar o cenário legislativo. A legislação muda com o tempo e é revogada e substituída. A empresa pode escolher ou ser obrigada a aderir a um padrão que não foi forçada a cumprir antes. Por exemplo, você pode começar a receber pagamentos online e precisar estar em conformidade com o padrão de segurança de dados da indústria de cartões de pagamento (PCI-DSS). Sua documentação de governança precisará ser alterada para refletir as novas demandas e para garantir que todas as cláusulas dos padrões sejam atendidas.

Enfrentando suas dívidas

O débito técnico nunca pára e fica pior quanto mais tempo você o deixa. O que é necessário para resolver o problema varia do fácil ao muito difícil. Estabelecer uma política de patch e definir um cronograma é fácil. Erradicar o aprisionamento aos sistemas legados pode exigir transtornos e despesas insustentáveis.

Se você tem uma dívida técnica que não pode ser resolvida — ou que não pode ser resolvida até que algum outro evento significativo ocorra — certifique-se de ter o risco capturado e caracterizado em sua avaliação de risco operacional e documentos de avaliação de risco cibernético. Registre quais etapas foram tomadas para mitigar o risco e quais etapas de contingência você pode tomar caso o risco ocorra.