LDD Today


[back to "Staying alert with Execution Control Lists"]

ECL access option risk levels
There are tradeoffs between user convenience (fewer execution security alerts) and tighter security. The tables below categorize the level of risk associated with each workstation security action for two signature policy scenarios.

Very stringent signature policy
Here is an example of a conservative ECL policy, which ensures fairly strong security with higher likelihood of ECL alerts.

ActionRiskDefaultNo SignatureLotus Notes Template Development/Lotus Notes*/Organization*/OU/Organization
(where * corresponds to trusted users)
Access to the file systemHighDo not allowDo not allowAllowDo not allowDo not allow
Access to the current database*HighDo not allowDo not allowAllowDo not allowAllow
Access to environment variablesLowDo not allowDo not allowAllowDo not allowAllow
Access to non-Notes dataMediumDo not allowDo not allowAllowDo not allowAllow
Access to external code
(such as Notes LSX or API programs)		HighDo not allowDo not allowAllowDo not allowDo not allow
Access to external programs
(such as non-Notes programs)		HighDo not allowDo not allowAllowDo not allowDo not allow
Ability to send mailHighDo not allowDo not allowAllowDo not allowAllow
Ability to read other databases MediumDo not allowDo not allowAllowDo not allowAllow
Ability to modify other databasesMedium-HighDo not allowDo not allowAllowDo not allowAllow
Ability to export dataMediumDo not allowDo not allowAllowDo not allowAllow
Access to Workstation Security ECLHighDo not allowDo not allowAllowDo not allowAllow

*Access to current database includes both read and write access. This can be risky in the context of a user's mail file. Use caution when assigning this privilege to users. However, if a consistent signing policy does not exist, not allowing access to current database will generate a large number of Execution Security Alerts.

Less conservative signature policy
Here is an example of ECL that minimizes execution control alerts while mitigating only the most severe risks.

ActionRiskDefaultNo SignatureLotus Notes Template Development/Lotus Notes*/Organization*/OU/Organization
(where OU corresponds to trusted users)
Access to the file systemHighDo not allowDo not allowAllowDo not allowDo not allow
Access to the current database*HighDo not allowDo not allowAllowAllow*Allow*
Access to environment variablesLowAllowDo not allowAllowAllowAllow
Access to non-Notes dataMediumDo not allowDo not allowAllowAllowAllow
Access to external code
(such as Notes LSX or API programs)		HighDo not allowDo not allowAllowDo not allowAllow
Access to external programs
(such as non-Notes programs)		HighDo not allowDo not allowAllowDo not allowAllow
Ability to send mailHighDo not allowDo not allowAllowDo not allowAllow
Ability to read other databases MediumAllowDo not allowAllowAllowAllow
Ability to modify other databasesMedium-HighDo not allowDo not allowAllowDo not allowAllow
Ability to export dataMediumDo not allowDo not allowAllowDo not allowAllow
Access to Workstation Security ECLHighDo not allowDo not allowAllowDo not allowAllow

*Access to current database includes both read and write access. This can be risky in the context of a user's mail file. Use caution when assigning this privilege to users. However, if a consistent signing policy does not exist, not allowing access to current database will generate an increased number of Execution Security Alerts.