You've uncovered vulnerabilities in a large-scale network. How do you decide which ones to address first?

Vulnerability prioritization should be identified based on a combination of impact to my organization (Assets critical to my organization and business function as well as those hosting sensitive data ) and criticality for a specific vulnerability which can be identified not just by CVSS scores but exploitation probability , availability of an public exploit code etc. To summarize focus on assets first that have maximum impact to your business and then on vulnerabilities that may impact business continuity.

First, you sit down with a big block of cheese and start contemplating all the life choices that led you to this moment. Second, you write three notes and put them in envelopes. The first one says to blame your manager. The second one says to blame the IT department head. And the third one says “I quit.”

Consider your crown jewels and deal with the vulnerabilities affecting them. Compensating controls can be implemented where the ultimate solution may require significant financial spend (e.g. obsolescence). Resolve low hanging fruits (user rights management, permissive network rules etc). Hackers are no longer interested in writing code to crack encryption whereas they only need to get one privileged account and they have the keys to the kingdom! Drive user awareness!!!

Vulnerability management for large networks invariably faces this situation and organisations should have a clear plan for prioritisation of remediation actions . These standard practices should help organisation 1. Asset Management: Very basic security practice but often ignored or not properly managed in large networks .Without proper asset management and assigned asset value everything else would be inefficient 2. Attack Surface Management: Vulnerability in itself isn’t risk to organisation. Actual risk is a factor of exposure of the vulnerability . These 2 factors combined help identify the threat 3. Business Risk assessment: Easier said than done, takes time to mature but once in practice helps all prioritisation tasks

The order of your actions needs to be based on the criticality of your asset (e.g., network, application…) in combination with the likelihood of begin exploited (e.g., internet facing or not). The sequence of your measures can be based on predefined risk classes, for example. These are calculated based on the criticality of the assets (e.g., application, business process, or infrastructure component) in combination with the probability of an attack (e.g., with or without an internet connection). The most critical assets, which are also exposed to the outside world, could be assigned to cluster risk class 1, for example, and would have to be dealt with first. Risk classes 2 and 3 are then less important and are processed in descending order.

Une fois que la catégorisation est effective, il faudrait une réponse appropriée pour la prise en charge des plus critiques. Cela réduirait considérablement la surface des risques. Le focus mis sur les assets critiques devrait se traduire par un monitoring pousse et cela sans oublier les autres assets. Il faudrait donc mettre en ?uvre les solutions techniques à même de protéger les assets avec la veille technologique qui s'en suit pour faire face aux nouvelles menaces.

Let's lead with asset value to the business; not the bug itself. But let's be mindful that other bugs can be a lead-in to our primary assets too. As information security professionals, we need to know what we are guarding and protecting. We need to know its inherent value to the business. This may not be ours to decide. This is something we need to establish with the exec and business owners. Not all breaches are about theft of data either. There could be other reasons why assets are attacked. To determine asset value, we need to know our assets. We need to know the critical path too and from a critical asset. Seemingly irrelevant systems can sometimes be a critical path. Then we need to risk treat those assets. And identify priority.

Never forget lateral movement. Information and physical assets are almost never vulnerable in isolation. Even "low value" assets like IoT devices, printers, phones, etc., are general purpose computers, and compromising any of these can provide an opportunity for a threat agent to have insider access to your network--potentially for a long time. If you're thinking it's time to start reviewing your network segmentation plan, you're probably right!

Prioritize vulnerabilities that affect critical business operations or sensitive data. Consider the vulnerabilities that are exposed to external threats, such as those on public-facing systems or devices.

The knowledge of attack surface and the respective rating of exploitability with the corresponding impact on the continuity of operations/business is extremely necessary to be able to take right decisions towards proper threat management. This enables clear prioritisation.

Threats consist of an agent and vector. The agent may be a human or nature. Intentions are irrelevant: "judge your enemy not by his intentions, but by his capabilities." The threat vector is how the threat agent can bring force to bear against an asset. That might be over the Internet, with physical access to a building, or through an internal network. One simply threat assessment method is the RESCOR HAM method. History - what is the historical or actuarial occurrence of this threat Access - what access does the threat have (outsider, insider, privileged) Means - what means does the threat possess (individual, corporate, nation state) HAM allows you to model probability AND impact by setting H to the highest value.

Il est à date difficile de faire de la gestion des vulnérabilités sans tenir compte de la threat intelligence. Il faudrait être à l'écoute de ce qui se dit sur le contexte de la menace pour bien y remédier. La threat intelligence permet d'être UP sur le contexte de la menace et les enjeux ou autres use cases dans des environnements similaires. On peut s'inspirer de cela dans le plan de réponse à menace que l'on mettrait en ?uvre.

I will collect information with the help of public and private platforms and will create the prioritization matrix rank based on multiple factors like risk, threat, business impact, feasibility, cost impact, priority, etc.? Then prioritise vulnerability with the final score.

All assets have a threat context. All assets are subject to vulnerabilities both in the assets themselves or in the supporting information and functional architecture that surrounds them. To understand the context we need to read, learn and discover wide. We can miss a path to exploitation that never occurred to us. I would caution one area of behaviour that can lead us into danger here and that is subjective opinion on the threat context. I was mind blown by a director of engineering who said "that would never happen to us" despite us showing we could compromise them. We also need to string together different contexts that can enhance the likelihood of a threat becoming real. Real-world context moves and shifts regularly.

However, establishing a compensating mechanism to avoid exploitation of vulnerabilities that have been left open as accepted or residual risks is also significant. Therefore, having an approach that is analogous to differentiation into smaller parts to breakup the problem and integration of solutions for overall system support could help.

The cost of controls is not the end of the cost calculation. Many security controls incur a realized loss of productivity in addition. If you have 100 employees and your $100,000 security controls cost each of them an hour a week, you have reduced productivity by 2.5%. If your labor costs average $50 per hour, that's an additional $250,000 cost that often gets omitted from cost considerations. Yet the total cost of your security controls is at least $350,000, or 350% more than the price of the controls.

Caution the sales solution! In my experience, there are many ways to tackle remediating vulnerabilities and we should have all tools at our disposal including short, medium and what one would refer to as interim solutions. Yes that includes compensating controls. It is too easy to buy-in solutions. All purchases attract a burden of maintenance; particularly our time. Its easy to reach out and spend our way secure when we could have thought our way secure! Vendors prey on the fact that we need fixes. Does as failure in the effectiveness of a control mean an further solution sale to fix it? One step at a time here. Let's get the fundamentals right. Security is about consideration, modelling and architecting. Cost may or may not follow.

You can consider how the exploitation of the vulnerability could affect business operations. For example, a vulnerability that could cause system outages should be prioritized higher. So you should prioritize vulnerabilities that pose a risk to business operations and access to critical data.

Sensitive and critical data and services require robust strategies of recovery then less sensitive and critical data and services. Management of priorities in Tiers help better decisions where to alocate resources.

For patching issues I calculate an overall risk sum and then derive the weight of the risk relative to the overall risk sum. Not perfect but it’s a workable compromise or balance between frequency of the issue and severity.

So often forgotten. You can’t prioritize what you can’t fix. Fix what can be patched first based on severity then mitigate what you can’t. Applying patches is frequently a lot easier than mitigation and has a high return on investment.

Patch availability and, more importantly, patch reliability are very important. Thorough testing of patches should be performed in a way that is aligned with the business criticality of the system that needs to be patched. When patches are not available or when patch testing is not able to be completed fast enough, the organisation and Security Professionals should be well prepared with compensating and or overlapping controls in place using overlapping controls to ensure that if unpatched vulnerabilities are exploited, the resulting impact to the asset is well reduced within acceptable loss tolerances.

All actions have risk, including the actions you take to mitigate other risk. Aggressive patching is a risk in and of itself. Based on anecdotal data from my customers, Microsoft issues "breaking patches" about once every eight weeks. Yet in any non-trivial information system there are hundreds or thousands of unique vulnerabilities to be addressed. So you don't have the option not to patch - the only question is, what is the best trade-off between rapid patching and the negative effects of rapid patching. And remember: preventive controls are only one class of controls. You should be at least as focused on detecting compromises or at least anomalous behavior, and your ability to correct and recover from those incidents.

The group in charge of IT security should have regular positive communication with users and not just contact with them when there is a vulnerability or a security incident. At our organization, we have a regular IT News mailing.

User awareness is knowledge that leads to appropriate security behaviors. Knowledge itself is insufficient. Awareness requires that people behave in accordance with that knowledge.

User awareness must go far beyond simple clean desk programs, phishing campaigns, and the use of strong passwords. The end-user is the first line of defense for any company and must be trained that security and its best practices are the responsibility of all employees, not just the cyber and audit areas. Security first in everything you do in the company.

Do a risk assessment, then divide and conquer based on the outcome. Eg. you might need to priortize if its a high value asset, its placement/exposure, exploits available with an risk assessment

I suppose risk assessment is a better way to decide either opt risk based approach to protect the assets. Either applying risk based approach to the rce values or on asset classification.

Sometimes you have to consider the ease of patching. Why not patch those that can be done with quickly and easily? Then prioritize the rest based on risk and asset value. Always consider how to patch/update non-standard common apps (Adobe Reader, Java, Chrome, Zoom...). While many patch management strategies keep the core OS and desktop apps patched, they often leave out common non-core apps. For servers and core IT shared systems, keep the backup and EDR tools up to date at all times. I've found the ports used by EDR and backup software are highly targeted and often a source of compromise. Limit inbound/outbound connections for common server ports (TCP below 1024, NFS 2048) to just known servers and proxies to prevent external access.

The prioritisation will surely come for the risks with CVSS high. It will be also beneficial to consider the risks which are front facing and the exploits might easily cause a denial or service.

It's time the information security world moved to outcomes rather than solutions. Such outcomes may be the result of using solutions of course but only as part of a carefully architected suite. We must drop the old world of thinking that we can wrap our arms around the large enterprise. Even if we did, our exposure is also in third party supply chain risk. Most important - we cannot patch ourselves secure. We need to think our way towards effective risk management and ensure that we think in terms of information flow rather than features. Its time cyber was shaken up and we got out of our own way of trying to spend our way secure. There is still huge space for vendors, but we need to implement crisp and effective thinking first.