This is a true story.

I was sitting at breakfast the other day with my wife. As we waited for our food to arrive, four people were sitting at a socially distanced table. They were discussing how they have to restart their computers every month because of “something Microsoft does that makes me restart.” The conversation continued:

Diner 1: “That’s why I only use a capital ‘A’ as my password on that machine.

Diner 2: “Mine is always ‘1234’”

Diner 3: “Same thing with the internet. I use the same password everywhere.”

They continued their conversation with a host of other revealing information. I was waiting for them to start reciting their credit card numbers out loud. I am not sure why they were all loudly broadcasting this at a public place. I would like to think that they were FBI agents and that they were testing me to see if I would take their bait. But I am certain that is not the case.

I started to stand up, and my wife stopped me and said “Don’t you dare go over there and educate them.”

I said “But this is ridiculous. They need to know!”

My wife said, “You’re being officious.”

Me: “No, I am not. I am not acting in any official capacity. Besides, I don’t even have my CISSP card with me.”

My Wife: “No, you knucklehead. Officious means that you are offering your services where they are neither wanted or needed.”

Me: “How is it not needed? They clearly need my advice. I bet that ‘1234’ is also the code for the keyless entry system on that guy’s car!”

My Wife continued: “How do you think they will feel if you go over there and start teaching them about cybersecurity when they are just trying to make breakfast conversation? Besides, you are probably the only person in the room who would really know what to do with the information they are trumpeting.”

Did I mention how astute (and brutally honest) my wife can be at times?

However, she was right.

As a cybersecurity professional, how would you have handled this situation? Should we approach unsuspecting people to teach them how to better protect their information such a passwords, or should our educational efforts be confined to the forced annual security awareness trainings and phishing exercises that we conduct?

We are great evangelists, but we are poor at public relations. We need a better marketing strategy, so here is a proposal that you can use now to raise awareness on a broader scale.

Contact your favorite local media outlet. Whether it is a news publication or a television news outlet, look up their contact information and let them know that October is National Cyber Security Awareness Month, and that you are confident that if they run a piece about cybersecurity, it would be a great benefit to their audience. Perhaps you could offer to write something for them yourself or offer some advice to them if they do not have a subject matter expert on their staff. Maybe this could result in a new career path for you. Whatever it amounts to, your contribution to the community can only help.

Happy October!

El panorama global de ciber-amenazas se encuentra en constante evolución lo cual resalta la necesidad emergente de que las organizaciones fortalezcan su capacidad para identificar, analizar y evaluar los riesgos tecnológicos antes de que evolucionen a incidentes de seguridad completamente. Cuando se trata de mitigar el riesgo, los términos “gestión de parches” y “gestión de vulnerabilidades” se usan como si fueran intercambiables. Cuando en realidad aplicar parches es una de las muchas formas de mitigar los riesgos en ciber-seguridad.

La decisión de desplegar, desinstalar o dejar pasar un parche específico cae dentro de un contexto más amplio de la gestión de vulnerabilidades. Definida como “una práctica de seguridad diseñada específicamente para mitigar o prevenir de manera proactiva la explotación de las vulnerabilidades de TI”, la gestión de vulnerabilidades no es únicamente escaneo y parchado. Es una función holística que tiene la visión proactiva de administrar la, en ocasiones desalentadora, tarea de abordar las vulnerabilidades identificadas en los dispositivos de hardware y software implementados. En pocas palabras, la gestión de vulnerabilidades es un concepto más amplio que envuelve la gestión de parches.

La administración de vulnerabilidades es más que solo recibir alertas cuando su infraestructura necesita un parche aplicado. La gestión de vulnerabilidades consiste en tomar decisiones informadas y priorizar adecuadamente qué vulnerabilidades mitigar y cómo. Esto se logra al incorporar agentes internos para telemetría en todos los sistemas de interés, así como controles externos para inteligencia de amenazas de todas las fuentes.

La gestión de vulnerabilidades se respalda por una inteligencia de amenazas que proporciona una comprensión más profunda de cómo y por qué los atacantes están utilizando ciertas vulnerabilidades e ignorando otras. La inteligencia sobre la explotabilidad de la vulnerabilidad prepara a su organización para lograr el equilibrio correcto entre parchear sistemas vulnerables e interrumpir las operaciones comerciales. Un enfoque basado en el riesgo de las amenazas hace que sea mucho más fácil comunicar el peligro de una vulnerabilidad a sus equipos desde seguridad y operaciones hasta gerentes senior e incluso a el consejo. Este nivel de visibilidad en la lógica detrás de las decisiones tomadas en torno a las vulnerabilidades aumentará la confianza en el equipo de seguridad en toda su organización y ayudará a evitar que ocurran fugas de datos, como la que sufrió Equifax.

Etapas de maduración para un programa de gestión de vulnerabilidades

Hay cuatro etapas principales en cualquier programa eficaz de gestión de vulnerabilidades:

1. El proceso que determina la criticidad del activo, los propietarios de los activos y la frecuencia de escaneo, así como también establecer los plazos para la remediación.
2. El descubrimiento y el inventario de activos en la red.
3. El descubrimiento de vulnerabilidades en los activos descubiertos.
4. La notificación y reparación de vulnerabilidades descubiertas.

La primera etapa se enfoca en construir un proceso que sea medible y repetible. Las etapas dos a cuatro se centran en ejecutar el proceso con énfasis en la mejora continua.

Examinemos brevemente cada etapa y cómo Tripwire puede ayudarlo.

ETAPA 1: PROCESO DE ESCANEO DE VULNERABILIDAD

La primera etapa se puede dividir en cuatro pasos.

El primer paso es identificar la criticidad de los activos en la organización. No se puede crear un programa eficaz de gestión de riesgos si no se determina qué activos hay que proteger. Estos incluyen sistemas informáticos, dispositivos de almacenamiento, redes, tipo de datos y sistemas de terceros en la red de la organización. Los activos deben clasificarse y priorizarse en función de su riesgo real e inherente para la organización. Se deben considerar muchos aspectos al desarrollar el riesgo inherente de un activo, como la conexión física o lógica a activos clasificados más altos, el acceso de usuarios y la disponibilidad del sistema. Los activos con mayor criticidad tendrán mayor prioridad que los activos con menor criticidad. Sin embargo, la remediación de activos con menor criticidad no debe ignorarse ni posponerse indefinidamente. Todos los activos contribuyen al riesgo organizacional general, y el esfuerzo de remediación siempre debe basarse en minimizar el riesgo general.

El segundo paso es identificar a los propietarios de cada sistema. Los propietarios del sistema son responsables del activo, su riesgo asociado y la responsabilidad si ese activo se ve comprometido. La rendición de cuentas es un factor determinante para el éxito final del programa de gestión de vulnerabilidades. Los activos y vulnerabilidades sin propietario quedarán olvidados y se convertirán en un riesgo no identificado para la organización.

El tercer paso es establecer la frecuencia de escaneo. El Centro para la Seguridad de Internet en su CIS Control 3 “Gestión continua de vulnerabilidades” recomienda que una organización “utilice una herramienta actualizada de escaneo de vulnerabilidades para escanear automáticamente todos los sistemas en la red semanalmente o con mayor frecuencia para identificar todas las vulnerabilidades potenciales en los sistemas de la organización “. El escaneo frecuente permite a los propietarios de los activos rastrear el progreso de la remediación, identificar nuevos riesgos y volver a priorizar la remediación de vulnerabilidades basadas en inteligencia actualizada. Como límite externo, el escaneo de vulnerabilidades debe ocurrir al menos mensualmente.

El cuarto paso es establecer y documentar plazos y umbrales para la remediación. Los plazos de remediación deben tener en cuenta la gravedad del impacto de una vulnerabilidad al ser explotada y darse a conocer a toda la organización. Las vulnerabilidades con el mayor impacto deben remediarse de inmediato. El programa también debe atender las excepciones en caso de que una vulnerabilidad no se pueda remediar dentro del plazo aprobado, documentando el riesgo aceptado junto con un plan de acción para remediar la vulnerabilidad en una fecha determinada.

ETAPA 2: DESCUBRIMIENTO DE ACTIVOS E INVENTARIO

El descubrimiento de activos y el inventario son los controles uno y dos de CIS. Estas son las bases de cualquier programa de seguridad. No puedes proteger lo que no conoces. El propósito de CIS Control 1 es “Administrar (inventariar, rastrear y corregir) activamente todos los dispositivos de hardware en la red para que solo los dispositivos autorizados tengan acceso, y se encuentren dispositivos no autorizados y no administrados y se les impida acceder”. Además, el Control 2 de CIS resalta la necesidad de “Administrar activamente (inventariar, rastrear y corregir) todo el software en la red para que solo el software autorizado esté instalado y pueda ejecutarse, y que el software no autorizado y no administrado se encuentre y se evite su instalación o ejecución. ”

Estos dos controles van de la mano, ya que los atacantes siempre intentan identificar sistemas que sean fácilmente explotables para ingresar a la red de una organización, como Shadow IT. Sin el descubrimiento apropiado de activos y el control de acceso a la red, este tipo de dispositivos pueden proporcionar una sencilla puerta de enlace para un atacante a la red corporativa. Una vez que ingresan, pueden aprovechar el control que han obtenido para atacar otros sistemas e infiltrarse aún más en la red. Estar al tanto de lo que hay en la red le permite al equipo de seguridad de la información proteger mejor los sistemas y proporcionar orientación a los propietarios de sistemas para reducir el riesgo que representan sus activos.

ETAPA 3: DETECCIÓN DE VULNERABILIDAD

Una vez que se identifican todos los activos en la red, el siguiente paso es identificar el riesgo por vulnerabilidad de cada dispositivo. El método recomendado para el escaneo de vulnerabilidades es a través de credenciales. Esto permite una mayor precisión para determinar el riesgo existente de la organización. Luego, de acuerdo a lo encontrado por la etapa de descubrimiento, se pueden correr firmas de vulnerabilidades específicas por sistema operativo encontrado.

 ETAPA 4: INFORMES Y REMEDIACIÓN

Una vez que se completa el escaneo de vulnerabilidades, se asigna un puntaje a cada vulnerabilidad utilizando un algoritmo exponencial basado en las habilidades requeridas para explotar la vulnerabilidad, los privilegios obtenidos tras una explotación exitosa y la edad de la vulnerabilidad. Cuanto más fácil sea explotar la vulnerabilidad y cuanto mayor sea el privilegio obtenido, mayor será el puntaje de riesgo. Además de esto, a medida que aumenta la edad de la vulnerabilidad, también aumenta la puntuación de la vulnerabilidad.

La primera métrica que debe obtenerse es la puntuación de riesgo promedio general como referencia para la organización. Con base en esta métrica, las organizaciones deberían comenzar a apuntar a una tasa de reducción de riesgo del 20-25% anual. La siguiente métrica es el puntaje de riesgo promedio por propietario. De manera similar al objetivo para la organización en general, cada propietario debe enfocarse en reducir su puntaje de riesgo promedio en un 10% a 25% año tras año hasta que estén por debajo del umbral aceptado para la organización. Para la implementación exitosa del programa el equipo ejecutivo podría premiar a los propietarios de activos con los puntajes más bajos.

Los datos de vulnerabilidad empíricos para delinear qué vulnerabilidades deben corregirse junto con instrucciones de cómo llevar a cabo la corrección permiten a los propietarios del sistema priorizar sus esfuerzos con un enfoque en las vulnerabilidades que reducirán al máximo el riesgo organizacional general. A medida que se ejecutan nuevos escaneos de vulnerabilidad, las métricas, como las que ofrece CIS, se pueden usar para mostrar un análisis de las tendencias del riesgo y el progreso de la corrección.

La clave es mostrar el progreso mes a mes, trimestre a trimestre y año a año. Los puntajes de riesgo de vulnerabilidad y el tiempo de reparación deberían disminuir a medida que los equipos se familiaricen más con el proceso y se eduquen más sobre los riesgos que plantean los atacantes.

Cómo ayuda Tripwire

La gestión de vulnerabilidades y riesgos es un proceso continuo, y debe adaptarse continuamente al panorama cambiante de amenazas de ciberseguridad. Por lo tanto, el proceso debe revisarse periódicamente y el personal debe mantenerse actualizado con las últimas amenazas y tendencias. Desarrollo continuo para el personal, los procesos y la tecnología asegurarán el éxito del programa de gestión de riesgos y vulnerabilidad empresarial.

Si desea tener un programa de gestión de vulnerabilidades, Tripwire IP360 es la solución que estaba buscando. Tripwire IP360 descubre todos los activos dentro de su organización y las aplicaciones siendo ejecutadas en ellos antes de realizar un análisis de vulnerabilidad. Los análisis de vulnerabilidad con credenciales proporcionan un análisis detallado y también identifican vulnerabilidades que un atacante vería en un análisis de vulnerabilidades externo no autenticado. Finalmente, Tripwire IP360 proporciona una puntuación de riesgo significativa y clasifica las vulnerabilidades numéricamente en función del impacto, la facilidad de explotación y la antigüedad.

Puede obtener más información sobre cómo crear un programa maduro de gestión de vulnerabilidades leyendo este documento técnico.

Este blog se publicó originalmente en inglés aquí: https://ift.tt/2MXssT9

Cybersecurity Supply Chain Risk Management (C-SCRM) deals with more than protecting an organization from cyber-attacks on third parties. It also addresses third parties to those third parties (known as “fourth parties”). Further still, a vendor to your vendor’s vendor is a fifth party, then a sixth party, etc. Your SCRM should involve knowledge of how far, complex and even convoluted your supply chain is. Then measure this complexity with your risk appetite.

(You might wonder, “What happened to the second-party?” Those are your members and customers.)

What really makes the difference between C-SCRM and any other kind of technical vulnerability management (VM)? There really isn’t much difference in the tactics used. What becomes essential in C-SCRM is that the technical aspect of VM gets done and gets done well. With C-SCRM, managing and monitoring aren’t optional. If a company has a relatively small number of third-party vendors, then there may not be too much more to do than a typical VM program. But if one has a multitude of third parties, then it’s inevitable that the total number of suppliers increases exponentially. This factor immediately leads to numerous vulnerabilities for which your company is responsible to manage. While it may seem unfair that you have to manage those vulnerabilities, in the end, your customers are relying on you to provide a solid product and service.

Digital transformation imposes and increases third-party risk. Two primary threats in the increasingly outsourced digital economy are:

1. Lack of full control
2. Lack of full visibility

Is there any data to show that third-parties are really such a serious risk? According to Verizon’s 2019 Insider Threat Report’s “5 Types of Insider Threats,” the 5th type of insider threat is the Feckless Third-Party, described as follows: “Business partners who compromise security through negligence, misuse, or malicious access to or use of an asset.”

C-SCRM is based on knowledge. As such, the DIKW model is a handy overview here. “D” is for “Data,” “I” is for “Information,” “K” is for “Knowledge,” and “W” is for “Wisdom.” More specifically, input for C-SCRM is found in the D-I-K tiers.

With C-SCRM, the aspects of DIK can be addressed with technologies (especially those leveraging AI) such as firewalls, spam filtering, EDR and DLP. The “Wisdom” tier is relegated to experienced personnel who determine what to do with all of that DIK. Technology can send plenty of bits and bytes to the governance committee, but it can’t decide traits like a company’s risk appetite, product direction or security budget.

How does one decide how to proceed with all of that info?

Think of the visual arts. A vital aspect of visual art that makes it viable art is boundaries; there has to be some kind of border. It could be comic book panels, the borders of the canvas, the limits of the monitor, a scene in a film or a character’s silhouette.

When creating C-SCRM programs, there have to be borders. No organization can possibly handle the entirety of the intel that’s available. Even if it could, not all of it matters. This is why even the most complex VM tools filter data.

With any C-SCRM, you want to know what information is coming in and going out. With the supply chain, especially digital, you now have an exponential amount of data being transferred. As a sample, any and every time a department buys new software for that department, there’s one if not multiple new threat vectors. Unless that vendor and the software has been vetted, then that purchase has created a blind spot.

Not surprisingly, there are plenty of aspects to consider in C-SCRM. Here’s how one might outline them:

• Inventory
  1. All assets – hardware, software, personnel, contracts
     1. This is a usual project for any company that hopes to maintain good security, but here the focus is on where these assets interact with third parties. Hardware and software are pretty straightforward, but personnel and contracts might not be. An example of these categories is knowing where one company shares confidential customer or corporate information with all other companies. Where that data is shared, can the security of those repositories be verified?
  2. Timing of inventory updating
     1. Do you need to scan for installs and be alerted to installs once a week? Once a day? Immediately? This needs to be done to ensure that software assets aren’t connecting to unapproved sources, which risks opening more holes in your firewall and weakening your security.

• Impact Analysis
  1. What technical threats are truly threats to the organization?
     1. Realistic Threats & Risks
        • There are innumerable threats every hour, but what threats really apply to you? A foreign state might be on the list of threats, but is the chance of that threat materializing as great as the chance that an RDP/3389 port (opened for your contractor) would be noticed on a Shodan scan and exploited?
     2. Here’s an example: in Q2 2020, the risk from personnel working from home hit an all-time high, whereas in Q1, your company might have had minimal risk from remote work. Changes can happen quickly and en masse, so be ready to analyze those changes for the ways that they can negatively affect your security.
        • As a reminder of changing one’s risk appetite, while the risks with work-from-home increased, for many companies, the advantages increased just as much. Changes aren’t all bad; they need to be approached from other angles than just straight-up security threats.
     3. Categorize and Classify
        1. C-SCRM would take account of all of the vendors, categorize them as to whether they pose a technical threat, classify those which are – at the very least – critical in severity, determine which suppliers further down the chain need to be verified for their security posture and begin the process of security attestation reviewing and reporting.

The Intelligence step is where you take all of the threats that could materialize from and through your suppliers and cull those possibilities to produce better data sets that would produce actionable steps.

Unless you are certified in app/web testing and the supplier has paid for your testing services, the likelihood of being able to directly test a vendor’s apps and sites is zero. So, feel free to ask for any kind of third-party testing results for your X-party suppliers. If acceptable to the requesting organization, the supplier’s internal ISMS documents or program can be requested in lieu of third-party testing.

There are many paid and free tools available for gathering threat intel. While your supplier may not have direct threats that can be monitored, there are likely extant threats – such as vulnerabilities in the codebase that are outsourced by the company responsible for creating your software – that affect that company. Those threats can be monitored.

Integration is taking the garnered intelligence and putting it into place in your network. In exploring the tools found in the Intelligence phase, the more you can streamline the integration of that data into your environment, the better.

Monitoring, alerting & reporting are in this stage. Each product is different, so in vetting the product, especially for vital data (e.g., Critical alerts of anomalous activity), ensure that it will actually produce email or text alerts.

Maturing the processes is always on the project board. In Year One, it might suffice to use a spreadsheet to keep track of assets by using a service on lower-end server to scan your network. But Year Two may require a more robust software tool for asset tracking and a higher-end server for real-time scanning.

Alternatively, your internal alert ratings could change. What was Low priority last year might now be High and need to re-labeling.

Correction is part of this phase. Are there new suppliers? Are there former vendors that no longer need any kind of access but for which there’s still an IP address opening on your firewall and servers? Correction can be addressed with recurring projects. Set-it-and-forget-it makes it possible.

Before embarking on a C-SCRM plan, have an IR plan. Bad things happen at any time, and they don’t wait until programs are fully developed. If a successful attack were to occur, it’s likely that it will happen before the program is completed because the unfinished program has more security holes in it than a completed one.

What are your communication channels (e.g., call tree)? Who will you contact if the app you just installed company-wide has a bug? Which person at Company X will you call if there’s malicious traffic flowing from that supplier? Who is your contact for the worst-case scenario of a breach in that supplier?

Test the People, Processes and Technologies involved in the IRP. How and when will you practice your IR plan?

After testing, produce the results according to your BC, IR and DR policies. In responding to incidents, it’s important to focus on defense, not offense. (NOTE: Unless you have some special authority, “hacking back” is not a valid response.)

Each of these steps may end up becoming quite complex, which is precisely why C-SCRM is so difficult. The concepts are quite commonsense, but the tremendous amount of detail and the lack of a one-size-fits-all approach makes it appear onerous.

What is to be done if your company is part of someone’s supply chain? Ask yourself, “What are the chinks in my armor?” Maybe the armor imagery isn’t your thing, but what will help your program is making it personal. Maybe you like basketball or football and want to think of it as setting up a defensive move. Or you’re in finance and think of Red Flag warnings. In looking for how to better protect your company’s network, it may help to start calling it “your” network and see, as objectively as possible, where your network has holes.

Depending on a company’s criticality in the chain, customers may ask for your vulnerability assessment results. These are typically considered “for internal use only.” By not sharing them, you’re not avoiding being honest or vulnerable (see what I did there), but there are many ways that those reports can be misunderstood. An example of misunderstanding can occur when internal corporate vulnerability scans assess both Prod and Test servers. If the reports reflect both, then the Test environment is likely filled with holes on purpose. Internal staff will understand the results, but external parties will not and may well consider the team lax in their duties – even if they are on top of the situations. If vulnerability assessments aren’t shareable, at minimum have a professional response ready for those inquiries and provide some metrics by which prospects and risk assessors can measure the internal security of the product or service to which they’re uploading their data.

Here’s a recently developed tool from NIST that can help as you develop and mature your C-SCRM.

About the Author: Ross Moore is the Cyber Security Support Analyst with Passageways. He was Co-lead on SOC 2 Type 1 implementation and Lead on SOC 2 Type 2 implementation, facilitated the company’s BCP/DR TTX, and is a HIPAA Security Officer. Over the course of his 20 year IT career, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP and CompTIA’s Security + certifications, a B.S. in Cyber Security and Information Assurance from WGU, and a B.A. in Bible/Counseling from Johnson University.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.

More From Ross Moore about Supply Chain Risk Management

1. Supply Chain Risk Management – What You Need to Know to Build a Successful SCRM Program