Communication to Identity providers like Active Directory, LDAP and SAP was covered in part 1, and securing the web tier was covered in part 2.
Now let's look at the actually BI servers, like the Central Management Server, (CMS), File repository Server (FRS) and others.
We'll look at port restrictions, potential firewall setups, SSL/TLS and other configuration switches.
FIPS 140-2
By now you may have read about the -fips parameter on the SIA. FIPS stands for Federal Information Processing Standard. I cover this mode more in my data security blog. The quick summary is that BI4 uses FIPS certified encryption libraries to perform its encryption.
Turning this switch on (add a "-fips" on the SIA command line), prevents usage of older clients and disables some older functionality. If you do not have any xir3 clients or custom applications running against your BI4 system, there is no reason NOT to have this switch on. Do expect this to become the default in upcoming maintenance releases, where you will instead need a special switch to turn ON old functionality, but by default, and xir3 or older client will NOT be able to connect.
It is not just about enforcing stronger BI4 security. By disabling older functionality, you again reduce the attack surface, where a server not accepting calls based on older functionality will be harder to exploit. If you're familiar with the POODLE attack, you'll know for example that the latest recommendation is to outright disable SSLv3 protocols and use strictly TLS. A similar concept applies here .
Minimum Privileges
Creating a special locked down user to run BOE can be worthwhile. The built in windows system account is actually quite powerful
The rights required on the local computer where the SIA is running are as follows:
-Logon As a Service.
-Read/Write to HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite XI 4.0
-Read/Write to Install directory (specifically Write access to the Log Locations).
The important part here is the account should NOT be an Administrator on the local machine.
Server to Server channel Encryption (CORBA SSL)
The how to steps for server to server communication encryption are detailed well in the BI4 admin guide, as well as in this online wiki for unix
The client configuration is detailed in sap note https://i7p.wdf.sap.corp/sap/support/notes/1642329
How much of a performance hit can you expect? It really depends on many factors, there is often a tradeoff in performance for security, but a rough guidance can be a 10%-20% impact based on what I have seen so far.
File Repository Server
This is an important server to protect, because it contains your report content on the file system. If the reports are saved as PDF or saved with data, that makes them very valuable to attackers. There are a few additional things you can do to protect the content.
-Secure the FRS OS folders so that only the account that the SIA hosting the FRS can access
-Use file level encryption. This can protect the content from unauthorized access through the local machine.
-Virus Scanning. For large deployments and heavy usage, this can be a big bottleneck on the I/O to the point that performance visibly suffers. For performance reasons, you may consider running scheduled scans in "off hours" rather than real time virus scanning. By far, real time virus scan is more secure, but you can further mitigate with locking down what users can upload.
-Limit content types from being uploaded:
Rather than granting the generic "Add Objects" right, you can actually lock it down to content types, and only permit CR, Webi etc types of documents. This will prevent a user from uploading a bad executable or batch file, that another user then downloads and executes on their own machine. Of course one would hope that end users would know better, but prevention is your best defense.
Default Accounts
All BI installations start with a default "Administrator" account. For a potential attacker, that is one known piece of information for trying a brute force attack. Enabling auto lockout for failed attempts will certainly help mitigate this, however another thing you can do is to rename the default account. Instead of "Administrator" use your own naming such as <Company>_BI_Admin. For example SAP_BI_Admin.
Stale Accounts
Have people left the company? Maybe never even logged in? The less accounts you have, the less chance of an old stale password falling into the wrong hands, or accounts being misused. It is again about reducing attack surface.
The following query, which you can run using the AdminTools console, will return to you a list of users by the last logon time.
SELECT SI_NAME, SI_LASTLOGONTIME FROM CI_SYSTEMOBJECTS WHERE SI_KIND = 'user' ORDER BY SI_LASTLOGONTIME DESC
Below is a stripped down sample output. While these users may have content in personal folders you don't want to lose, consider disabling the accounts.
Ports, Firewalls
Firewalls help you reduce the attack surface. In the simplest, happiest (from a security standpoint) workflow, all your users are web users, and will only be connecting to BI Launchpad. In this case, the BI servers can be fire-walled away from the end users. However chances are you also have thick clients connecting. In this case, make sure the thick clients are limited to connecting from a trusted network zone, if networks are partitioned.
You can bind servers to a specific port in the CMC.
The CMS has both the the name server and request port that you can configure:
By setting a specific range of ports to use or binding to specific ports, you can then use a firewall to further lock down and reduce the attack surface of your servers.
Keep in mind that thick clients must be able to communicate with the CMS, as well as the Input and Output file repository server. There is a fairly complete overview of the server port communication described in the administration guide, section 8.14.2
Your IT may have also put your database layer into a separate network zone, inaccessible to regular workstations. Yes, IT is making your life difficult, but for a good reason in the classical 3 tier architecture. Clients can and should (for security purposes) connect through the BI platform which in turn connects to the database layer. This extra hop makes it more difficult for a connection to abuse or attack the database layer directly, where all your valuable data resides.
Database Encryption
The communication between the BI processing servers and the actual database can, and from a security standpoint should be encrypted. To help you decide, a threat model should be done. How sensitive is the data, how isolated are the data sources are just two considerations. Generally, one should assume that their network HAS been compromised, and build out a security in depth approach. It is quite easy for someone in your company to fall for a phishing attack. You can set database encryption at the driver level, below being an example of a sql server driver:
CMS DB Encryption
The CMS repository does not store any data in your reports, however it can store sensitive metadata such as connection information. This is automatically encrypted using a two key mechanism as part of the BI4 build in encryption. Again, this is described in my encryption & data security blog.
Using your database vendor's built in database encryption to encrypt the whole data may actually be overkill here, and is actually not something that I would strongly recommend as being necessary, but certainly a valuable 'security in depth' principle option. The advantage of selectively encrypting content, the way the BI4 process does is that you do not suffer performance hits on non essential data encryption, such as the metadata associated with a report's layout.
Temporary Files
During document creation and processing, temporary files will be created, and they may contain some data. Have a look at your temporary folders, and lock these down to the process that the SIA service hosting these servers is running under. See below for the Crystal Reports processing server as an example.
Placeholders like "%DefaultDataDir% and others are defined under the placeholders tab of your Server Properties.
%DefaultDataDir% defaults to "/SAP BusinessObjects Enterprise XI 4.0/Data/"
Stay up to date - Part 4 - security patch awareness.
- SAP Managed Tags:
5 Comments
