¿Cómo enfocan los desarrolladores web autónomos la seguridad y la responsabilidad?

Question

Responsabilidad

¿Cómo pueden los clientes esperar que pequeños equipos e individuos sean responsables de una violación de seguridad cuando las noticias están llenas de gobiernos/corporaciones con enormes presupuestos de ITSec que son hackeados? Sólo somos desarrolladores web, no expertos en seguridad, ¿esperan los blogueros hacerlo mejor que las instituciones financieras y conseguir un producto "infranqueable"? Además, no existe ningún estándar de la industria que cubra de forma exhaustiva todo el desarrollo web, así que ¿quién determina lo que es adecuado y lo que no lo es?

---

¿Cuándo puedo empezar a trabajar?

Si la seguridad al 100% es un mito (y lo es), ¿a qué nivel de competencia puede un desarrollador responsable ofrecer sus servicios? El 70% de los sitios web tienen vulnerabilidades significativas, así que la gente que los construyó obviamente no estaba esperando. Aprender a desarrollar usando la guía de OWASP sería bueno si su actualización estuviera disponible. Al menos entonces podría declarar explícitamente el grado de protección que ofrecen mis servicios y tener un estándar respetado con el que contrastar. Suponiendo que ese fuera el caso, ¿bastaría con un descargo de responsabilidad del tipo "no soy una empresa de seguridad" y "no puedo hacerme responsable de las pérdidas ocasionadas por una infracción"?

---

Acuerdos entre el promotor y el cliente que incluyen el mantenimiento

Hay quien dice que debería ser responsable de un hackeo si fue contratado para mantener el sitio una vez terminado. Creo que esto sólo debería ser así si la brecha se produjo debido a un fallo por tu parte a la hora de instalar los parches de seguridad y las actualizaciones a tiempo. Si se te culpa de cualquier otro "vector de ataque", creo que se espera de forma irrazonable que te protejas de todos los posibles exploits que existen (volviendo a ese mito de la seguridad al 100%). Y en cuanto a la respuesta a la brecha, dependiendo del alcance del problema, creo que tiene menos sentido asumir que el desarrollador medio debería ser competente para manejarlo. Parece que incluso los profesionales de la seguridad están divididos en cuanto a cuál es el protocolo adecuado. Y son especialistas.

---

Terceras partes

Parece que subcontratar la seguridad para el mantenimiento (monitorización, actualizaciones, recuperación, etc.) y el prelanzamiento (pruebas) podría ser una buena forma de evitar la responsabilidad. ¿Tendría que indicar explícitamente algo en el contrato para trasladar la responsabilidad?

Parece que se confunde cuando se habla de externalizar otras partes del proyecto, como el front-end. ¿Son los subcontratistas que contratas responsables de las vulnerabilidades en su extremo o todo el proyecto recae en ti? Dependiendo de la respuesta, ¿cómo se podrían coordinar los contratos entre el cliente, la seguridad de terceros, el diseñador, y más, de una manera integral que aborde tanto la seguridad como la responsabilidad?

---

Información que me sería útil

Lo que me sería útil sería conseguir ejemplos de trabajo de cómo otros autónomos tratan estos temas de seguridad/responsabilidad. La redacción específica de los contratos personales junto con cualquier medida adicional sería genial. Parece que el lenguaje legal es tan a prueba de balas como la seguridad, así que ¿debería convertirme en una empresa de responsabilidad limitada o contratar un "seguro contra demandas para desarrolladores" (acabo de enterarme de que eso existe)? Cualquier conocimiento o experiencia directa o indirecta es apreciada y estaría muy agradecido. Nada de lo que se proporcione se tomará como consejo legal.

Answer 1

Soy un desarrollador web independiente y un investigador de seguridad, así que mi experiencia puede ser un poco parcial.

En general, el desarrollo web es un lío bastante inseguro. Los desarrolladores más experimentados suelen ser vistos como programadores más centrados en la seguridad; primero se aprende a programar, luego se aprende a programar bien y después se aprende a programar de forma segura.

En general, si tu cliente se centra en la seguridad, recomiéndale que tenga una auditoría de seguridad independiente como parte del proceso de aprobación. Se trata de un equipo o una persona que analizará el código, realizará pruebas de penetración generales, etc., y te entregará un informe con las cosas que debes corregir antes de la aprobación final. Esto debe acordarse de antemano con el cliente, y usted debe ser seguro incluir una cláusula de indemnización en su contrato por lo que ha creado.

No soy abogado, pero esto es de mi contrato:

Asuntos legales

No puedo garantizar que mi trabajo esté libre de errores y, por lo tanto, no puedo ser responsable ante usted ni ante terceros por daños y perjuicios, incluidos el lucro cesante, la pérdida de ahorros u otros daños incidentales, consecuentes o especiales, incluso si me ha advertido de ellos. Por último, si alguna de las disposiciones de este contrato fuera ilegal, nula o, por cualquier motivo, inaplicable, dicha disposición se considerará separable de este contrato y no afectará a la validez y aplicabilidad de las disposiciones restantes.

_{<a href="https://gist.github.com/malarkey/4031110" rel="noreferrer">Fuente original - Contract Killer 3</a>}

Como desarrollador web, tu responsabilidad es tapar cualquier agujero evidente. Esto se puede encontrar en OWASP (el Proyecto de Seguridad de Aplicaciones Web Abiertas), en sus 10 principales vulnerabilidades, pero para ser breves, hay que mitigar las siguientes cosas:

• Inyección SQL (¡O cualquier inyección!)
• Gestión de autenticación/sesión rota (suplantación de otros usuarios)
• Secuencia de comandos en sitios cruzados (XSS)
• Configuración de seguridad
• Exposición de datos sensibles
• Falsificación de solicitudes en sitios cruzados (CSRF/XSRF)
• Redirecciones reflejadas (haciendo a ciegas redirect($_GET['redirect']) , por ejemplo)

Además, independientemente del lugar del mundo en el que te encuentres y de las leyes de privacidad de datos, asegúrate de cumplir con las leyes de privacidad más estrictas del mundo (la mayoría de los estados de la UE) si tu aplicación recopila datos sensibles. La separación de intereses en todos los aspectos de su aplicación debe ser respetada; el simple hecho de seguir la mayoría de las leyes de privacidad conduce a reducir las fugas de datos.

Answer 2

Como has dicho, los autónomos individuales o los equipos pequeños no pueden proporcionar los mismos niveles de seguridad que alcanzan las grandes corporaciones, pero podemos hacer todo lo posible para alcanzar un nivel razonable de seguridad, teniendo en cuenta también el hecho de que (normalmente) las grandes corporaciones tienen grandes ataques y toneladas de datos que perder mientras que una pequeña empresa tiene un número menor de ataques (esto no es una ley pero en general es así).

Sobre la seguridad en la oficina y los lugares de trabajo, en la UE tenemos una ley compleja y específica que regula cómo se deben guardar y proteger los datos (físicos y digitales) y mantener lo más seguro posible el ordenador con varios protocolos. Si te mantienes dentro de esta ley estás legalmente bien nadie puede decir nada. Personalmente pagué una consultoría a un profesional que me preparó todos los papeles y me instruyó sobre los protocolos a mantener (ya que tampoco tengo tiempo para hacerlo yo mismo).

En cuanto a la seguridad del sitio web, la forma más segura (pero digamos que la menos insegura) de desarrollar un sitio web es adoptar una plataforma y componentes razonablemente estables y mantenerlos actualizados tan pronto como haya actualizaciones disponibles, y utilizar también un proveedor de alojamiento de calidad. Eso es lo que soy capaz de hacer como un solo o pequeño equipo impulsado por el proyecto. Y desde ahora nunca he tenido grandes problemas hasta ahora.

Sobre los contratos, en pocas palabras, escribo en él que el cliente es consciente de que a pesar de todos los esfuerzos que se hacen para asegurar un sitio web, no hay garantía de que nadie lo hackeará y robará los datos o creará cualquier tipo de problema. En este caso no se me puede considerar total o parcialmente culpable de ello ni se me puede pedir ningún tipo de reembolso.