|
Figure 1: Growth of On-Line Business |
By
Robert
Stocker
CIS 732 - Design of Interactive Systems
December 18, 2000
Table of Contents:
2. Business applications and increased risk
4. Alternative Interface Methods for Security
5. Security Design in the Development Framework
This paper explores the requirements and development methods for user-centered security and it’s impact on the human computer interface. It is no secret that e-Commerce has been in the center of an explosion of new users onto the Internet. According to Forrester Research, global e-Commerce will approach $6.9 Trillion by 2004 (NUA, 2000) which translates into millions of additional users being added to the Internet and using on-line systems each year. Figure 1 illustrates the $1.4 Trillion share relating the growth in the US alone.
Digital signature laws, which were primarily governed by the individual states, have now been standardized by a new federal regulation, which promises to encourage new business opportunities. Organizations now have the opportunity to exploit another marketing channel for financial transactions (such as purchasing life insurance on-line) but there are additional risks that come with on-line authentication.
With such growth in the number of casual users on the Internet (and other applications), access security is clearly becoming a more important part of application development, and it is important that more effective user interface designs be developed to improve user satisfaction and to ensure compliance. Usability testing and security must be merged in order to produce designs that will be accepted and not circumvented by the user. Alternative user interfaces, including biometric interfaces need to be adopted, both for stronger security and to improve functionality.
On October 26, 2000 Microsoft disclosed that computer hackers had managed to obtain the plans and blueprints for future Microsoft products still in development. Also during the last year, the Meta Group reports that 9 out of 10 companies and government organizations have reported security breaches. “For 42% of the companies who were willing (or able) to quantify the damages and financial losses, the total ran to $265M” (Passori, 2000).
And yet, a different Meta Group article stated that organizations that are able to provide an “infrastructure for employees, partners, and clients to find the concise relevant information they require to make decisions, with a minimum of effort, will have a significant competitive advantage in terms of efficiencies, service and satisfaction.” (Barnes, 2000).
These two statements illustrate a paradox in industry and government where the need to meet tight deadlines, to compete effectively and to disseminate timely information usually outweighs any desire to mitigate the potential risks to availability, data integrity and accuracy of a computer system. Articles on improving the usability of high volume applications such as Internet based e-Commerce sites often do not mention security and if they do, it is to warn against it’s ‘overuse’. For example in a 1998 article on “Creating Usable e-Commerce sites”, Janice Rohn writes the following: “Do not require a login and password unless necessary. Customers are in the difficult situation of not wanting to use the same password everywhere, yet having too many passwords for different purposes to remember them all” (Rohn, 1998). And yet, all e-commerce sites collect private customer data; including address, birth date, credit card numbers and other information in a database accessible from the web and prone to be stored outside of the protection of the company firewall. The Gartner Group states that: “Security is essentially an economic proposition: If an asset is worth more than it costs to steal, it is insecure. Legitimate owners must understand the street value of their information resources or risk applying the wrong level of security to the wrong resources, with potentially disastrous results” (Hunter, 2000).
Identification of the user and access control lists (ACL) manage the actual processes that the user will gain access to. Id and password authentication are typically the primary method of verification by attempting to determine that the user is the actual owner of an id. There has been considerable research in role-based access controls, password construction analysis, security directories such as the lightweight directory access protocol (LDAP), digital signatures, as well as hardware-based methods such as tokens or smartcards. However, while most of the research in the past has centered on controlling access to systems, the “usability of these mechanisms has rarely been investigated” (Adams, 1999).
“Considerations for users’ natural working patterns can strengthen the security of the system” (Zurko, 1996). Typically the security paradigm may take one of two directions: The oldest security model is based on security classifications and on the concept of least privilege or “need to know” (Zurko, 1996). The very nature of securing systems this way creates a challenge to usability. The other paradigm of little or ineffective security policies has come about along with the advent of eCommerce and on-line financial transactions. A stated privacy policy and the use of a browser-to-server secure sockets layer (SSL) is recommended on page 114 of the Rohn article, but it may provide a misleading and false confidence to the user. Using SSL may protect individual transactions, but many organizations do not take into consideration the risks to their data, systems or business reputations and implement weak or ineffective policies in order minimize the convenience to the customer. But, if the user’s id and password becomes compromised or forgotten, they must typically call customer service to have it reset. This creates even more frustration and an environment where the user can be impersonated in order to gain unauthorized access to the system. It is much more effective, and would give a better sense of confidence to the user to have a well designed user security interface as well as strong security policies in place.
Users have a strong motivation to protect their privacy, and security designers must balance the need to share information with the need for privacy of confidential data, particularly in the case of medical information. It is a paradox where medical data is the most personal and sensitive of all information, and yet provides maximum value to the user only if it is shared with healthcare providers or emergency room personnel (Rindfleisch, 1997).
Tessa Lau, et al. proposes developing a privacy interface to “provide users with a means of specifying their own individual privacy policies” (Lau et al., 1999). These interfaces should aid the user in selecting their own policy parameters, to be able to monitor and modify these policies as needed, and for the policies to be extensible to new objects as they are encountered (Lau et al., 1999). And yet, the design should not prevent an emergency room doctor to gain access to information in the case of an unconscious or critically ill patient.
No one security policy or architecture can be made to fit all application designs. This realization makes it that much more important to incorporate risk assessment, analysis, and design directly into the development methodology taking into account the need for privacy, confidentiality and security. “As we move toward the era of computerized medical record systems, we must design the systems from the start to accommodate evolving policies and security management technologies and develop standards to integrate and administer computerized health information systems prudently” (Rindfleisch, 1997).
Internally, an organization may have been adding new systems and infrastructures, all of which require distinct and unique passwords. Unfortunately, many users now need to remember multiple passwords for the various networks and applications that they use on a daily basis. Corporate password policies are inconsistent, and some passwords may need to be changed more frequently than others. Having more than just a few passwords reduces their memorability and increases insecure work practices, such as poor password design (for example selecting ‘password’ as the password) or simply writing passwords down in an open place, often as a note on the computer terminal. Users will use the shortest and easiest passwords that they can get away with as limited by policy (if any exist). These are the types of passwords that are quickly compromised by someone hacking into the computer system, removing the entire password file and decrypting it with software freely available on the Internet, such as ‘cracker’. (Adams, 1999).
According to the Meta Group, only 5% of the 2000 largest global companies have linked IT security policies with business policies. They have also observed that only the most effective organizations have created polices and based them on the results of a comprehensive risk assessment. (Passori, 2000). However while the assessment does much to identify sensitive information and critical systems, define appropriate security objectives, and “set a course for accomplishing those goals and objectives” (Passori, 2000) they do not describe the need to develop systems and policies with usability in mind.
Any good system development life cycle methodology will require active and ongoing participation of the users in the development process, and yet when it comes to security, there is often an inadequate amount of communication with the user during the design of the security mechanisms. As Adams stated: “ Many of these mechanisms create overheads for users, or require unworkable user behavior. It is therefore hardly surprising to find that many users try to circumvent such mechanisms” (Adams, 1999). It is also important for interface designers to realize that user behavior is affected by the number of passwords a person has, whether it was selected by them, or for them and the frequency with which it must be changed. They will in all likelihood also have multiple ids and passwords outside of the work environment, “increasing the cognitive load of users” (Adams, 1999).
“User-centered security refers to security models, mechanisms, systems, or software that has usability as a primary motivation or goal. Most work on usability emphases design process and testing.” (Zurko,1996). Particular attention must be paid to User Interface design dimensions such as using simple and natural dialogue as well as minimizing the user's memory load among others (Molich & Nielson, 1990) (Turoff et al., draft book). Unfortunately, since the technology is constantly changing and the user needs are so varied, it is difficult to develop an architecture that will always apply. However, the system development life cycle methodology can be modified to include security-usability testing and review several times throughout the design process beginning in the systems requirements analysis stage. (Zurko & Simon, 1996) define three categories of work in enhancing the user friendliness of security:
Applying
usability testing and techniques to secure systems: Zurko
et al. recommend using low-tech methods such as design mock-ups on paper. However, a
“Protocol Analysis is one of the most effective methods for assessing the usability
of an information system, and for targeting aspects of the system that should be changed
to improve usability” (Turoff
et al., draft book). This category would be best served by performing a limited
protocol analyses earlier in the life cycle and iteratively throughout the development of
the system.
Developing
security models and mechanisms for user-friendly systems (such as groupware). Technical and
computer-aided support for any sort of collaborative effort can generically be referred to
as Groupware, which reflects a change in importance from "using the computer to solve
problems to using the computer to assist in human interaction" (Ellis et al. 1991). Groupware has a unique set of
circumstances, which require users to work together in the same environment and utilize
the same resources. Traditionally, many such
systems rely on database or operating system methods for controlling access among multiple
users. Operating systems can restrict access to directories, files and applications, but
cannot support group-level activities. Using
programmatic interfaces, unique and customized desktop user interfaces can be built for
multiple users, even on the same desktop computer (Cowart, 1995). However, operating
system access controls alone are not sufficient for sharing applications among multiple
users.
Database access controls allow a higher level of granular access to database filespaces, tables, columns or data elements for multiple users. With modern relational database management systems, multiple users may be provided access to the data via group-level authority, through an application, or as an individual. However it is only after the user has attempted to invoke a function such as read, write or update that authentication occurs.
The majority of research by the Computer Human Interface
community has been in the groupware area because of the need to add appropriate controls
between the simultaneous users in simultaneous multi-user systems. Dewan et al. has
written about the need to control higher level logical operations such as window position
and resizing or scrollbar controls which can only be restricted via user protected
interface objects, inheritance based on include and imply relationships, and interactions
and coupling rights. (Dewan, 1998).
Considering
user needs as a primary design goal at the start of secure system development. When following
the system development life cycle (SDLC), the risk to the business should be assessed in
terms of confidentiality, integrity and availability during the system requirements
analysis phase of the life-cycle (PWC, 1997):
· Confidentiality is keeping information secret or private within
a pre-determined group. The loss of confidential information may be a factor in loosing
competitive advantage or being held liable for the loss of legal or ethical information.
· Integrity is the confidence that the quality of the data is
accurate and complete.
· Availability refers to the accessibility and usability of the
application and data.
· User-Centered Security requirements should then be derived from
the risk analysis and the framework for implementation developed.
In
order to motivate people to use passwords properly, several factors must be addressed. The
concept of the user as the enemy by the security forces is very counterproductive, and
much in the same way that an application is developed by enlisting and involving motivated
users, security development must follow the same methods. Involving the user in the design
process will help gain understanding and buy-in and many user-centric design issues will
have a better chance of being addressed. The users should be involved in setting the
security policies, such as password length and time to expiration; should it be
computer-generated or input by the user; should the application ‘coach’ the user
if the selection is too weak to be secure; what the procedure is after three incorrect
tries, or if the user forgets their password. All of these policy issues need to be
addressed during the analysis and design phase of the user interface (Cobit, 2000).
Of
course, with the new technology options available, passwords may not be the only solution
to the security challenges. During the requirements analyses phase, the risk assessment
may indicate that stronger authentication is necessary. Also, the results of an early
usability test may indicate that users will need an alternative to password controls.
Other options include hard-tokens, public key encryption or biometric authentication.
Authentication
is usually a combination of: 1) What you know, 2) Who you are, 3) What you have. A
reasonable security architecture can be any combination of these three forms, with a
minimum of two recommended (Cobit, 2000). Id
and password are a form of a ‘shared secret’ between a user and the computer,
e-commerce web-site or ATM. This requires trust on both sides, and anyone compromising a
password may be granted ultimate authority over the system. (Corcoran, 1999) If designed well, interfaces adhering to the
shared secret can be made to conform with the design dimensions as listed in the draft
book (Turoff et al., draft book)
Some
individuals and companies are now turning to Public Key Infrastructure (PKI) and replacing
the shared secret method of security. As defined by Corcoran: “PKI uses a
standardized set of transactions using asymmetric public key cryptography, a more secure
and potentially much more functional mechanism for access to digital resources. The same
system could also be used for securing physical access to controlled environments, such as
your home or office” (Corcoran, 1999).
By
using PKI, the user is issued a public and a private cryptographic key. Private keys,
(often stored as certificates on your harddisk) are made up of a set of 1024-bit (or
2048-bit) binary digits and used to encrypt data or a transmission. , The other key is
used by the receiving party to decrypt the data. Anyone can use the public key, which is
not a secret, to encode a message which is subsequently decoded by the private key.
Corcoran describes it as: “Public keys are certified by a responsible party such as a
notary public, passport office, government agency or trusted third party. The public key
is widely distributed, often through a directory or database that can be searched by the
public. But the private key remains a tightly guarded secret by the owner” (Corcoran,
1999). After the certificates have been assigned (who you are), the process becomes
fairly transparent to the user and is generally more secure. For portability, PKI may also
be used in conjunction with a smart card (what you have) and a password (what
you know) for even greater security. An added benefit from a user-centered security
standpoint is that by using PKI either as a certificate or on a smart card will help in
the development of a single-sign-on solution that would increase the chances of conforming
to more of the design dimensions (Turoff et al., draft book), particularly security, and
the sense of control.
Biometrics
is the ultimate use of “who you are” characteristics and is preferable to PKI as
a potentially irrefutable authentication method. For example, the user carries a smart
card with their fingerprints encoded on it. After placing the card, and your finger into
the reader and entering a password (what you know) your fingerprint is then read
and matched against the one on the card. Other
than the fingerprint, biometric authentication can also be made against voice pattern,
face pattern and retina scans (Corcoran, 1999) and is considered more secure than using
PKI technology. Unfortunately, biometric technology is not cost effective enough to
justify utilizing it for anything but the most highly sensitive security applications.
When
designing for user-centered security, the potential risk must be weighed against the cost
and inconvenience to the user of the architecture that is eventually selected. There needs to be a balance, as the more secure
an application is made, the more inflexible the administration of the system will
inevitably become. However, as discussed in
Atsushi Sugiura’s paper on Fingerprint Recognition, it may be possible to design a
highly secure biometric interface that will be considered by the user to be a convenience,
rather than a burden.
The ideal interface would be one where the user feels that it is improving their productivity and enjoyment while using it. However, security interfaces are normally considered necessary evils. What Sugiura describes is a method of using biometrics, specifically fingerprint recognition as the actual user interface itself. This fascinating concept uses a special keyboard and finger Id table in order to program each fingerprint to perform specific tasks (see Figure 2). Other options are to assign objects or data elements directly to each fingerprint as well. Since users can manipulate objects or perform tasks with different fingers, they “will feel as if commands and data objects were actually held on their fingers” (Sugiura, 1998).
In addition to computer keyboards, it will be possible to use this interface on consumer items such as telephones, portable CD players or personal digital assistants (PDA) (see Figure 3). While the fingerprint user interface is still in the concept stage, there is additional on-going research in many areas of biometrics at this time including face and speech recognition. The FUI is still in the proof of concept stage and tests made by Sugirua indicated slow recognition times (1.7 seconds) and occasional mis-reads. As such, these issues do not yet conform to all of the minimum foundation factors as listed by Turoff: “If any of the foundation factors do not exist at a sufficient performance level, the system will be a failure” (Turoff et al., draft book). In particular the Responsiveness and Reliability factors will hold this interface back until these issues can be resolved. However, the accessibility and convenience, efficiency and least effort, and security foundation factors are well represented by this interface.
Going
forward, user-centered security interfaces will be used to add value to applications and
to help support dynamic business plans such as what customers can do in support of new
marketing campaigns. In general, the perception of information security will evolve away
from the negative public perception of preventing access to the more positive one of
giving users exactly what they want, or need (Fenn, 2000).
|
The Gartner Group performed a modified Delphi method to identify 12 high-impact technologies for user enterprises that will be adopted over the next ten years (see Figure 4.) fully half of them refer to new forms user interfaces such as speech recognition and advanced display technologies, several of which can be adapted to enhance user-centered security issues. (Fenn, 2000) Biometrics and speech recognition will play a central role as the technology becomes more reliable and the social issues such as privacy and safety concerns surrounding this technology become resolved and are more accepted by the user community. |
Analysis
of risk, security control functions and usability will determine the type of security
architecture to implement and the functions that need to be included. As noted earlier, it
is not enough merely to require an ID and Password to utilize a system. The security architecture must be analyzed and
decided upon early in the development process in order to have enough time to get users
involved in the usability testing of the security method and to design the policies. Policies for password length and expiration as
well as administrative functions (e.g. how a user may request a new password) or
development of role-based security rules must be designed during the requirements
gathering phase. As stated by Zurko, “one obvious approach to synthesizing usability
engineering and secure systems is to apply established procedures for enhancing usability
to developing or existing secure systems” (Zurko, 1996). The four techniques described by Zurko include:
Figure 5 illustrates a less formal, rapid prototyping methodology,
which is preferable for building complex systems with evolving requirements and rapidly
changing design and solution techniques. Controlled iteration operates by setting up an
initial executable model of user requirements, based upon and supported by the appropriate
conceptual data and process models. This executable model is progressively expanded and
refined through a series of passes (iterations) until is shown to meet key user
requirements.
This controlled iteration approach requires an unusually high level of user involvement in the design. The systems developer is only the catalyst between the users and the system, modifying the programs as per user feedback (Sprague 1980). Summit D modules fall under the five classic phases of development and Figure 5 graphically shows an overview of the methodology and the placement of the additional security usability development steps. Table 1 describes the phases and the ideal placement of the security usability tests within the lifecycle.
Phase / Module name |
Description |
UI - Security Deliverable |
|
I.
Requirements Analysis Phase |
|
||
SRA |
Systems
Requirements Analysis |
This
module analyzes and documents the functional requirements to be supported by the proposed
system, using data and process modeling model techniques. |
Contextual
Design: (Ethnography and Risk Analysis) |
PER |
Product Evaluation and Recommendation |
The
purpose of the PER modules is to evaluate and recommend products and vendors that best
meet the requirements. |
|
II.
Solution Definition Phase: |
|
||
SDS |
System
Delivery Specification |
This
module expands upon the user requirements and outline design documented in SRA to produce
detailed specification of the system to be delivered. |
Discount
Usability Testing: (Modified Protocol Analysis) |
PAI |
Product
Acquisition and Installation |
This module deals with the purchase and
installation of third party hardware and software. |
|
III. Design Phase: |
|
||
TSD |
Technical
System Design |
Continuing
from SDS, the purpose of the TSD module is to provide a detailed blueprint for how the
proposed system is to be built. |
In
Lab Testing: (Full Protocol Analysis) |
IV. Build & Test Phase: |
|
||
TPD |
Technical
Procedure Development |
This
module outlines in detail the plans for development, unit and integration testing of the
hardware and software. |
|
UPD |
User
Procedure Development |
Tasks
in this module include developing manuals, providing training and procedures for the new
system. |
|
SAT |
System
Acceptance Testing |
The
types of testing called for in this module include: functional, communications,
performance, volume, stress, recovery, usability, operations, environment and security. |
|
V. Transition to Production Phase: |
|
||
TRA |
Transition to Production |
This
module includes data conversions, lining up operations support, establishing all
production controls including scheduling and backups. Final plans for cutting over to
production are prepared and executed. |
|
VI.
Post Production Phase |
This
phase is an addition to the Summit-D methodology. The timeline is 3-6 months post
production |
Contextual
Inquiry: (Experiment & Questionnaire) |
|
As previously discussed, user-centered security design should follow the same goals of user-interface design as any traditional interface. As stated by Shneiderman: “For each user and each task, precise measurable objectives guide the designer, evaluator, purchaser, or manager” (Shneiderman, 1998, pp15). They include:
· Time to Learn: Determine how long it takes for a user to learn how to utilize the security scheme in the application
· Speed of Performance: Measure the amount of time that is required for the user authentication process.
· Rate of errors by users: Detmine what sorts of errors users make during the sign-in and authentication process. Design support systems to minimize the rate of errors and the recovery time for locked accounts and other common errors.
· Retention over time: Design systems to assist the user in reducing memory load. Develop self registration and self help modules to minimize the need to call someone for support.
· Subjective Satisfaction: Design interfaces that add to the user’s satisfaction and efficiency, such as the Fingerprint User Interface discussed by Sugiura.
This paper has attempted to demonstrate the need to incorporate user-centered security design tasks directly into the system development lifecycle. Spurred on by the popularity of the Internet, there has been a tremendous growth rate in the number of people accessing systems through human-computer interfaces. In order to accommodate this growth, many organizations have taken a casual approach to security, contending that it would stifle growth and customer satisfaction. However, there are serious concerns among the public regarding the privacy, confidentiality and security of their personal information and yet weak or ineffective policies encourage circumvention by the users.
Modern system development methodologies typically include requirements for on-line interface designs and call for usability testing. However, privacy and security interface analysis and design are usually developed at the end of the lifecycle and without thought to integration with the rest of the application. This is an error that this paper was trying to address. There are many different types of security interface alternatives available including password controls, public key infrastructure, voice recognition and biometrics and should be evaluated based on a complete risk analysis early in the development lifecycle. Security policies need to be developed early on, in order to better incorporate them into the ultimate design. Over the next five years, security interfaces may evolve into a perceived asset by offering value added features such as fingerprint user interfaces or improved personalization of an application upon identification to the system. Individuals should be able to set their own policies regarding the privacy and confidentiality of their personal information.
This paper concluded with an illustrative example incorporating and overlaying the four techniques described by Zurko into a commercially available system development life-cycle methodology for improving the development of user-centered security. These included a security and privacy risk analysis during the systems requirements analysis phase, a modified protocol analysis during the Solution Definition phase, a full protocol analysis during the design phase and a contextual inquiry in the form of experiments and questionnaires during the post production phase.
Adams, A.;
Sasse, M.A.; “Users are not the enemy”; Communications of the ACM; v42(12); Dec.
1999, pp 40-46.
Cowart, R.; "Mastering Windows", Sybex Inc., Alameda, CA, 1995.
Ellis, Clarance A., Gibbs, S.J., and Rein, G.L. “Groupware: Some Issues and Experiences”
Communications of the ACM, v34n1, Jan 1991, p.38-58.
El Sawy, O.; Malhotra, A.; “IT-Intensive Value Innovation in the Electronic Economy: Insights from Marshall Industries”; MIS Quarterly; vol. 23(3), 1999; pp. 305-336.
Fenn, J; Linden, A.; Gartner Group, Inc. April 18, 2000
Twelve Technologies for 2000-2010.
Hunter, R; Malik, W.; “Your Data or your
Life”; Gartner Group Inc.; 12/07/2000
King, Elliot, “From e-commerce to e-business"; Enterprise Systems Journal; Dallas; vol. 15(1), Jan 2000, Start page: 16.
NUA Internet Surveys; NUA
LTD; New York, NY; 2000 including data from Forrester Research; http://www.nua.ie
Passori, A.; “Enterprisewide Information Security Best Practices”; Meta Group Inc. ; 12/04/00
Interactions, ACM; Volume 2 , Issue 1 (1995) ; Pages 27-31
PriceWaterhouseCoopers
L.L.P (PWC).; “Summit Systems Delivery Methodology (Summit D)”; Version 5.0;
1996-1997.
Rindfleisch,
T.; “Privacy, information technology and health care”; Communications of the
ACM; vol 40(8); Aug. 1997; pp 92-100.
