Security Advisor

Security Advisor

To assist system managers in securing an InterSystems IRIS system, the InterSystems IRIS Management Portal includes a tool called the Security Advisor. This is a web page that shows current information related to security in the system configuration. It recommends changes or areas for review, and provides links to other pages in the Management Portal so that you can make the recommended changes.

There are some general features in the Security Advisor:

• Details button — Each section has a Details button. Selecting this button displays the page for managing that aspect of InterSystems IRIS regulated by the section.

• Name button — Each named item in each section is a link. Selecting one of these items displays the page for managing that item.

• Ignore check box — Each named item in each section has an associated Ignore check box. If you have determined that the item does not apply to your specific requirements, selecting this box grays out the line for the specified item. The line does not appear if InterSystems IRIS is set up according to the Security Advisor’s recommendations, whether or not the Ignore check box is selected.

Auditing

This section displays recommendations on auditing itself and on particular audit events:

• Auditing should be enabled — Auditing creates a record that can provide forensic information after any notable or unusual system events.

• Auditing for this event type should be enabled — Auditing particular events can provide more specific information about various topics. Specifically, since the events noted when not enabled are:

  • The DirectMode event — Auditing this event can provide information about connections to InterSystems IRIS that give users significant privileges.

  • The Login event — Auditing this event can provide information questionable logins.

  • The LoginFailure event — Auditing this event can provide information about attempts to gain inappropriate access to the system.

Services

This section displays recommendations on InterSystems services. For each service, depending on its settings, the Security Advisor may address any of the following issues:

• Ability to set % globals should be turned off — Since % globals often hold system information, allowing users to manipulate these globals can result in serious, pervasive, and unpredictable effects.

• Unauthenticated should be off — Unauthenticated connections give all users, including the unidentified UnknownUser account, unregulated access to InterSystems IRIS through the service.

• Service should be disabled unless required — Access through any service monitored by the Security Advisor can provide an undue level of system access.

• Service should use Kerberos authentication — Access through any other authentication mechanism does not provide the maximum level of security protection.

• Service should have client IP addresses assigned — By limiting the number of IP addresses from which connections are accepted, InterSystems IRIS may be able to more tightly oversee the connections to it.

• Service is Public — Public services give all users, including the unidentified UnknownUser account, unregulated access to InterSystems IRIS through the service.

Roles

This section displays recommendations for all roles that hold possibly undue privileges; other roles are not listed. For each role, the Security Advisor may address any of the following issues:

• This role holds privileges on the Audit database — Read access to the Audit database may expose audited data inappropriately; Write access to the Audit database may allow the inappropriate insertion of data into that database.

• This role holds the %Admin_Secure privilege — This privilege can allow for the establishing, modifying, and denying access of users to assets; it also allows the modification of other security-related features.

• This role holds Write privilege on the %IRISSYS database — Write access to the %IRISSYS database may allow the compromise of system code and data.

Users

This section displays recommendations related to users generally and for individual user accounts. In this area, the Security Advisor may address any of the following issues:

• At least 2 and at most 5 users should have the %All role — Too few users holding %All can lead to access problems in an emergency; too many users holding it can open the system to compromise

• This user holds the %All role — Explicitly announcing which users hold %All can help eliminate any who hold it unnecessarily.

• UnknownUser account should not have the %All role — A system cannot be properly secured if anonymous users have all privileges. While this is part of any instance with a Minimal security level, such an instance is not properly secured by design.

• Account has never been used — Unused accounts provide an attractive point of entry for those attempting to gain unauthorized access.

• Account appears dormant and should be disabled — Dormant accounts (those that have not been used for over 30 days) provide an attractive point of entry for those attempting to gain unauthorized access.

• Password should be changed from default password — This is a commonly attempted point of entry for those attempting to gain unauthorized access.

Web, Privileged Routine, and Client Applications

Each application type has its own section, which makes it simpler to review details for each application type. These sections display recommendations related to access to and privileges granted by applications. In this area, the Security Advisor notes the following issues:

• Application is Public — Public applications give all users, including the unidentified UnknownUser account, unregulated access to the data associated with the application and actions that the application supports. This is even more notable if the application also grants the %All role, either conditionally or absolutely.

• Application conditionally grants the %All role — A system cannot be properly secured if users have the possibility of holding all privileges. This is even more notable if the application is also public.

• Application grants the %All role — A system cannot be properly secured if users have all privileges. This is even more notable if the application is also public.