We have to enforce HTTP Strict Transport Security (HSTS) in our prod servers, which are running on webMethods 9.12, for which we have just reached to end of support, so will not get any support from SAG!
We are running our stagging environment in 10.5, where we have the provision to enforce HSTS using the below said option in extended setting:
watt.server.http.Strict-Transport-Security=max
But in webMethods 9.12, we are not seeing any such option in extended setting!
Does anybody implemented HSTS, in 9.12 or lower version, if yes what are the steps to do so?
It has been a long time since I used 9.12. First thing came up on my mind though, you tried to enable it first but couldn’t find it or did you just check the list and didn’t see it there? If it is the latter you need to enable the settings first. Its in the same page you edit the setting.
can you please check which Fixes do you have applied to your IS?
Esp. the IS Core Fix is of interest here.
I could find the following entry in the Readme for IS_9.12_Core_Fix31:
PIE-49975 (IS_9.12_Core_Fix15)
Support for security headers.
Integration server now supports the following security
headers in response headers:
Strict-Transport-Security
X-Content-Type-Options
X-XSS-Protection
Following server configuration parameters are introduced:
watt.server.http.Strict-Transport-Security
Specifies whether Integration Server includes Strict-Transport-Security header
in response headers. Value specified for this parameter is set in the response
headers of web requests to access the Integration Server Administrator. You can
set any valid value to this parameter. If the value is set to None or left
blank, then the Strict-Transport-Security header is not included in the
response headers.
For more information about valid values for this parameter, see the HTTP Strict
Transport Security (HSTS) section of Internet Engineering Task Force (IETF)
November 2012 specification.
watt.server.http.X-Content-Type-Options
Specifies whether Integration Server includes the X-Content-Type-Options header
in response headers. Value specified for this parameter is set in the response
headers of web requests to access the Integration Server Administrator. Default
value is None. You can set any valid value for this parameter. If the value is
set to None or left blank, then the X-Content-Type-Options header is not
included in the response headers.
For more information about valid values for this parameter, see the
X-Content-TypeOptions section of Fetch 31 January 2018 specification.
watt.server.http.X-XSS-Protection
Specifies whether Integration Server includes X-XSS-Protection in the response
headers. Value specified for this parameter is set in the response headers of
web requests to access Integration Server Administrator. Default value is None.
You can set any valid value for this parameter. If the value is set to None or
left blank, then the response header does not include the X-XSS-Protection.
when you have an active Extended Maintenance Agreement for 9.12 in place, sure.
Without an active Extended Maintenance Agreement, I am not sure.
But for the case, that you are planning migration from wM 9.12 to wM 10.x (10.5 is fairly old meanwhile reaching, end of support soon if it did not do so already), there might be a chance, that you can request the fix (I would prefer latest Fix 31 then) as part of your migration preparations, which recommend updating the old components to latest fixes before starting the migration.
You need to have an extended support agreement for that. 10.5 support ends this month. Your only chance is either purchase extended support agreement, or like Hogar said
I am able to see existing fixes for IS going back to 3.1.2 on Empower. For 9.12, the docs indicate IS_9.12_Core_Fix31 is “Downloadable via Software AG Update Manager”. Perhaps using SUM will work.
This is the latest fix available from SUM without extended support for 9.12. My account also has extended support but not for 9.12. It needs to be enabled by SAG. You can download all the non extended version patches as long as you have a download enabled empower account. For the fixes released after official support ended, you need extended support.
since the latest fix level is 23 and what you need is 15, you can fix your issue with fix level 23. Fixes are cumulative, so fix level 23 also includes fix level 15.
Yeah, I realized we were going off topic therefore edited my last post. Its always a good practice to keep your environment patched and up to date. That’s why it was advised to install fix level 31, same thing with fix level 23. Install the latest and carefully read the installation steps. They may (probably will, since you are way behind in fix level) involve DB updates as well.
I’m definitely off-topic but “always a good practice” is a synonym for “best practice”
IME, it is not “always” a good move to apply the latest. I say this mostly in the context of troubleshooting and when support urges “install the latest fixes and see what happens.” We avoid that because we have too many times been the victim of “does not fix the problem and now there is a new problem.” We apply fixes only when the fix explicitly mentions the symptom we’re working on.
Every environment differs a bit. And practices vary. What works well for one may be eschewed by another, for better or worse.
SoftwareAG patches usually include security patches as well. What I mean by that is to do it regularly, not as a big bang. This is also recommended by SoftwareAG
