How to Configure the Ethical Wall?
The Ethical Wall provided by SphereShield serves as an information barrier to enforce data separation between groups & users within an organization or federated domains.
For Ethical Wall to work, we'll need to have the SIP Filter component installed on either the Edge or the Front-End of Skype for Business.
In the case you are still considering which deployment of Ethical wall you need, please check the following KB: Where Should the SIP Filter be installed?
Ethical Wall Settings
Initial configuration
In order to reach the Ethical wall settings, please go to your Admin Portal Admin Area → Settings → Ethical Wall, or by using the following URL: /admin/settings?category=settings_federation_webservice_category_header
Please note all the following settings will not appear unless the "Enable Ethical Wall" Settings is set to "Yes".
Options
| Option | Explnation |
|---|---|
| Run Ethical Wall on | Choose where you have the SIP Filter installed, Skype for Business Front-End or Edge. Please note the Bastion option is only available if your Bastion server has a LAC filter which supports Ethical wall. |
| Skype for Business Front End servers FQDNs | Enter the FQDN of your Front-Ends, this is only relevant when you have the SIP Filter installed on the Front-End servers. This is used to ignore SIP messages from the Front-Ends which cause unnecessary traffic. |
| Policy rules memory cache time (minutes) | Set the number of minutes for the SIP Filter to save policies and policy cache locally on the server before refreshing and fetching updated policies from the Database. |
| Access Skype for Business contact list | If set to "Yes", policies based on the contact list will be available (This requires UCMA configuration unless installed on the front-end. How to configure UCMA integration with SphereShield?) |
| Contact list cache period (minutes) | Set the number of minutes for the SIP Filter to save a user's contact list locally on the server before fetching it again. |
| Internal domain list | Enter the SIP domains of your environment. |
| Operation Mode | Set the operation mode on which the SIP Filter runs (Live, Learning or Dummy). |
| Calculated Policy cache validity period (hours) | Set the number of hours for policy cache records to remain valid, after this the invalid records are deleted. |
| Ethical Wall scope | The scope of the Ethical Wall, External controls federated users, while internal controls internal users communications. |
| Admin notification type | Choose the type of notification for notifying admins about Ethical Wall incidents (IM Requires UCMA integration and IM Notifications configuration). |
| User notification type | Choose the type of notification for notifying users about Ethical wall incidents they have caused (IM Requires UCMA integration and IM Notifications configuration). |
| User notification message | Enter the message to be sent to users after they have caused an Ethical Wall Incident. |
| Ignore handling presence | If set to "Yes", any Ethical Wall Policy with a presence rule set to it, will not apply and will be ignored (hence presence will always be seen), choose "Yes" for Internal Ethical Wall control. Ignoring presence reduces the load from the system. |
Ethical Wall Policies
To configure Ethical Wall policies, go to the Admin Portal Admin Area → Ethical Wall Policy, or by using the following URL: /admin/federationpolicy
Ethical Wall policies can be set to apply internally (on users and groups within the organization that communicate with other users or groups within the organization). Alternatively, policies can be set to apply externally (For federated domains).
Ethical Wall policies can be applied to specific groups within the domain that the Access Portal can pull from the Active Directory, this feature requires an LDAP connection string to be set. When setting an Ethical Wall, it will create a default policy for P2P communication and conference communication, these policies cannot be moved up/down and cannot be deleted. Use it as a baseline for when none of the policies apply. There are 2 default policies for internal Ethical wall and another 2 default policies for the external Ethical wall (for P2P and conference both internally and externally).
Policy order
Policies are enforced from top to bottom, where the first policy will take precedent over the policies below it
It can be configured that a policy will only apply one rule by changing the rule to be with control
Policy creation
The policy creation process is split into two stages:
- Polices condition - Setting the scope of the users implicated by the policy and additional modalities. The scope of the policy is versatile and can be set based on groups, individual SIP addresses, or domains.
- Policy rules - Setting the type of communication that will be handled by the policy
Policy conditions
Policies are created first by defining the communication conditions, the set of relationships between Users, AD Security Groups, Domains. as well based on an additional modality whether they are present in the contact list of the user.
Options
Side A policy condition
The Internal user SIP address, AD security group, or the internal SIP domain.
- Group - AD security group
- Domain - SIP Domain under the Internal domain list
- SIP - A particular user under internal domain list
- A has B in the Contact List - Enforce the policy based on contact list's presence in Side A
It is required to configure UCMA integration in order to apply policies based on the Contact list
for more information see
UCMA General Information
Side B policy condition
Configuration The other side of the communication
Defines the scope of the policy:
- Internal - The policy will only apply to Internal users.
- Group - AD security group
- Domain - SIP Domain under the Internal domain list
- Same side as A - set policies for each internal SIP domain when using multiple SIP domains
- SIP - A particular user under internal domain list
- External - The policy will only apply to traffic with Federated domain
- Domain - A federated SIP domain
- SIP - A particular user under a federated domain
Policy Conditions
Policy Rules
Policy rules is the section where configured which type of communications will be allowed or disallowed
Policy Rules
Communication policy
| Allow | Allow all controlled capabilities between side A and side B. |
| Block | Block all controlled capabilities between side A and side B. |
| Control | Modify the policy based on other policies below it |
Contact Card
An optional section to control which information will appear in the Contact Card,
The option will only show if UCMA integration is set and the contact card modality is enabled as part of the conditions of the policy.
Contact card setting
Policies types
P2P (Peer to Peer) Policy
Scope
These policies are policies that are applied when a certain user chooses to communicate with another user not via a conference, by searching the appropriate contact in the user’s client and starting a conversation.
Communication rule types
Communication rule types are the type of communication that can be configured within the scope of the Policy
Chat | The ability to initiate a chat. The side with the |
Audio | The Ability to initiate a VoIP conversation over Skype for Business. Works the same as the Chat restrictions. |
| Video | The ability to initiate a video call over Skype for Business. Works like the chat and the Audio. |
| File Sharing | The ability to share a file Via Skype for Business. If the policy is set in the same manner as the Chat example, side A will be able to send a file to side B, while side B won't be able to send a file even after a file has been already sent. |
| Conference | The ability to start or invite users to a conference. This setting work like Chat, Audio, and Video |
See presence | The ability to see the presence (Statuses like “Busy”, “Available”, “In a meeting” etc.) of the other party. When this feature is deployed externally it can be set only to block federated users from seeing the internal user’s presence and not the other way around. |
| Contact Card | The contact card policy rule refers to the vCard you may see when choosing someone’s name. This policy rule allows blocking federated users from seeing the internal user’s contact cards. Just like the presence control, this feature can only be applied to block federated users seeing internal user’s contact cards and not vice versa. Within this feature, SphereShield also offers the ability to control what information exactly is shown to the other side (Name, Title, Email, Phone, etc.) This feature is not available when running the SIP Filter on the Front End. |
| Desktop Sharing | The ability to perform a screen presentation and whiteboard. |
| Program Sharing | The ability to perform a screen presentation that presents only a certain program within the computer rather than the entire monitor |
Conference Policy
Conference policies are policies that are applied for meetings both Ad-Hoc and organized
Generally, most of the conference policy rules work in a 2-way manner and can be set to either completely allow a certain feature in a conference or completely block.
This behavior is contrary to P2P policies where a certain rule can have a different behavior if it’s “Incoming” (from side B to Side A) or “Outgoing” (from side A to side B). However certain features (like “Present desktop”) can be set with different “Incoming” and “Outgoing” values.
When setting an Ethical Wall policy it is set between 2 sides (Side A, Side B). Side A Should be an internal SIP domain Group, Side B can be either an Internal SIP domain or an external SIP Domain.
Communication rules types
| Chat | The ability to initiate a chat. In conferences, this rule can be set to allow both sides or block both sides. |
Audio | The Ability to initiate a VoIP conversation over Skype for Business. Works the same as the Chat restrictions. |
Video | The ability to initiate a video call over Skype for Business. Works like the chat and the Audio |
Data collaboration | The ability to share PowerPoint presentations, File transfer, QA, Whiteboards, and polls. This setting can also be defined either to allow both sides or to block both sides |
| File transfer | A way to exclude only file transfer from the Data Collaboration. This feature requires the usage of SphereShield's Content manager (This rule exists only if Data Collaboration is allowed). |
| Present Desktop | The ability to present the screen. This feature can be set to block or allow incoming and outgoing independently. Will also apply for Present Program. |
| Remote control | Blocking this feature will grey-out the “Request control” button in a chat. This feature can be set to block or allow incoming and outcoming independently (This rule exists only if Present Desktop is allowed). |
Communication policy type screen
Web App Policy
These policies are applied by the Bastion LAC filter which will be enforced only on the WebApp.
You cannot configure the granularity of the users that will receive this policy, all internal users connected using a mobile phone will be enforced under this policy outside of the Present Desktop.
Present Desktop is controlled by all the other user-defined policies
Communication rules types
| Chat | The ability to initiate a chat. In conferences, this rule can be set to allow both sides or block both sides. |
| Data collaboration | The ability to share PowerPoint presentations, File transfer, QA, Whiteboards, and polls. This setting can also be defined either to allow both sides or to block both sides |
| Conference | The ability to start or invite users to a conference. This setting work like Chat, Audio, and Video |
| File transfer | A way to exclude only file transfer from the Data Collaboration. This feature requires the usage of SphereShield's Content manager (This rule exists only if Data Collaboration is allowed). |
| Present Desktop | Taken from all the other user-defined policies |
Mobile Policy
These policies are applied by the Bastion LAC filter.
You cannot configure the granularity of the users that will receive this policy, all internal users connected using a mobile phone will be enforced under this policy outside
Communication rules types
| Chat | The ability to initiate a chat. In conferences, this rule can be set to allow both sides or block both sides. |
| Audio | The Ability to initiate a VoIP conversation over Skype for Business. Works the same as the Chat restrictions. |
| Video | The ability to initiate a video call over Skype for Business. Works like the chat and the Audio. |
| Present Desktop | The ability to present the screen. This feature can be set to block or allow incoming and outgoing independently. Will also apply for Present Program. |
| See presence | not supported in mobiles |
