Header Ads Widget

Ticker

6/recent/ticker-posts

Fomento de una cultura interna de seguridad

 

Fomentar-una-cultura-interna-de-seguridad-02

La seguridad de la API es un tema común, y por una buena razón: a medida que el usuario promedio se vuelve más experto en utilizar sistemas más poderosos que nunca para completar tareas increíbles, los viejos métodos de comunicación segura se vuelven menos seguros. Lo que alguna vez se consideró la crème de la crème de la seguridad de TI y API se ha convertido en la vulnerabilidad del mañana.

Debido al mundo siempre cambiante del desarrollo de API e Internet de las cosas (IoT), fomentar una cultura interna de seguridad es fundamental para el éxito de una organización. Esto significa adoptar la seguridad de la API y la responsabilidad del desarrollador como normas culturales dentro de su organización. En este artículo, hablamos sobre por qué esta cultura es tan importante y qué pasos tomar para mejorar su enfoque interno para promover la sostenibilidad y el crecimiento .

Seguridad integral: ¿de quién es la responsabilidad?

Hay una mentalidad entre muchos desarrolladores novatos (y, desafortunadamente, muchos desarrolladores experimentados) de que la seguridad es responsabilidad del usuario. Después de todo, es el usuario el que tiene las llaves del reino en forma de nombre de usuario y contraseña, junto con los perfiles de autenticación / autorización y las necesidades de uso.

Sin embargo, esto es fundamentalmente defectuoso, aunque solo sea por una razón: el usuario no tiene acceso completo al sistema al que está solicitando acceso. Por su propia naturaleza, una API es restrictiva para aquellos que acceden a ella de forma remota en comparación con aquellos con acceso físico a su servidor. De este modo, tanto el usuario API y el desarrollador API tienen una responsabilidad de gran seguridad .

dar-llaves

Piénselo de esta manera: una persona invita a un amigo a cuidar la casa durante una semana y le da una llave. En ese momento, la clave es la responsabilidad del amigo. En un entorno de API, el nombre de usuario, la contraseña o el token son igualmente responsabilidad del usuario.

Pero, ¿de quién es la responsabilidad de la puerta de entrada? ¿Quién decidió el tipo de material del que estaba hecha la puerta? ¿Quién necesitaba cambiar la cerradura cuando dejó de funcionar correctamente? ¿Quién hizo las llaves? El propietario lo hizo. En el espacio de las API, los proveedores deben asumir la responsabilidad de garantizar la seguridad dentro de su sistema.

Un usuario solo puede ser responsable de lo que tiene: los métodos mediante los cuales se autentica y autoriza. Federación, delegación , la seguridad física y la seguridad de los datos internos están dentro del ámbito del desarrollador de API por el simple hecho de que son los más capaces de garantizar que estos sistemas sean seguros.

La importancia de la CIA

Un sistema ideal equilibra la confidencialidad, la integridad y la disponibilidad en armonía con las soluciones de seguridad y los requisitos de acceso. Con tantas API funcionando en una variedad de plataformas, y con muchos sistemas modernos que utilizan almacenamiento y computación en la nube , la seguridad interna equilibrada con la seguridad externa es de una importancia increíble.

Confidencialidad

Una cultura de seguridad interna restringe los datos solo a aquellos que tienen derecho a verlos.

cerrar con llave

La confidencialidad es el acto de mantener la información alejada de aquellos que no deberían tener acceso a ella. En el espacio de API, es necesario hacer una división entre confidencialidad externa e interna . La confidencialidad externa es, obviamente, la restricción del acceso externo a materiales confidenciales. Esto incluye el acceso a la funcionalidad de la API que no es necesaria para los requisitos específicos del usuario y el acceso restringido a las bases de datos de contraseñas.

Si bien la confidencialidad a menudo se maneja utilizando encriptación para ocultar la información , hay una gran cantidad de información que no se puede encriptar: la información que tienen los desarrolladores de la API. Esta confidencialidad interna a menudo es mucho más peligrosa de lo que podría ser cualquier problema de confidencialidad externa.

Como ejemplo, suponga que un desarrollador está utilizando un sistema de base de datos plano para contraseñas que está protegido por un servicio de autenticación interno. Este servicio, alojado en un servidor Linux, requiere un nombre de usuario y una contraseña en el nivel raíz para acceder a las tablas de autenticación.

Un pirata informático está intentando acceder a un servidor confidencial y tiene una conexión directa con sus sistemas y servidores a través de una API. Llama a la oficina del desarrollador y declara que es el proveedor de hardware del servidor que llama para emitir un parche para una vulnerabilidad masiva y que necesita una sesión privada y sin restricciones con el servidor.

El desarrollador crea una combinación de nombre de usuario / contraseña raíz, que el pirata informático puede usar para ingresar al servicio sin restricciones y robar las tablas de autenticación con fines nefastos.

Esto se llama phishing y es un gran riesgo que muchas personas han tenido. Promover una cultura interna de seguridad en este ámbito significa garantizar que los datos se mantengan seguros, que los desarrolladores sigan las políticas que garanticen la seguridad de los protocolos de autenticación y autorización, y que se eviten cosas como el phishing.

Además de garantizar que exista una cultura de seguridad, informe a los desarrolladores sobre estas amenazas. Tener un sistema de autenticación, autorización, federación y delegación correctamente utilizado y comprendido para garantizar que el acceso externo no autorizado otorgado por desarrolladores internos se convierta en una amenaza.

Integridad

Una cultura de seguridad interna garantiza que los datos solo sean modificados por aquellos autorizados para hacerlo.

usuario

La integridad en el espacio API significa garantizar la precisión y confiabilidad de los datos Al mantener flujos de datos y emplear estaciones de trabajo seguras, no deberían ocurrir cambios no autorizados a los datos en tránsito, y la alteración de la información codificada no se convierte en una amenaza.

A diferencia de la confidencialidad, las amenazas de esta categoría suelen ser internas. En el mundo empresarial, los empleados descontentos, los servidores defectuosos e incluso un control de versiones deficiente pueden provocar el cambio de datos durante el ciclo de tránsito. El software mal codificado puede devolver valores que no deben devolverse, las vulnerabilidades que deben protegerse con el software pueden violarse y la transmisión física del código puede resultar en sesiones capturadas y ataques de intermediarios .

Una de las mejores formas de administrar la integridad de un sistema es educar a los desarrolladores sobre cómo debería verse exactamente su tráfico de API. Esto se puede hacer con una variedad de soluciones API Metric que pueden mostrar la tasa de tráfico, el tipo de datos solicitados, la longitud promedio de la conexión y más.

Sepa qué servicios son atacados con más frecuencia y a través de qué método, y tome medidas para proteger estos recursos, como estaciones de trabajo bastión (nodos que están diseñados expresamente para soportar una enorme cantidad de tráfico ilícito) o zonas DMZ (zonas que separan una red interna segura). desde una red externa insegura). Evite estos problemas al educar a los desarrolladores sobre la transmisión segura de datos, los requisitos de protocolo y lo que es un flujo de datos "normal" y "anormal".

Adopte una cultura que otorgue una importancia primordial a la gestión de riesgos , especialmente cuando se trata de integridad, una de las cosas más difíciles de mantener. Sin embargo, equilibre la gestión de riesgos con la eficacia del servicio, asegurando que la integridad exista junto con la facilidad de uso y acceso para clientes y usuarios.

Linda Stutsman lo expresó mejor en una entrevista con Andrew Briney de Information Security Magazine :

“Se dice una y otra vez, pero es absolutamente cierto: hay que llegar al punto en que la gestión de riesgos se convierta en parte de su forma de trabajar. Eso comienza con buenas políticas impulsadas por la empresa, no por la seguridad. La comunicación es absolutamente el factor principal, a través de políticas y programas de capacitación. Luego está determinando las pocas métricas importantes que necesita medir ".

Por otro lado, la integridad de una API no depende totalmente del software o de los factores de transmisión del código; se puede decir mucho de la red física que la API planea ejecutar y las limitaciones inherentes a la misma.

Por ejemplo, si un desarrollador de API está creando una API para la transmisión de registros de área local, como un entorno hospitalario, sabiendo si la señal se transmitirá a través de un cable coaxial o de fibra óptica, si estos cables se ejecutarán cerca de la transmisión de energía y provocarán la pérdida de datos. , e incluso si los datos saldrán a una Internet más amplia, informará al desarrollador sobre las funciones de verificación de errores, mitigación de pérdida de paquetes y aumento de la integridad que podrían ser necesarias y mantenidas.

Aprenda a medir el rendimiento de su API con análisis de métricas

Disponibilidad

Una cultura de seguridad interna se centra en un alto tiempo de actividad y facilidad de acceso.

teclas

Si bien es importante asegurarse de que su API tenga una gran confidencialidad e integridad de los datos, quizás el atributo más importante de una cultura de seguridad eficaz es garantizar la disponibilidad. Después de todo, si sus usuarios no pueden utilizar una API, ¿es realmente una API?

Ya sea que una API sea privada, pública o centrada en socios , garantizar que su API sea accesible es increíblemente importante. Esto se puede equilibrar de varias maneras, pero todas estas técnicas se pueden resumir ampliamente en dos categorías: garantizar la disponibilidad mediante la actividad del desarrollador y mediante la actividad del usuario .

Veamos la actividad de los desarrolladores . En primer lugar, los desarrolladores deben comprender que todo lo que hagan en una API o el servidor en el que se ejecuta una API afectará la disponibilidad del sistema. Actualizar el firmware del servidor, cambiar la forma en que funciona una llamada a la API o incluso chocar accidentalmente con una regleta de enchufes puede provocar la falta de disponibilidad para muchos usuarios.

Además, algunos cambios que se consideran simples son realmente catastróficos para el usuario final. Considere el control de versiones : si bien la actualización a la versión más reciente de una dependencia puede brindar el contenido más actualizado para su usuario, si esta actualización no es compatible con sistemas o servicios heredados, es posible que una API esté básicamente rota . Los cambios deben equilibrarse a lo largo del ciclo de vida de la API, independientemente de si la API en cuestión es una API propia o de terceros .

La actividad del usuario es mucho más fácil de manejar. Las amenazas a la disponibilidad por parte de los usuarios a menudo surgen de solicitudes mal formadas en el caso de amenazas no maliciosas y en el escaneo de puertos o la inundación de tráfico (especialmente la inundación de UDP) en amenazas maliciosas. Estas amenazas de usuario son más fáciles de manejar y, a menudo, se pueden solucionar simplemente eligiendo el tipo de arquitectura correcto e implementando soluciones como mitigación de desbordamiento de búfer, registros de memoria e informes de errores.

Recorrido por la publicación del blog CTA 5-01

4 aspectos de una cultura de seguridad

Hasta ahora hemos cubierto conceptos de alto nivel: analicemos lo que es una cultura de seguridad eficaz en cuatro puntos. Estos puntos, cuando se implementan en su totalidad, no solo deben crear una cultura de seguridad efectiva, sino que también deben conducir al crecimiento y la estabilidad a lo largo del tiempo.

Una cultura de seguridad implica:

  • Conciencia de las amenazas : los desarrolladores deben estar al tanto de las amenazas potenciales a su sistema y codificar sus API en consecuencia;
  • Conocimiento de las vulnerabilidades : los desarrolladores deben reconocer las vulnerabilidades inherentes a su sistema, servidores o dispositivos. Esto incluye vulnerabilidades que surgen de su propio código y sistemas, así como de proveedores, servicios o servidores de terceros;
  • Conciencia de las fallas : los desarrolladores deben ser conscientes de sus propias fallas personales. Si un desarrollador tiene un historial de extravío de memorias USB, intercambio de contraseñas o algo peor, no debería ser responsable de los servicios seguros administrados internamente;
  • Conocimiento de las limitaciones : los desarrolladores deben conocer la red que se utiliza para su API y las limitaciones que representa. Las soluciones de seguridad para una intranet cercana que funciona con cable de fibra óptica serán diferentes a las soluciones para una conexión de cara a Internet que se ejecuta en un par trenzado o coaxial;

Considerando la "cultura"

Es importante considerar la función de la cultura dentro de una organización. Todos los temas tratados en este artículo son aplicables en una amplia gama de situaciones, entornos y organizaciones, debido a la naturaleza de la seguridad. Los conceptos de seguridad son universales y escalan directamente con el tamaño de los datos que se protegen.

La forma en que se construye y perpetúa una cultura de seguridad está directamente influenciada por el tipo de organización que la adopta. Por ejemplo, en una organización gubernamental, esta cultura se puede aplicar directamente a través de políticas, leyes y pautas, mientras que en una organización sin fines de lucro, esta información debe difundirse a través de clases o pautas de instrucción a los trabajadores que pueden no estar familiarizados con políticas tan estrictas.

En un entorno corporativo, gran parte de esta seguridad se puede administrar directamente mediante la limitación de privilegios y habilidades. En un entorno corporativo, cada servidor o servicio puede tener su propio administrador, y al limitar los poderes, conocimientos y habilidades solo a aquellos que lo necesitan para función, mantiene una cultura de seguridad.

Sin embargo, en una pequeña empresa emergente o sin fines de lucro, una persona puede necesitar acceso a diez servicios y servidores diferentes. En este entorno, donde el éxito de la empresa controla directamente el bienestar de sus empleados de una manera muy granular, comunicarse verbalmente o por correo electrónico puede ser extremadamente efectivo, ya que existe un interés personal en la seguridad.

Todas las organizaciones deben perpetuar una cultura interna de seguridad

Básicamente, fomentar una cultura interna de seguridad es más fácil de hacer en las primeras etapas: comenzar con una mentalidad sólida centrada en la seguridad garantiza que pueda revisar, expandir y reiterar mientras se mantiene a salvo de los ataques actuales. Además, preparar sus sistemas para ataques conocidos y estar al tanto de cualquier vulnerabilidad garantiza que cualquier sistema pueda permanecer seguro durante mucho tiempo en el futuro contra ataques nuevos e imprevistos .

Al actuar sobre estos puntos, hace que su API sea un servicio más eficaz para el usuario. Un servicio inseguro puede ser funcional, pero un servicio seguro es fundamentalmente útil .

Publicar un comentario

0 Comentarios