Tecnología

Por qué la complacencia en el cumplimiento es otra forma de deuda técnica: CloudSavvy IT

Por qué la complacencia en el cumplimiento es otra forma de deuda técnica: CloudSavvy IT
ilustración de gobernanza de ti
Den Rise / Shutterstock.com

La deuda técnica se presenta en tres formas. Equipos heredados que no pueden satisfacer las necesidades actuales, proyectos de software en los que se han recortado esquinas y marcos de gobernanza mal implementados o completamente ignorados. ¿El hilo común? Riesgo.

Deuda técnica

La deuda técnica es el déficit entre el desempeño asumido de algo y lo que realmente entrega. Debido a la disparidad, es inevitable un bajo rendimiento. La deuda técnica no envejece bien. A medida que crece la disparidad, crece su exposición al riesgo.

La deuda técnica puede acumularse lentamente. El hardware y los sistemas operativos envejecidos eventualmente se deslizan hacia atrás fuera de los ciclos de soporte de sus fabricantes. La deuda técnica es el creciente riesgo de seguridad al que está exponiendo su organización al ejecutar sistemas que no reciben parches de seguridad.

A veces, puede heredar deuda técnica mediante una fusión o una adquisición. También puede fabricar deuda técnica, especialmente en proyectos de desarrollo de software. Las decisiones de diseño e implementación, a menudo forzadas al equipo de desarrollo debido a restricciones presupuestarias o plazos poco realistas, pueden generar una deuda técnica que se integra en la aplicación y existe, completamente formada, en el lanzamiento.

Los marcos de gobernanza de TI, como las políticas y los procedimientos de ciberseguridad y protección de datos, pueden acumular deuda técnica, pueden crearse con deuda técnica ya incorporada o pueden sufrir ambas.

en todos los casos, la deuda técnica equivale directamente a riesgo. Es un indicador seguro de que se debe prestar atención al problema.

Equipo de TI y deuda técnica

Todo el equipo de TI debe recibir mantenimiento. Se deben aplicar parches de seguridad al software y al firmware, y los sistemas operativos se deben actualizar a medida que se vuelven obsoletos y no son compatibles. Los discos duros deben reemplazarse al final de su vida útil esperada o ante los primeros signos de advertencia de errores en desarrollo. Si el disco duro en cuestión no forma parte de una matriz RAID, no espere las señales de advertencia. Actúe cuando el variador haya cumplido su ciclo de trabajo proyectado.

Eventualmente, todos los equipos y sistemas operativos se vuelven obsoletos. El funcionamiento de equipos viejos y sin soporte es un riesgo para la seguridad. A pesar de esto, puede ser difícil de vender para el lado comercial del negocio reemplazar algo que, para ellos, todavía está funcionando bien. E incluso cuando algo está destinado a ser actualizado y reemplazado, la deuda técnica persiste hasta que el reemplazo realmente se ha llevado a cabo.

A veces, ejecutar sistemas operativos caducados o hardware antiguo está fuera de su control inmediato. Los PC de control industrial y de laboratorio son particularmente propensos al bloqueo del sistema operativo. Esto puede suceder si una pieza de software crucial de terceros no se ha actualizado desde su lanzamiento. Eso puede obligarlo a ejecutar el sistema operativo que estaba actualizado cuando se lanzó el producto. puede ser un problema de hardware. Si el software solo funciona con una placa de interfaz antigua y particular que solo es compatible con una cosecha particular de hardware de PC, está atascado con los sistemas operativos que esos POC pueden admitir.

Reemplazar completamente el hardware y el software antiguos no es tan fácil como parece. Puede controlar la producción u otra maquinaria o procesos de misión crítica. No puede simplemente deshacerse de las cosas viejas si lo que está disponible hoy no se integra con sus sistemas de producción.

Cuanto más antiguos son los sistemas, más probable es que las personas que los implementaron hayan abandonado la empresa. Puede que no haya un conocimiento profundo de los sistemas antiguos en sus equipos de soporte. A menudo, cuando se descubre que estos sistemas antiguos están más profundamente interconectados e integrados de lo que se creía anteriormente.

Proyectos de desarrollo y deuda técnica

Los proyectos de desarrollo no triviales tienen muchas demandas. Tanto si la aplicación es para consumo interno como si se trata de un producto que se comercializará, los puntos de estrés son similares. La mayoría de ellos giran en torno a plazos, especificaciones y presupuestos.

La especificación es una lista de funciones y contenido que debe proporcionar el software. La especificación debe ser más que una larga lista de deseos. El tiempo disponible para el desarrollo, las pruebas y la documentación dicta qué contenido se puede lograr de manera realista con el recurso de desarrollo que tiene disponible y las tecnologías con las que están familiarizados.

Una especificación demasiado optimista o una fase de desarrollo demasiado corta equivalen a lo mismo. El trabajo no encaja en el tiempo disponible. El impacto que esto tiene en el equipo de desarrollo es profundo. Si se encuentran bajo el arma, las técnicas, metodologías y tecnologías conocidas serán preferidas a dedicar tiempo a evaluar nuevas plataformas, marcos o lo que sea.

Cuando está en la marcha de la muerte hacia una fecha límite, no tiene tiempo para comenzar a experimentar con nuevas tecnologías y potencialmente introducir riesgos. Ese riesgo puede ser problemas funcionales dentro del software que impactan a los usuarios o pueden ser problemas insidiosos que dan lugar a vulnerabilidades de seguridad.

A veces, el desarrollo se ve sometido a la presión del lado comercial del negocio. Pueden estipular que se utilice una nueva tecnología para garantizar que su producto se compare con la competencia. Eso significa que se ve obligado a intentar aprender la nueva tecnología y aún así cumplir con la fecha límite.

Este tipo de heridas autoinfligidas afectan la arquitectura del producto y la calidad del código. No obtendrá lo mejor de un nuevo marco, lenguaje o incluso paradigma de desarrollo hasta que sus desarrolladores estén lo suficientemente familiarizados con él para comprender sus modismos y mejores prácticas. Al menos, es probable que produzca un código que funcione mal y sea difícil de mantener. En el peor de los casos, puede presentar riesgos de seguridad.

Las bibliotecas y los kits de herramientas de terceros aceleran el desarrollo, pero pueden albergar vulnerabilidades de seguridad y su propia deuda técnica. El uso de código de terceros simplifica el desarrollo, pero puede complicar las cosas para su equipo de seguridad.

Los aspectos comerciales y de negocios de la organización deben participar en las primeras conversaciones con el desarrollo para poder redactar una descripción y especificaciones del producto realistas pero mutuamente satisfactorias, teniendo en cuenta los plazos y las tecnologías, tanto actuales como de vanguardia. Su equipo de seguridad también debe participar. Y debido a que su equipo de desarrollo nunca está sentado sin hacer nada, debe haber disposiciones para la investigación. De lo contrario, no sucederá.

Programar formalmente el tiempo y los recursos para la investigación, incluida la capacitación, es la única forma de garantizar que se lleve a cabo la investigación esencial. Puede que tenga que reclutar para lograrlo. sin investigación, nunca podrá pasar a nuevas tecnologías de forma controlada. Y sin control, te quedas con el riesgo.

Gobernanza y deuda técnica

La deuda técnica puede infiltrarse en la creación de marcos de gobernanza de manera similar a como ocurre con el desarrollo de software. En lugar de desarrollar software, está creando políticas y procedimientos, como el gobierno de TI o los sistemas de protección de datos. No le daría un proyecto de desarrollo a un equipo que nunca antes haya escrito código. Lo mismo se aplica a la documentación de gobernanza.

No puede esperar grandes resultados si le da la tarea a alguien que no tiene las habilidades adecuadas. Escribir documentos de buen gobierno es difícil. Sin ese conjunto de habilidades, es tentador copiar fragmentos de las políticas y procedimientos de otras organizaciones y tratar de editarlos en un todo coherente, pero no funciona. El resultado es una colcha de retazos de documentos que fueron diseñados para otras organizaciones.

Los autores de su gobierno deben conocer y comprender la legislación o el estándar que está tratando de satisfacer o abordar, y tener experiencia en la producción de documentos de gobierno y políticas. Si ese no es usted, interactúe con alguien que tenga esas habilidades.

Otro error común es hacer que los documentos de gobernanza sean impresionantes en lugar de convertirlos en hechos. Deben ser un fiel reflejo de lo que usted hace y necesita controlar, y cómo lo va a hacer para cumplir con la legislación o el estándar con el que está trabajando. Es imposible pasar una auditoría si los documentos contra los que está siendo auditado no reflejan sus procesos, flujos de trabajo y salvaguardas reales.

Tener documentos de gobernanza precisos y aplicables logra muy poco si no se utilizan. La complacencia en el cumplimiento es cuando tiene las políticas y los procedimientos, pero nadie los usa. Deben ser adoptados y utilizados por su fuerza laboral; de lo contrario, sus procedimientos no se llevarán a cabo de acuerdo con sus políticas. Eso es suficientemente malo, pero también significa que sus procesos no generarán una pista de auditoría. Peor aún, no seguir los procedimientos puede provocar fallas de seguridad y violaciones de datos.

Mantener un sistema de gobierno también requiere tiempo y recursos. Necesita realizar auditorías internas, por ejemplo, y debe monitorear el panorama legislativo. La legislación cambia con el tiempo y se deroga y reemplaza. La empresa puede optar o verse obligada a adherirse a un estándar que no se ha visto obligado a cumplir antes. Por ejemplo, puede comenzar a aceptar pagos online y debe cumplir con el Estándar de seguridad de datos de la industria de tarjetas de pago (PCI-DSS). Su documentación de gobernanza deberá modificarse para reflejar las nuevas demandas y garantizar que se aborden todas las cláusulas de las normas.

Enfrentar sus deudas

La deuda técnica nunca duerme y empeora cuanto más tiempo la dejas. Lo que se necesita para abordar el problema varía desde lo fácil hasta lo muy difícil. Establecer una política de parches y establecer un cronograma es fácil. Erradicar el bloqueo de los sistemas heredados puede requerir trastornos y gastos insostenibles.

Si tiene una deuda técnica que no puede abordar, o que no se puede abordar hasta que se produzca algún otro evento significativo, asegúrese de tener el riesgo capturado y caracterizado en sus documentos de evaluación de riesgo operativo y evaluación de riesgo cibernético. Registre los pasos que se han tomado para mitigar el riesgo y los pasos de contingencia que puede realizar en caso de que ocurra el riesgo.

Leave a Comment

You may also like

Más