In light of the recent news about yet another reported Zero-Day Exploit and the accompanying discussions about security, let’s touch on the topic of security audits and how Enterprise Alert can be configured to avoid or at least minimize potential security impact.
First, let’s establish what we mean by security audit. A security audit is a systematic evaluation of the entire Enterprise Alert environment including the hosting Server OS, the application, and the peripheral components it connects to. The goal of such an audit can never be to make a server invulnerable to any and all attacks, the only realistic goal can be to make attacks as hard as possible and reduce the impact as much as possible.
We here at Derdack, as the application provider, can only really deliver details on the application. The server OS and the network part are always better to be handled by the dedicated engineers of our customers, only they know the specifics of their companies’ requirements and concerns. We may touch shortly on those 2 sections where it concerns Enterprise Alert directly.
In this section, I would like to quickly address a few touching points for Enterprise Alert as they are essential for a smooth operation of Enterprise Alert. The usual issues we get reported are small problems, technically within the system owner’s responsibility, but I’d like to address them here quickly. I will not touch on system variables for the above-stated reasons.
Can the IIS splash screen be disabled?
By default, the IIS is configured to display the IIS splash screen which often gets raised as an issue since it allows attackers to conclude what kind of operating system he is dealing with. This can be easily disabled in the IIS settings for the default website.
Can Enterprise Alert be configured to not use a local system account?
By default, the set run as accounts are NT AUTHORITY\SYSTEM (for all services) and NT AUTHORITY\NETWORK SERVICE (for the IIS ApplicationPool). We recommend using an AD Account instead of the default accounts directly as part of the advanced setup. If the application is already up and running you can still change the accounts without much of an impact on the system uptime.
Must the RunAsAccount be a local administrator with LogOn permissions?
Enterprise Alert requires the local administrator User role or equivalent permissions to provide all functionalities without issues. This might be an issue that is raised in a security audit as a concern since it allows additional users to log onto this server. Usually, this issue can be mitigated by denying the user logon permissions.
In this section, I would like to cover items that might be raised by the security audit for network-related issues. Basically, this includes everything related to how Enterprise Alert is communicating with external systems. Technically this would include our Database connections as well, but I thought it more appropriate under the Application section.
Which TLS versions does Enterprise Alert support?
Enterprise Alerts fully supports TLS versions 1.0 to 1.2. the actual versions allowed can be controlled and restricted via the Operating system settings. The application is also prepared to utilize and support TLS1.3 depending on the availability within the operating system
Can Mail communication be encrypted?
With the Mail channel having multiple setup modes you will always be able to either enable SSL for receiving protocols (POP2, IMAP) and sending protocols (SMTP Server relay) or have it set as a default (o365, Exchange). Only SMTP Direct Delivery does not support a secure mode of communication and therefore should be avoided.
Can VoIP communication be encrypted?
VoIP-based communication with Enterprise Alert is in many cases still handled via insecure UDP packages but can be easily reconfigured to use TLS. This also provides for secure communication with an external VoIP provider unless communication to an external network is considered a security risk.
Is Teams IM communication encrypted?
The Microsoft Teams integration is SSL secured by default and shouldn’t come up during an audit unless communication to a system in a public network is considered a threat. If that is the case Microsoft Teams will not be an option since no on-premises alternative is available.
Can SMS/text-based communication be encrypted?
GSM Modems can be connected to Enterprise Alert either via a COM port, which can be considered a secure connection since no external access is possible or via a Telnet-based connection. As of this date, the Telnet connecting cannot be secured on the application level and will therefore appear in a security audit.
Communication with an SMSC Provider via SMPP or UCP Protocol cannot be secured on an Application Level. But it is possible to do this on a network level and is often offered by SMSC providers.
Is the communication between the mobile App and Enterprise Alert backend secure?
The Mobile App requires access to the Enterprise Alert backend either via a public access point or via a VPN tunnel (provided via an MDM solution like BES or Intune) into your network. If you utilize ADFS or Azure AD as the Identyprovider make sure the Enterprise Alert App, as well as the enterprise Alert server, have access. By default, all communication is SSL encrypted and access to the API is only granted when User credentials and a second factor is provided correctly to the API. For sending Push notifications all communication is, by design, secured via SSL.
Is the communication for 2-way connectors encrypted?
All smart connectors support secure communication via SSL encryption so any findings in that direction can easily be rectified by reconfiguring the URLs to utilize SSL encryption for access to the remote systems.
Which standard APIs can be encrypted?
The standard APIs Like REST, SOAP, HTTP POST/GET can all be secured via simple SSL encryption, the same goes for OPC U/A when a server certificate is provided.
Which standard APIs cannot be encrypted?
Unfortunately, you will also come across a couple of APIs that cannot be secured in Enterprise Alert like the SMTP server as well the SNMP trap receiver. If this poses too much of a security threat as per your security guidelines you can always disable able those interfaces.
In this section, I want to touch on anything that is related to the Enterprise Alert application itself, including application-owned security items and concerns. Like application authentication and password encryption for users and configurations.
How are database connection strings stored in Enterprise Alert?
The database connection strings are stored in cleartext within the Logman.xml as well in the web.config file for the EAPortal. To avoid SQL credentials being accessed by unauthorized users we recommend using a trusted connection instead of a SQL authentication as the connection mode.
How are passwords for access to 3rd party systems stored?
All 3rd party connectors store Passwords as encrypted values. No cleartext passwords will be stored and shared outside the application.
How are User passwords secured in Enterprise Alert?
User credentials are stored in the Enterprise Alert DB only and are encrypted similar to other credentials within Enterprise Alert. Overwriting or altering the DB stored key will render the User unable to log in. Enterprise Alert does not store any user passwords if Active Directory (AD) integration is enabled – see below.
Does Enterprise Alert offer automated User management?
Yes. Enterprise Alert provides automated User management through AD synchronization. It offers manual sync or fully automated user data updates in freely configurable intervals. Enterprise Alert however will not synchronize Passwords from Active Directory.
How are users authorized in Enterprise Alert?
Enterprise Alerts offers authorization via the build-in identity server, SSO, ADFS and Azure AD. All authentication methods can be combined with Active Directory synced users. Only for authorization through the build-in identity server locally (Enterprise Alert DB) stored passwords are required. Details for the different authentication methods can be requested via the Derdack Support team.
Does Enterprise Alert support the principle of minimum privilege?
Yes. Enterprise Alert provides 7 different user roles covering the most common use cases by default. Should the standard roles not be sufficient Enterprise Alert offers the option to alter or create new user roles enabling you to precisely control and restrict access to the application and its features. Custom user roles are an add-on feature and not available in any plan or edition.
What permissions does the application need on the database?
For the setup, therefore the creation of the main database, of Enterprise Alert, system admin privileges are required on the SQL server. If that is not possible the Enterprise Alert database can be created manually by a DBA. For the smooth operation of Enterprise Alert the account, either SQL Account (not recommended) or AD Account used by Enterprise Alert Services and ApplicationPools, needs DBowner or equal permissions.
Is there a complete list of all ports used by Enterprise Alert available?
The Derdack support team can provide documents addressing the most commonly used ports and standard ports. Please note that used ports may vary based on 3rd party application settings e.g. SQL DB ports or application web services.
Your security audit will most likely contain a lot more open items and it will go into much more detail than the questions and answers here. We gladly will sit down with you and go over the different Items and provide guidance. Enterprise Alert is designed with security and reliability in mind therefore all findings will be addressable with reasonable effort.