Solutions

Tips for Securing SBM Server



ID:    S143597
Published:    17 November 2021
Updated:    29 November 2021

Product(s)

  • SBM
 

Description

How-To Secure SBM Server
 
When securing SBM, we will consider the following items.  The three items below function in the context of the SBM architecture diagram listed in the pre-installation chapter of the SBM Installation Guide located at https://help.serena.com.  It is not necessary to reduce surface area.  Reducing surface area does reduce the avenues of possible attack.  If it is not possible to keep SBM up-to-date, then reducing surface area is necessary.
 
  • Reduced surface area
  • Secure connections from the browser / client to SBM
  • Keeping SBM update to date

 

Reduced Surface Area
 
Surface area refers to various software on a given server that can be used as a way to get into that server.  An SBM server requires the following server components on a Windows Server.
 
IIS Components
For IIS, you may not need all of the IIS components listed in the Installation Guide.  For example, SBM does not need ASP.NET, Basic Authentication, Windows Authentication or WebDAV[1].  However, it is possible that your organization has customized code running on the server that uses ASP.NET.  Basic Authentication may be required by SBM if for instance, you have an SBM C++ API program running.  Windows Authentication would be necessary if you use Integrated Windows Authentication for browser single sign on.
 
Best practice suggests that you install only the components that you need.
 
You should also run an IIS Lockdown tool to remove server headers 
 
Apache Tomcat (installed with SBM)
For Tomcat, we have both HTTP, HTTPS, and an AJP port open by default.  However, you utilize IIS to proxy all connections to SBM (see the Component Servers section), you will effectively shutdown HTTP(S) ports in Tomcat, thus eliminating a possible attack vector.  In this case, all calls to Tomcat go through IIS and get proxied to Tomcat via AJP[2].  
 
A word about Tomcat and AJP.  It has been shown to be vulnerable with the Ghostcat vulnerability.  As of SBM 11.8, we automatically lock down access to AJP using a random shared secret at the time of install; see the Security section of the Configurator.  For prior versions of SBM, see KB S143121 for immediate remediation.
 
[1] See Pre-installation Checklist in SBM Installation Guide.
[2] Note that turning on IIS to proxy all connections is like installing SBM on a new server.  You will need to update environment urls in the Application Repository on the General, Target Servers and Endpoints tab.  Once these endpoints are updated any process app that utilizes them will need to be redeployed.  When changing to using IIS to proxy, you are changing Tomcat port numbers to IIS ports (80/443).  When installing SBM on a new server, you may need to update these endpoints and target servers if the server name (or DNS name) changes.
 
Secure connections from the browser / client to SBM
  • Use SSL: Make sure to use well-known SSL certificates in IIS and Tomcat (if you have HTTP ports active). 
  • Vulnerable TLS: On the HTTPS tabs in the IIS and Tomcat sections of the Configurator, you can control which versions of TLS are used.  At this time, you should be using TLSv1.2 and later.  Before disabling this for IIS, make sure that you will still have access to your server as disabling TLSv1.0 could cause RDP clients to not connect to the server.  Also, make sure that all systems / programs that interact with SBM can use TLSv1.2.
  • Use Secure Response Headers: Use SBM Configurator to enable security response headers.  Under Security > Secure Response Headers check Enable.  After you apply Configurator, do the following:
    • Open IIS Manager on the server
    • Highlight the SBM web site
    • Double click HTTP Response Headers
    • Click add. 
      Name: Content-Security-Policy. 
      Value: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: X-Permitted-Cross-Domain-Policies "none" 
 
Keeping SBM update to date
The SBM development team utilizes its own Tomcat, JDK and other third party components.  We update Tomcat and JDK with every release.  Failure to update SBM for 3 years will mean that old versions of these components are running on your servers.
 
 

Applies To

SBM 11.8+

Rate this Solution

Find Answers

Type a question or describe what you are looking for below

My Recent Searches

Welcome kb sso

Additional Assistance

  • Submit a Case Online
  • FAQs