1

2

3

In this course you will learn to analyze computer security from three different perspectives: Alice the user, Dan the administrator and Trudy the bad guy. The purpose is to switch different roles and understand the computer security problems and design better solutions.

4

For example, passwords are used to protect user accounts. Passwords can be looked from three perspectives.

5

Users are worried that they forget passwords. Thus, they try to set easy to remember passwords or write them down. They use the same password for all accounts. Thus, compromising one account can make the other accounts vulnerable as well.

6

Dan, on the other hand is concerned about system security. He is also concerned about users calling in and asking for password resets.

7

8

Both Dan and Trudy compete with each other for swinging human factors in their favor. The question is who wins. So, it is important that security professionals are aware of human factors and be able use human factors to enforce security.

9

10

11

Best strategy is to chose an option that is both secure and usable. A very complex password may gives rise to memory problems. As the result, users may write down or store their passwords in text files. Thus, the usability problems result in security. So go for an option that is both secure and usable.

12

[Nielson 93] Usability Engineering, Jacob Nielsen, AP Professional

For best usability, the system should be:

Easy to learn

Efficient to use

Easy to remember

Less Errors – frequency and severity

Users should like using the system

13

In the next few slides, we introduce usability design principles.

14

A good system should correctly balance security and usability.

15

At every stage, you should know what to do next.

16

You should be able to easily figure out how to do something.

17

System design should make you safe from dangerous errors such as accidently revealing password or confidential information or deleting all your files.

18

You should like the interface. It is often good idea to ask for some previous work to understand the design philosophy.

19

The above are the steps for achieving usability. Design and Usability Tests (and possibly some of the earlier steps) are repeated until satisfactory system design is achieved. Usability testing can significantly increase your Return on Investment and improve security.

20

It is definitely a good idea to invite the team to your location, this way they can observe how users are using (or not using) the system. This will give an idea as to what improvements can be made.

21

Users memory may be corrupted or learning may be affected due to inference.

22

Dual Coding Theory says that humans have two distinct cognitive subsystems for processing imagery and language

It is better to provide information in both visual and verbal form. The worst scenario is when the visual information conflicts with the verbal information.

23

Avoid conflicts between visual and verbal information.

24

Users’ interaction with the system is heavily influenced by their mental model of the system.

25

Users have a simple mental model on how dimmers work.

26

The actual system is more complex.

27

Users mental model may suggest that placing black rectangle over the area to be redacted will ensure security. However, an attacker can cut and paste the secret information from the “redacted” area.

28

[wt99] – “Why Johnny Can’t Encrypt:

A Usability Evaluation of PGP 5.0”, Alma Whitten and J.D. Tygar, USENIX Security Symposium, 1999.

29

The gap between user’s mental model and the actual system may be reduced by training, by the use of documentation provided or by their own experimentation with the system. Again, the expectation is not for users to know everything about the system, but to provide enough details so they can securely use the system.

30

31

A survey may be created with list of relevant questions for your users to respond.

32

33

34

Usability analysis methods include: Functional, Task, and Competitive.

35

Perform task analysis [Nielson 93] to find out what users want to do and how they can do those tasks.

36

Task analysis provides insight into users’ goal of using the system.

37

Here the focus is on “what”. Thus, we can find out more efficient ways (“how”) of performing tasks.

38

Those products are already built and may be experimented with, to find out what improvements can be made. This is especially useful since reasonable effort must have already been put into designing of these products. i.e., you don’t have to re-invent wheel.

39

It is not feasible to address all usability goals; so pick the most important ones.

40

41

Parallel design is a design technique where

different teams can individually develop designs in parallel and

combine the different designs to develop the new product design.

42

Another technique that includes real users in the design process. Developers and Administrators (Expert users) may also be included.

Participatory design help find out the difference between users’ view of tasks and

developers’ model of tasks

43

Horizontal prototyping is breadth, i.e, all features are implemented at GUI level, but no functionalities are actually implemented. Vertical prototyping, on the other hand, implements certain core functions of the system that corresponds to major usability goals.

44

45

Scenarios are a kind of prototype. Usage scenarios can be created and then discussed with actual user groups.

e.g., scenario of a user logs on to a computer system: (1) User visits the website (2) User finds the login link and clicks on it. (3) User enters user name and password … etc.

46

A number of usability principles relevant to the application are evaluated. Often it is a good idea to use double experts; i.e, people with usability expertise and knowledge in the application domain.

Experts analyze the GUI to see whether it is usable often by checking the GUI’s adherence to certain pre-established rules.

Common sense and intuition may also be applied during Heuristic Evaluation process

47

48

Again, the hope is that you can learn from a diverse group of people.

49

In the next few slides, we explain some testing methods.

50

More information is available in [Nielson 93].

51

In some cases, sound recording of user response may be made along with

video feed from monitor (to record user interface interactions).

52

53

Other techniques may also be used.

54

Several iterations are possible until an acceptable design is obtained. Any of the above steps may be repeated as needed.

55

56

Usable Security: How to Get It, B. Lampson, CACM, November 2009

57

58

59

It would be tempting to go ahead and start implementing. Often, client gives you sketchy requirements, at best. So it is important that we find out more.

60

Ask additional questions to find out more information. The more information you can find, the better it is.

61

62

63

Data Flow Diagram (DFD) may be used for modeling system and visualizing its components

64

Draw DFDs to visualize the system (you may also use UML). Entities are represented by rectangles. The processes are represented by circles.

65

Level 1 DFD is expanded. The filter process obtain two integers from the user. These are passed to add. Add adds these integers and displays the result for the user.

66

67

User interface design may be performed with techniques such as parallel design, proto typing etc.

68

Psuedo codes are developed for the module. Psuedo code resembles a programming language, but more of a high level specification of what each module should do.

69

70

Trust boundaries are identified as above. Entry/Exit point to the system would be the web input form. Anyone can read the web page and submit information. Users are not allowed to modify web pages. The second trust boundary is between Filter and add. User’s don’t have direct access to add method. Add assumes that the inputs are integers – no error checking is done inside. Only applications can cross through this boundary.

71

Standard threat models such STRIDE may be used to discover threats. Pay attention to human factors.

72

73

References:

1. Security and Usability: Designing Secure Systems That People Can Use, Edited by Lorrie Faith Cranor and Simson Garfinkel , Publisher: O'Reilly Media, ISBN-13: 978-0596008277

2. “A Framework for Reasoning About the Human in the Loop” UPSEC 2008.

74

Analyze system from three perspectives: Use, Defense and Offense to list potential threats.

Threats may be rated using a model (such as DREAD) to spot the important threats.

75

DREAD or similar models may be used for rating threats

76

77

Make sure the human interface is redesigned to mitigate human factor thereats.

78

Make necessary changes to the modules to mitigate the threat.

79

For each module, specify how you are going to test it.

80

81

82

This policy is bound to fail due to human factors.

83

The above policy eliminates the risk of users accidently downloading software from unknown websites. At the same time, it helps uses to check their gmail or skype to someone else occasionally.

The above example shows that a security policy can be improved when viewed from three perspectives.

84

85