woman placing sticky notes on wall

Remediation Best Practices

Conducting a network vulnerability scan is a critical step in the identification of security weaknesses within your network infrastructure. However, your real work begins after the scan – the remediation phase. Armed with a comprehensive report generated by a reliable scanning engine, your next move is to strategically mitigate the vulnerabilities uncovered. Effective remediation is a nuanced process, requiring a blend of technical expertise, risk assessment, and operational know-how. In this article, we’ll delve into best practices for remediation, aiming to provide you with a systematic approach to secure your network assets efficiently and effectively.

1) Keep It Simple

Simplicity is key to effective remediation. Over-complicating the process may lead to errors or inefficiencies. A simple approach can offer both robust security and operational efficiency.

Follow the Prescribed Steps
A good vulnerability scan report will include clear and reliable remediation instructions. These are often straightforward procedures vetted by security researchers. Stick to these guidelines as they are the quickest and safest routes to fix vulnerabilities.

Don’t Use a Bulldozer When a Shovel Will Do
Overly elaborate solutions can introduce new complexities, risks, and points of failure into your system. Keeping your fixes as simple as possible ensures that the process can be managed better, and work can be performed and verified more easily, reducing both time-to-fix and the potential for introducing new vulnerabilities.

It’s Sometimes OK to Not Fix It Directly
If a vulnerability is truly unexploitable due to specific configurations or conditions, apply the workaround. For example, reducing access to a vulnerable service could serve as a temporary measure, or perhaps even a long term solution. These situations require a unique risk calculus that is specific to your environment. And sometimes it’s worth a conversation around shutting down a service completely if the risk is high, remediation is costly, and the service isn’t critical. Conversations like this can help improve your operations even beyond security.

It’s Sometimes OK to Let a Vulnerability Exist
Some vulnerabilities may be acceptable depending on your unique business operations, like using self-signed certificates in a development environment. If you’re not completely confident, consult a trusted source for a second opinion.

2) Prioritize Based on Risk

Every vulnerability comes with its own set of risks and complexities, making prioritization crucial. The ultimate goal should be efficiency – the number of fixes per time – guided by overall risk.

The Important Scoring Ratio
When it comes to prioritization, weigh the potential for harm against the ease of fixing. The precise definitions of these terms are best determined by someone who understands your operations intimately. Outside consultants should take the time to learn your business, processes, and people, to help make a well-informed decision.

Three-Bucket Strategy
Divide the vulnerabilities into just three categories: 1) fix ASAP, 2) fix soon, 3) fix when convenient. Work your way through these buckets in order of (1) to (3). Within each bucket, aim to fix the items as quickly as possible, in whatever way works for you: optimize your agile velocity, fill in empty time between existing tasks/projects, throw darts to assign fixes, etc.

3) Test and Verify

You can’t assume a fix is effective until you’ve tested it, and have confidence the fix hasn’t introduced other problems.. There are multiple ways to do this:

Option 1: Re-Scan
After implementing your fixes, run another scan. If you re-scan only a subset of hosts, be sure that your fix won’t inadvertently impact other parts of the infrastructure.

Option 2: Test Manually
Use other tools along with data from the scan report to test the fixes manually. For instance, after updating SSL/TLS configurations, you can use an app like testssl.sh to ensure that deprecated protocols and ciphers are now disabled.

$ testssl.sh --quiet -p scanmy.cloud:443

Testing all IPv4 addresses (port 443): 50.18.215.94 52.9.166.110
---------------------------------------------------------------------------
 Start 2023-10-09 23:52:07        -->> 50.18.215.94:443 (scanmy.cloud) <<--

 Further IP addresses:   52.9.166.110
 rDNS (50.18.215.94):    ec2-50-18-215-94.us-west-1.compute.amazonaws.com.
 Service detected:       HTTP

 Testing protocols via sockets except NPN+ALPN 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final
 NPN/SPDY   not offered
 ALPN/HTTP2 h2, http/1.1 (offered)

4) Ask for Help

Even seasoned professionals seek advice. If you’re stuck at any stage of the remediation process, ask your scan engine vendor or security consultant for help.

ScanMy.Cloud offers unlimited support to help you understand your report and guide you through the best fixes in your unique environment. Reach out to us for more information or specialized assistance.