#1. Clearly describe how to set security· Ensures that UI reduces the level of complexity in configuring and managing security
· Are there features to test roles?
· Will users understand how the test features work?
· What are Default Security Roles for New Objects
· When objects are created, what are the default security settings?
· Are users informed what the security settings are?
· Default Security Roles for Updated Objects
· What is the default security mode for updated (sub-) objects?
· Are users aware of the default security permissions?
· Is the security mode appropriate?
· When updating the object, will users think/be prompted to change the security?
· Are there Multiple Methods of Setting Security:
· Are there are multiple methods of setting security for an object?
· How are the methods different?
· Do users understand the key differences between the methods? (Will they be able to choose the appropriate method?)
· If a parent object rolls-up security state from its children, is the state accurately rolled up?
· Can I Bulk Edit Security Roles?
· Do users require bulk editing of security roles?
· Are bulk editing facilities provided?
#2. Does UI provide a means to quickly reset to a secure mode in case of a security lockdown?
• Provide a single place for users to turn off features in security lockdown.
• If clusters or a group of servers are used, provide a facility to bulk reset
#3. Does the UI imply security when system may not be secure
• Don’t give users a false sense of security: Users feel secure when they have set a password. Counter intuitively, if this password is weak, a blank password is in fact a stronger defense, since the system will restrict certain access if there is no password, but will not do this if there is a password is present.
• Giving partial or incomplete information can falsely imply security.
#4. Ensure that UI provide admins an overview of privilege granted to users
• Ensure that admins have a means to have a system overview of which user has what privileges.
• Excessive privileges granted are a major vulnerability. Ensure that UI allows admins to easily revoke granted privileges, and clearly see consequences.
#5. Does the UI actively promote security
• Ensure that your UI does everything it can to actively help the user secure their system.
• If a user must compromise their system’s security to perform a task, provide some way to automatically restore the system’s security later, or prompt the user to restore the setting when the user has completed the task.
• Make it clear to the user where they need to go to reestablish a secure configuration. Provide direct links wherever possible.
• Enable your feature to be updated easily if security issues appear after it ships using an automatic mechanism such as Windows Update.
• Make sure that the most secure option is the default. Explain to users the security issue that makes this is the recommended option.
• When the default option is not the most secure option (for reasons of product compatibility or some other intention), indicate visually which setting is the most secure.
• Provide an option to automatically secure system, such as to lock unattended machines
• Provide a simple means in the UI for users to determine if preventive measures such as virus signatures are up-to date
#6. Are security messages effective?
• Ensure that security messages are differentiated from other messages. Users are inundated with so many message boxes that they often breeze through these obstacles. Security messages look much like every other message, so users get a mixed message and tend to ignore them. In one usability study, 5 out of 8 clicked either Yes or No without reading the security dialog.
• Emphasize security by giving a visual clue that this is a different type of message. Even as users become familiar with the style and learn to click through without reading the text, we alert them to the fact that there is a security issue during the split second we have their attention. Used judiciously, users may even perceive them as infrequent enough and visually arresting enough to slow down and pay attention.
• Communicate the level of risk associated with any choice provided in security-related information. Users should be able to identify the severity of the problem, likelihood that it will affect them, and any necessary steps to correct the situation.
• A high risk warning would have more lasting impact if the frequency of other messages is low.
• Make information in the message box specific enough for the user to follow up after closing the box, such as searching for the terms in the message to find relevant Help content or links to security features.
#7. Are UI graphics appropriate to the severity of the message?
• Use graphics to reinforce, highlight or convey security information, but ensure that the graphics are appropriate and related to the content.
• Do not use the question mark message icon. This image does not clearly represent a specific type of message or could be misinterpreted as related to Help information.
• Avoid overusing the warning icon. Be sure that the content is truly a warning, and not simply an fyi or even more serious than a warning.
• Use graphics that look professional and consistent with the product’s look and feel so that the user feels they can trust the source of the message. Work with a designer to define the correct style for icons in your product.
#8. Does UI Help assist user to be secure?
• The Help topic should bridge the gap between the UI and real world usage. The Help topics can be the user’s last hope of understanding a concept or helping them make a decision. Often our Help topics are just as vague, technical and intimidating as the interface the user is trying to understand.
• Address common user scenarios.
• When the user experience is not great, explain how to understand the feature’s design and UI, not just the steps to use it. For example, if the settings for using a feature for a specific scenario are on a different tab or hidden behind a link to “advanced” features, explain that X users can find the settings they want there.
• Where a feature allows users to choose settings that affect the security of their system, explain the security consequences even if it makes it clear that they don’t get to have a perfect solution.
#9. Has the UI been designed to accommodate supplemental security?
• Design the product to anticipate security devices t such as smart cards, biometric product fingerprint, and retina scanners which are starting to be used to identify users to system.
