Usable Security Notes PDF

Week 8 notes **Usable Security** - Originated from the 1990s work of Adams and Sasse, who suggested that users aren't inherently the enemy in security but face usability challenges, e.g., difficult password policies. - This led to more research on making security mechanisms user-f...

Week 8 notes **Usable Security** - Originated from the 1990s work of Adams and Sasse, who suggested that users aren't inherently the enemy in security but face usability challenges, e.g., difficult password policies. - This led to more research on making security mechanisms user-friendly, particularly in areas like authentication and encryption. - The first Usable Security and Privacy conference (SOUPS) was launched in 2005, highlighting the significance of this field.  **Why Usable Security Matters**: - Security tasks, such as authentication, are secondary (supporting) tasks users perform to accomplish primary goals, like accessing email. As secondary tasks, they're less engaging and can lead to insecure behaviour, such as weak or written-down passwords.  **Human-Centred Security**: - Emphasises designing security systems that account for human behaviour and reasoning, making secure behaviour easier for users.  **Ka-Ping Yee's Usable Security Guidelines**: - **Path of Least Resistance**: Ensure the simplest option is the most secure. - **Explicit Authorization**: Require users to directly authorise actions to prevent accidental access. - **Appropriate Boundaries**: Clearly distinguish resources and actions in the interface. - **Revocability**: Allow users to withdraw previously granted permissions. - **Expected Ability**: Avoid implying functionality that doesn't exist. - **Trusted Path**: Ensure secure communication channels for sensitive actions. - **Identifiability**: Make objects and actions distinct and difficult to spoof. - **Expressiveness**: Allow users to define security policies easily and specifically. - **Clarity**: Display security impact warnings before completing high-risk actions.  **Limitations and Future Directions**: - Although following guidelines helps, usability testing is essential. Encouraging companies to incorporate user-centred security remains challenging. **Pretexting:** - Pretexting is an attack in which the attacker creates a scenario to try and convince the victim to give up valuable information, such as a password. - Pretexting is composed of the following elements: - **Plausible situation:** This is the situation that could potentially lead to the objective being achieved. It is a sequence of believable events, designed and guided by the social engineer to extract information or manipulate the target. The chosen pretext is based on the initial reconnaissance. It is this reconnaissance that not only points to a viable pretext but also provides the necessary information to support it. - **Character:** The plausible situation involves the social engineer playing a "role" much like an actor. This does not necessarily mean impersonating someone real, in fact, it is more often a fictitious character. However, it is important to remember that there are many aspects to consider when creating a character.