Software Requirements Specification Template - users at Marshall

Software Requirements Specification for

LockoutII Version 1.0 approved

Prepared by Alex M. King

Marshall University

September 29, 2012

Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Software Requirements Specification for

Page ii

Table of Contents Table of Contents .......................................................................................................................... ii Revision History ............................................................................................................................ ii 1. Introduction ..............................................................................................................................1 1.1 1.2 1.3 1.4 1.5

Purpose .......................................................................................................................................... 1 Document Conventions .................................................................................................................. 1 Intended Audience and Reading Suggestions ................................................................................. 1 Project Scope ................................................................................................................................. 1 References ...................................................................................................................................... 1

2. Overall Description ..................................................................................................................2 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Product Perspective ........................................................................................................................ 2 Product Features ............................................................................................................................. 2 User Classes and Characteristics .................................................................................................... 3 Operating Environment .................................................................................................................. 4 Design and Implementation Constraints ......................................................................................... 4 User Documentation....................................................................................................................... 4 Assumptions and Dependencies ..................................................................................................... 4

3. System Features .......................................................................................................................4 3.1 System Feature 1 ........................................................................... Error! Bookmark not defined. 3.2 System Feature 2 (and so on) ........................................................ Error! Bookmark not defined.

4. External Interface Requirements ...........................................................................................5 4.1 4.2 4.3 4.4

User Interfaces ............................................................................................................................... 7 Hardware Interfaces ....................................................................................................................... 8 Software Interfaces ......................................................................................................................... 8 Communications Interfaces ............................................................................................................ 8

5. Other Nonfunctional Requirements .......................................................................................8 5.1 5.2 5.3 5.4

Performance Requirements ............................................................................................................ 8 Safety Requirements ...................................................................................................................... 8 Security Requirements ................................................................................................................... 8 Software Quality Attributes ............................................................................................................ 9

6. Other Requirements ................................................................................................................9 Appendix A: Glossary ....................................................................................................................9 Appendix B: Analysis Models .....................................................................................................10 Appendix C: Issues List ...............................................................................................................10

Revision History Name

Date

Reason For Changes

Version

Alex King

9/29/12

Document Creation

1.0

Software Requirements Specification for LockoutII Page 1

1. Introduction 1.1 Purpose This SRS describes LockoutII version 1.0. The scope of this SRS describes the LockoutII version 1.0 system in its entirety.

1.2 Document Conventions Priorities for higher level requirements are assumed to be inherited by detailed requirements.

1.3 Intended Audience and Reading Suggestions The intended audience for this document includes the LockoutII stakeholders and developers. Stakeholders and software developers can read through this document consecutively, proceeding through the sections in ascending order. The section most pertinent to the majority of stakeholders is section 2, which provides an overall description of LockoutII. The most pertinent section for developers will be section 3, which describes the system features, and section 4, which describes the external interface requirements. In addition, section 5 covers nonfunctional requirements and section 6 covers all other requirements not covered in the other sections.

1.4 Project Scope The scope of the initial release is described the LockoutII Vision and Scope document which is located at http://users.marshall.edu/~king184/documents/visionScope.pdf.

1.5 References Documents referenced here can be found at http://users.marshall.edu/~king184/LockoutII.html. Specifically the Vision and Scope is located at http://users.marshall.edu/~king184/documents/visionScope.pdf. Information on keystroke metrics can be found in: Shimson, T., Moskovitch, R., Rokach, L., & Elovici, Y. (2010). Continuous verification using keystroke dynamics. In 2010 International conference on computational intelligence and security (pp. 411-415).


2. Overall Description 2.1 Product Perspective Current security systems authenticate users with something the user knows (e.g. username and password), something the user has (e.g. id and token), or something the user is (e.g. fingerprint or retinal scans). These authentication systems are vulnerable, because they only authenticate the user once. Also, in the case of passwords or tokens, they can be lost, cracked, stolen, given away, or otherwise social engineered, and in the case of fingerprint and retinal scans they require extra hardware and could be considered obtrusive. A solution to this would be to authenticate the user continuously, based on his or her unique typing patterns. This is called keystroke biometrics. Keystroke biometrics cannot be mimicked, lost, or stolen; it does not require extra hardware, and it does not require the user to present a body part for scanning purposes. LockoutII is a keystroke biometric system that will improve upon existing systems in that it will be an open-source, clientside, continuous (i.e. free-text) authentication system that will evolve with the user’s typing behavior. LockoutII will operate “behind the scenes” authenticating the user as he or she accomplishes other tasks. LockoutII is the successor of Project Lockout. However, LockoutII will be a fundamentally different system. Project Lockout is a Chrome browser extension written primarily in JavaScript, whereas LockoutII is a Windows desktop application written in C#. Additionally LockoutII will utilize different statistical algorithms, and it will involve adaptive learning technology. All in all LockoutII will be a new, self-contained product.

2.2 Product Features LockoutII will have the following major features: MF1. Open Source The source code for LockoutII will be made available on Bit Bucket after May 20, 2013. MF2. Client Side LockoutII will be self-contained on a user’s workstation. It will not require the use of an outside server. MF3. Continuous Authentication LockoutII will continuous authenticate users as they are logged on to a desktop computer. MF4. Allow Multiple Users LockoutII will store data for multiple users on one computer. MF5. Efficient Algorithm LockoutII will utilize a statistical algorithm that minimizes the number of falsely reject users and the number of falsely accepted attackers. MF6. Adaptive Learning Template LockoutII will modify its data as there users typing evolves. MF7. Allow/Deny Log LockoutII will log the times a user is authenticated or denied. MF8. Security User templates and allow/deny logs cannot be modified.


2.3 User Classes and Characteristics None of the user classes listed requires anything beyond a basic knowledge of how to use a Windows computer. User classes 1 through 4 are all critical to the basic functions of LockoutII, whereas user classes 5 and 6 are less important. The frequency of use for each user class will be in the following order: U.C. 3, U.C. 5, U.C. 4, U.C. 6, U.C. 2, and U.C. 1, with user classes 3 and 5 being used almost constantly and user class one being used once per user. The user classes are defined as follows: U.C. 1. New User Enrollment: When initially starting LockoutII, the user will need to allow LockoutII to record his or her keystroke biometric data and develop a template for the user. This template is the keystroke biometric fingerprint of that user, and it is stored in a SQLite Database. During this phase LockoutII assumes that the user is not an imposter. U.C.1 will most likely only be used once per user, but it is very important to satisfy. U.C. 2 Trust Threshold: An authorized user will be able to access a GUI where he or she can adjust the trust (or confidence) threshold of LockoutII. The trust threshold will basically be how much trust or confidence LockoutII has that the users are who they say they are before their access is restricted or revoked. U.C. 2 may be used once or twice per user, but once an acceptable trust threshold is found, it probably won’t be used that frequently, but it is very important to satisfy. U.C. 3 Continuous Authentication: When an enrolled user logs on to his or her Windows account, LockoutII will continuously monitor their keystrokes, to verify that they are authorized users, if not their access will be restricted or denied. This use case will be used most frequently, and it is very important to satisfy. U.C.4 Deny Access: If a user’s keystroke biometric data falls below LockoutII’s trust threshold. They will be logged out of the system. If other security features are in place, this should not be used frequently, however it is very important. U.C.5 Adaptive Template: If adaptive templates are checked in the GUI, LockoutII will modify a user’s template as his or her typing changes. Basically, if the keystroke metrics are still within a user’s trust threshold, but they do not exactly match the template, LockoutII will modify the template to adjust for changes in the user’s typing patterns. If the user allows adaptive technology, then it will be used frequently, but this use case is not as important as the others. U.C. 6 Allow/Deny Logs: An authorized user will be able to access a GUI where he or she can adjust the trust (or confidence) threshold of LockoutII. The allow/deny logs will be a list of times that access is allowed or denied. U.C. 3 will only be used if the user thinks an imposter attack may have happened and wishes to know when it happened. In most situations this shouldn’t be used very much, and it is less important than other use cases.


U.C. 7 Delete Account: Users can delete their accounts.

2.4 Operating Environment LockoutII will operate in a Windows7 environment and on any hardware platform that natively runs Windows7. LockoutII will require the use of an embedded SQLite database, and LockoutII must “peacefully coexist” with any other application running concurrently in Windows. That means if LockoutII denies access to a user, it be able to safely log out a user while other programs are running without a loss of data.

2.5 Design and Implementation Constraints LockoutII will be written in C# and it will use a SQLite database. Since this is a client side system, the customer will be required to manually check for updates. LockoutII will need to be secure user templates cannot be modified. This release of LockoutII will only run in Windows. Linux and Mac implementations may occur at a later date. Also, LockoutII will not require any hardware so there will be no limitations in that regard. Also this release of LockoutII will not monitor mouse clicks either, but this may be available in a future release.

2.6 User Documentation A user’s manual will be made available locally on the client’s machine and at http://users.marshall.edu/~king184/LockoutII.html. Also, a video tutorial will be made and posted on YouTube and at the link listed above.

2.7 Assumptions and Dependencies The following is a list of assumptions: A1. LockoutII will run natively in Windows7. A2. LockoutII will be able to securely utilize a SQLite Database in Windows7. A3. If LockoutII denies a user access, it will do so in a secure way without loss of data. Other dependencies for LockoutII can be found in the Vision and Scope document, located at http://users.marshall.edu/~king184/LockoutII.html.

3. System Features 3.1 User Enrollment 3.1.1

Description and Priority User enrollment involves securely creating a SQLite template for each user when they “enroll” with LockoutII. This is a high priority feature that is necessary to implement LockoutII.


3.1.2

Stimulus/Response Sequences User launches LockoutII and clicks “new user.” Then, a new window appears explaining user enrollment. While the user is logged on and in the enrollment phase, LockoutII will record the user’s keystroke biometric data into a template. This template will be used later to verify the user. Once the user logs out or opts to end the enrollment phase, the enrollment phase will be finished.

3.1.3

Functional Requirements REQ-1: Read Keystroke Data REQ-2: Statistically analyze keystroke data REQ-3: Secure communication with SQLite database REQ-4: Simple GUI

3.2 Continuous User Authentication 3.2.1

Description and Priority LockoutII will continuously authenticate an enrolled user. This is a high priority feature that is necessary to implement LockoutII.

3.2.2

Stimulus/Response Sequences When an enrolled user logs on to his or her desktop, Lockout will begin recording his or her keystroke biometric data. LockoutII will compare the data to a predefined template to allow, deny, or restrict access to the user accordingly.

3.2.3

Functional Requirements REQ-1: Read Keystroke Data REQ-2: Statistically analyze keystroke data REQ-3: Securely query SQLite database REQ-4: Statically compare user input to user template. REQ-5: Lock the computer if user goes below trust threshold. REQ-6: Operate “behind the scenes” with little CPU footprint.

3.3 Lock out Impostors 3.3.1

Description and Priority If a user is determined to be an impostor, LockoutII will immediately lock that user out of the operating environment. This is a high priority feature that is necessary to implement LockoutII.

3.3.2

Stimulus/Response Sequences If the user’s keystroke input does match the predefined user template to such a degree that LockoutII’s trust threshold is breached. LockoutII will immediately lock the user’s computer.

3.3.3

Functional Requirements REQ-1: REQ-2: REQ-2:

Read keystroke data Statistically analyze keystroke data Securely query SQLite database


REQ-3: REQ-4: REQ-5:

Statically compare user input to user template. Lock the computer if user goes below trust threshold. Successfully communicate with Windows to initiate a lockout.

3.4 Algorithmic Efficiency 3.4.1

Description and Priority LockoutII will utilize a statistical algorithm that minimized False Rejection Rate (FRR) and False Acceptance Rates (FAR). Also, this algorithm will not monopolize the CPU. An efficient algorithm is high priority.

3.4.2

Stimulus/Response Sequences When a user enters keystroke data. That data must be statistically compared to a predefined user template. This statistical comparison must be accurate and efficient.

3.4.3

Functional Requirements REQ-1: REQ-2: REQ-3:

Minimize FRR Minimize FAR Small CPU footprint

3.5 Adaptive Learning 3.5.1

Description and Priority LockoutII will modify an authentic user’s template as his or her typing style changes. This is of medium priority.

3.5.2

Stimulus/Response Sequences If a user’s typing shows a consistent change in pattern. LockoutII will modify that user’s template accordingly.

3.5.3

Functional Requirements REQ-1: Read Keystroke Data REQ-2: Statistically analyze keystroke data REQ-2: Securely query SQLite database REQ-4: No increase in FAR

3.6 Allow/Deny Log 3.6.1

Description and Priority LockoutII will keep a timestamp log of times an authenticated user was logged on and when a lockout occurs. This is of medium priority.

3.6.2

Stimulus/Response Sequences LockoutII will keep a record of when an authenticated user logs on, when an authenticated session ends, and when a lockout occurs. This data can be viewed by authenticated users in Lockout’s GUI.

3.6.3

Functional Requirements


REQ-1: Keep a time stamp record of when a user logs on REQ-2: Keep a time stamp record of when an authenticated session ends REQ-3: Keep a time stamp record of when a lockout occurs REQ-4: Query a SQLite database REQ-5: Put data in usable format

3.7 Multiple Users 3.7.1

Description and Priority Any instance of LockoutII will allow for multiple users. This is of low priority.

3.7.2

Stimulus/Response Sequences The GUI for Lockout will have an option to add a new user. If a new user is added, the enrollment phase will be initiated and a new template is made.

3.7.3

Functional Requirements REQ-1: REQ-2: REQ-3: REQ-4:

Read Keystroke Data Statistically analyze keystroke data Securely query SQLite database Recognize multiple users.

4. External Interface Requirements 4.1 User Interfaces

User:

Regular user can access LockoutII GUI via a static authentication. A user can enable or disable adaptive learning, toggle a trust threshold, access help files, and access an allow/deny log. Also a user can delete their account. Users accessing the GUI will be required to enter some sort of static text.

New User (Enrollment):

An unauthenticated user can click enroll. They are prompted for a username. And they can begin an enrollment session where a template will be created for them.

Allow/Deny Logs:

Users accessing the GUI can view time stamped logs of when an authenticated user began a session and when that user ended a session. They will also see lockout times.


4.2 Hardware Interfaces LockoutII must interface with keyboard input from a computer to read in keystroke metrics.

4.3 Software Interfaces Windows7 Compatible:

LockoutII will initialize when a Window logs on a user account. LockoutII will initialize a Windows lock out without corrupting data. LockoutII will use alternate processes, so impostors cannot cancel processes

SQLite Database:

LockoutII will user a SQLite database

Visual Studio 2010:

LockoutII will be developed in Visual Studio 2010

C# Language:

LockoutII will be written in C#

4.4 Communications Interfaces LockoutII will operate locally entirely on a client.

5. Other Nonfunctional Requirements 5.1 Performance Requirements LockoutII will work continuously and concurrently with a user’s tasks. LockoutII must not only quickly deny access to an impostor, but must also use a minimal amount of CPU cycles so as not to slow down a user’s tasks. LockoutII should be able to work on any workstation that natively runs Windows7.

5.2 Safety Requirements LockoutII is not directly related to any safety issues. Although it is important that no damage or loss of data occurs as a result of LockoutII locking out or denying access to a user.

5.3 Security Requirements Security is very important to LockoutII. Users will be authenticated using keystroke biometrics, and a username and password will also be required to access accounts on the GUI. Also, it is important to remove any read/write permissions on the SQLite Database.


5.4 Software Quality Attributes Availability:

LockoutII needs to be consistently available to the user.

Usability:

A simplified GUI and ease of use is the second most important quality attribute

Scalability:

Since other keystroke biometric systems work on enterprise servers. LockoutII needs to be designed with scalability in mind to remain competitive.

6. Other Requirements TBD

Appendix A: Glossary Adaptive Learning :

LockoutII will adapt to the changing typing styles of authentic users.

Allow/Deny Logs :

Timestamp log of times an authenticated user was logged on and when a lockout occurs.

Authenticate :

Verify that users are who they say are via keystroke authentication

GUI (Graphical User Interface):

This includes all aspects of LockoutII that the user will see and interact with on their screen.

Impostor :

Person posing as authenticated user who isn’t who they say they are

Keystroke Biometric:

Specific measurements of how a user types, such as how long individual keys are held down or time it takes to type two or more consecutive keys, used to uniquely identify a user. A diagram of the different keystroke metrics is available in appendix A.

Session:

The time a person logs into a Windows computer

Template:

A user’s unique keystroke biometric data stored in a SQLite database.

Trust Threshold (Confidence Level):

Level of trust that the system has that the user is who they say they are

User:

Person using LockoutII

Workstation:

Windows desktop computer, laptop, or PC


Appendix B: Analysis Models Keystroke Metrics (Shimson et al, 2010):

System Architecture:

Appendix C: Issues List TBD