Sin ningún orden en particular y fuera de mi cabeza:
Proveedor único:
- relaciones más fáciles y rápidas
- (por lo general) una mejor integración de los diferentes productos, siempre que no sean kits con nueva marca
- es más fácil "pasar la pelota" si los productos A y B no se ven cara a cara; ambos son responsabilidad del mismo vendedor.
Múltiples proveedores:
- menos riesgo de bloqueo del proveedor
- más competencia, por lo tanto, posibilidad de precios más bajos
- más difícil hacer un seguimiento de licencias y contactos
- riesgo de duplicación de trabajo entre diferentes productos (la empresa A tiene un producto que realiza 1, 2, 3; la empresa B tiene otro 3, 4, 5. La tarea 3 puede, en algunos casos (por ejemplo, un antivirus) incluso generar conflictos) .
- más posibilidades de adaptación precisa de cada producto a sus necesidades
Como puede ver, la solución de múltiples proveedores parece tener más "contras", pero estos puntos no solo deben contarse, sino que deben ponderarse en cada situación específica. Además, la mayoría de los puntos son hipotéticos, son riesgos o oportunidades , y si ocurren o no depende de los proveedores y la situación.
Creo que ninguna de las opciones puede recomendarse a priori .
Las horas de trabajo y el costo de mantenimiento son más o menos proporcionales al número de proveedores, todas las demás cosas son iguales, pero los ahorros (en precio, recursos, mantenimiento y productividad) son en porcentaje, y por lo tanto son proporcionales a los Número de instalaciones y tamaño de la empresa.
En una empresa grande, con mano de obra y procedimientos para aprovechar, y con un presupuesto mayor, probablemente la opción de proveedor múltiple tenga posibilidades de mejorar. Una firma más pequeña, tal vez sin un verdadero rol dedicado a la seguridad, probablemente encuentre más conveniente negociar una sola oferta y olvidarse de ella hasta la evaluación del próximo año.
Desde un punto de vista de seguridad, creo que lo que realmente importa es el ecosistema del producto: qué productos son realmente de cualquier proveedor dado (en lugar de productos con una nueva marca y, tal vez, solo los mantengan los equipos de esqueleto que sobrevivió a la adquisición de la compañía original), cómo se respaldan y el compromiso del proveedor con esos productos: lo mejor de todo sería obviamente una compañía que garantiza un respaldo sólido para todos sus productos, no solo los "productos emblemáticos" o "desarrollados aquí". / p>
En mi experiencia, los productos "adquiridos" son comparables al original para la primera versión, notablemente peor para la (s) siguiente (s) versión (es) (cuando la empresa compradora intenta calzar el producto en su propia forma, por ejemplo, cambiando la interfaz de usuario o mover los archivos de configuración a XML y demás), luego mejorar constantemente (o deshacerse de ellos) a medida que los equipos de programación actúan juntos.
Lo que realmente hace la diferencia (pero esta es mi propia experiencia limitada) es la cantidad de tiempo (y presupuesto) que puede dedicar a seguir los productos: consultar actualizaciones, alertas de seguridad, navegar por los foros, y tal vez hacer algunas pruebas en el lado. Cuánto despacha el proveedor un producto porque cree en el producto, en lugar de mantenerlo para que pueda hacer una "oferta completa".
Por lo general, revisar las páginas de contacto e inspeccionar el producto y actualizar el historial es suficiente para evaluar el nivel de compromiso del que disfruta el producto.
Por lo general, existe un argumento sobre la "biodiversidad" en los productos de seguridad, que más o menos se reduce a:
- es probable que varios productos del mismo proveedor y base de código compartan las mismas vulnerabilidades.
- diferentes productos pueden tener una "superposición de seguridad", de modo que lo que no está protegido por uno, será interceptado por el otro.
Creo que ambos puntos están cerca de ser discutibles (excepto en la medida en que descienden de la actitud del vendedor, si lo desea):
- varios productos que comparten el código común harán que ese código se pruebe con más fuerza, más tiempo y mejor , y los errores se solucionarán de una vez por todas. Si bien las diferentes implementaciones de un mismo algoritmo, compartir una vulnerabilidad conceptual , probablemente conducirán a soluciones escalonadas y varias ventanas de vulnerabilidad.
- dos productos que tienen una "superposición" es lo mismo que productos en conflicto o duplicación de esfuerzos . Si quiero una superposición, a propósito compro dos productos para poder controlar la superposición, en lugar de confiar en una duplicación aleatoria, cuya extensión podría no ser completamente conocida (porque dos productos del mismo proveedor tiene dos enfoques diferentes; la superposición entonces probablemente estará en el área de "visión periférica" de ambos. Si es algo que viene gratis, un extra , puedo disfrutarlo, pero confiar en ello? Piensa otra vez).
Una vez más, estos factores deben evaluarse a nivel de proveedores y considerarse a la luz de la política, el presupuesto y las necesidades de su empresa.