Ecessa solutions are in integral part of your network and must meet or exceed all aspects of your corporate security requirements, policy, and reputation. This security vulnerability policy was created to explain how we are making sure that your solutions are secure and meet new and increasingly stringent testing standards. We take this responsibility seriously and look forward to your feedback. To view this document in PDF format, click here.
Ecessa’s internal team actively monitors the forums that are most relevant to our solutions. Every Ecessa product is an x86 based industrial computer running Gentoo Linux. We monitor the Gentoo Security Database (https://security.gentoo.org/) and the NIST National Vulnerability Database (https://nvd.nist.gov/home.cfm) on a monthly basis to determine what new threats are reported.
Our team also monitors relevant social media forums like Twitter, LinkedIn, Facebook, and Google+ daily for mention of any new threats or trends in our industry. New alerts are captured as a new task in Jira, our internal development environment, for our teams to review, assign, and escalate.
Ecessa has an internal, automated testing platform designed to determine if and how each security vulnerability impacts our software code base. First we port the latest security vulnerability code from the Gentoo Linux community, then we load this into our Jenkins automated test platform and execute all tests. The results from this screening output a threat report that indicates if any items affect our software, which ones, and in what way. This report is then reviewed by the development team and any relevant issues are then capture in Jira and assign for a comprehensive team review.
After the reviews are complete and the threat is verified to impact the Ecessa software code base, our team investigates a solution; this includes understanding the specifics of the threat, the impact on our features, how broadly it impacts our code and kernel, and the best way to mitigate it. Depending on the severity, impact, complexity, and risk the team will generate short and long term options for customers. These options may be limited to communications, indicating a low risk or impact, or be immediate software code updates and release to resolve critical or high risk issues. All software design information associated with the vulnerability and how to mitigate it are updated in the Jira tool.
Ecessa has several ways to communicate with our install base customers, new clients, and partner groups. Each communication path is provided to accommodate different communication needs, styles, details, and frequency. Below are the three levels of communication.
Ecessa has a philosophy of continuous improvements; we are looking to make our products, processes, and experience better each day. To accomplish this, we have a formal Voice of Customer (VoC) process that is open to all customers and partners (email@example.com). This is also used for us to improve our security vulnerability process and fine tune it for our customers’ ever changing needs. Please provide feedback at that e-mail for specifics on this policy or other Ecessa features and products – thank you.
CVE-2016-0800 – DROWN – Cross-protocol attack on TLS using SSLv2
Ecessa software versions 10.2.24, 10.4.6 and newer, all versions of 10.5, and all versions of 10.6 are not vulnerable to this issue. Both SSLv2 and SSLv3 ciphers are disabled and could not be used to exploit this vulnerability. Read more >>
CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
This vulnerability is caused by stack-based buffer overflows that can be triggered via a crafted DNS response when performing dual A/AAAA DNS queries. The vulnerability of the Ecessa device is only through DNS queries the Ecessa device itself makes, not through DNS traffic routed by the Ecessa device. Our testing has confirmed that some functions in the Ecessa software are vulnerable to this exploit and an update addressing the issue is planned for release 10.7 later this year. In the meantime it is possible to disable the ability of the Ecessa device to make DNS queries. Read more >>
GNU Bourne Again Shell (Bash) ‘Shellshock’ Vulnerability (CVE-2014-6271, CVE-2014-7169)
This vulnerability is fixed in Ecessa software versions 8.4.27, 9.2.24, 10.2.22, 10.3.13, and 10.4.3. Ecessa recommends upgrading to one of these versions as soon as possible. In the meantime if you would like to restrict access to the Ecessa devices, instructions are available. Read more >>
Let our team of experts find the right solution for you.
Fill out our simple form and we’ll take it from there.