Paul Jodlowski wrote: >Currently OpenSSH is at 6.4p1, I have been asked by our >Network Security Team to upgrade to OpenSSH 7.4.
That's an "amusing" recommendation from your Network Security Team. Unless security patches have been backported and applied to a particular distribution of OpenSSH, OpenSSH 7.4p1 has at least three known security vulnerabilities that I see: CVE-2018-15919, CVE-2018-15473, and CVE-2017-15906. So is your Network Security Team running around and getting lots of other systems "updated" to an insecure release of OpenSSH (7.4), if those other systems don't have backported security patches? Probably. Ooops. I think you'll need to educate your colleagues (politely, diplomatically) on how security patching and backporting works. It's great they're checking -- too few organizations do even that -- but they're not checking well, and their advice is not helpful. As a general or at least widespread practice, and for decades now, software version and release numbers often refer to *functional* levels. In Db2 for z/OS, for example, this concept is now explicitly labeled "Function Level" just to remove ambiguity, e.g. "Function Level 502." In contrast, security updates and patches typically flow through the service stream, using PTF/APAR numbers (as in z/OS), fixpack or service pack indicators (e.g. "SP8"), date codes (e.g. "20190204"), or some other indicator that isn't part of the major version and release level. That's what your security teams should regularly check for, and that's how they should express their recommendations if they spot something missing. z/OS OpenSSH is a fully IBM supported component of z/OS. As long as you're on a supported release of z/OS, then backported patches for security and defects -- and sometimes functional improvements -- are available to you as part of the service stream and should be promptly applied per your preventive maintenance plan. (You should have such a plan.) As others have mentioned, you should subscribe to the IBM Z Security Portal, and you should also closely monitor at least the fixes marked HIPER. Just to drive home this point, this practice isn't peculiar to mainframes or even to servers. For instance, if you have a desktop or laptop PC running Microsoft Windows, you can be running any of several functional versions/levels of Windows that are all still Microsoft supported, with security patches available for all those supported function levels. Just looking at Windows 10, here are the versions that are still receiving security updates from Microsoft (as I write this, and without any special support contracts): Windows 10, version 1703 (Enterprise and Education editions only) Windows 10, version 1709 (Enterprise and Education editions only) Windows 10, version 1803 Windows 10, version 1809 Yes, that's four versions of the Windows 10 product alone, in multiple editions, that Microsoft is supplying with security patches through their regular (non-extended) service streams. But if you have some security team say, "You should install Windows 10, version 1803," that's bad advice as such. Version 1803 as it originally shipped has several known security defects. No, they need to check for specific security patches and, when they find something missing, provide actionable advice on which specific patches to apply. For Microsoft's products, patch identifiers start with the letters "KB" followed by a sequence of digits. So the correct advice would be something like this: "According to our latest check, System XYZ123 is missing Microsoft security patches KB012345, KB012346, and KB987653. Our preventive maintenance plan for Windows desktops and laptops requires applying all security patches within 45 days unless the operations team has granted a temporary waiver for good cause, and subject to special conditions and limitations. Please apply these missing security patches, and any others, right away. We will check again within the next few days to verify that the patches have been successfully applied." Bonus points are awarded if your security teams also check for End of Service dates (to keep on eye on whether you and others are getting too close to the end of security patch availability), review preventive maintenance plans, and make sure those plans are being followed well. Example: "Also, after you apply these patches, we recommend that you upgrade from Windows 10, version 1709, to the latest version of Windows within the next 90 days. Version 1709 will reach End of Support soon and will no longer be able to comply with our preventive maintenance plan." Unfortunately you might have to tell your security team how to do their jobs competently. Be gentle. :-) -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
