If you’re a Citrix customer and you want to keep your customer or employee personal information secure, chances are that you’ve had some exposure to one of the many automated vulnerability scanning tools that can be purchased for use today.
This is the first in a series of articles designed to help you understand the results and how to investigate the findings.
These tools, such as Nessus, Nexpose, and Retina can help to provide a level of assurance that your corporate IT infrastructure is deployed securely, typically by port-scanning the machines it identifies on a corporate network and using the responses it receives to make educated guesses on the potential vulnerabilities that may be present on those computers. With most of these tools, login credentials can be provided to allow the tool to remotely log in to the machines and carry out further analysis, looking for software versions that are installed, services and processes that are running and hotfixes that have been applied.
If you’re in finance or handle customer credit card information, it is likely you will require a pass from a scanner that has been approved by the Payment Card Industry’s Data Security Standards (PCI-DSS) before your deployment can be used with customer data. Alternatively, you could be using a scanner as a means of accrediting a system—something common in Federal or Defense markets—and may require a clean pass before the system can be put into production. Any failures before the production roll out, or in subsequent, periodic scans, and the system accreditation may be withdrawn.
So, what is the point of this blog post?
The prevalence of these tools, their ease of use and (despite this simplicity) their ability to generate complex and extensive reports means that there is the potential for confusion on which findings may actually mean there is a valid threat to your system. Knowing how to interpret these reports will mean you’ll get a better idea of the potential risks to your infrastructure from the issues that have been picked up and will mean that the genuine items can be resolved more effectively.
Let’s talk about triage.
On receiving your scan report, your first step should be for you to triage the results. Before doing this, I recommend that you gather together all the information about your infrastructure that could have a bearing on the scan. That will mean correlating IP addresses or domain names to the machines scanned and obtaining the details on the specific machines and their functions. Information like the machines’ operating systems, the installed software, versions and whether hotfixes have been applied will have a bearing on the scan, so note this down. A machine inventory can help with this process, but it is possible that the information will be out of date, so make sure that the manual steps are taken. As a bonus, the new information can then be fed back into your inventory.
With this information in hand, it should be possible to make an initial pass of the findings and eliminate any obvious false positives.
What is a false positive?
Earlier, I spoke about the tools making educated guesses based on the information they gather during a scan. While this information can be useful in some situations, it’s also possible that this information could be incorrect and the tool is reporting something that is not really there. A good example here would be a tool reporting a linux kernel vulnerability when run against a Windows Server. So, step one of triage is to a quick sanity check to rule out the obvious false positives.
Once the obvious false positives are discounted, step two is to identify which results apply to which parts of your infrastructure. Most scanners will provide both a summary of the issue found and a more detailed report giving technical information and this will enable you to find out which application or component is being highlighted. With some of the results, it should be relatively easy to make a decision on whether the finding affects a product, for example if the scan was run against a Citrix NetScaler management IP, then it is reasonably safe to assume that the findings relate to NetScaler. For other products, it may not be so easy to identify what the finding relates to, such as for products running on existing operating system.
Step three is to check whether vendors have released fixes for any of the issues picked up by the scanner. For Citrix products, you can find all our existing security bulletins in one place: https://support.citrix.com/securitybulletins. I recommend that you visit this portal and review the bulletins to make sure that you are following our guidance on fixes for security bulletins. If you want to be kept up to date with new releases or updates to existing bulletins, you can register for e-mail alerts on the same page. Most other vendors should provide similar resources and I recommend that you keep up to date with their guidance as well. Once you have the latest patches and fixes installed, re-run the scan and you should see these issues go away, which is a useful way to check that the fixes have been deployed.
Step four is to check configuration. Patches and hotfixes can address specific issues, but ensuring that your infrastructure is securely configured provides a more general reduction is risk, for example by enabling TLS across your infrastructure or reviewing which ciphers are available for use. You can also review any configuration files against both Citrix recommendations and industry best practice to ensure that both the applications and the underlying operating systems are correctly configured and locked down. Further information and guidance for Citrix products is available on our website at the following address: https://www.citrix.com/security.
What next?
Once the obvious false positives have been discounted and the less obvious results triaged, you should be left with a smaller subset of findings that require further investigation. Indeed, it is likely that the steps above will eliminate or resolve all of the issues found by the tool. If there are any issues left that are not cleared up by steps one to four, then it is now time to seek assistance from the vendors of the impacted components.
For Citrix products, your first point of contact should be to your normal Citrix Support representative, either via a TRM or by raising a Support ticket. Let them know that the issues were identified by an automated scanning tool and that you need assistance investigating the remaining issues in the report. Make sure that you include as much of the information that you gathered as part of triage. If necessary, prioritise the remaining items so that your Support contact knows which items will provide the most benefit to you quickest.
Look out for further articles in this series, giving more tips on how to interpret automated scan reports and dig deeper into the results. If you need more information on the best way to contact Citrix with a security-related question, you can find it on our website in the following article: CTX081743
