School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project Requirement Specification 27 December 2012

Group: SS12/4B Khoo Jun Xiang Ang Wencan Stephen Goh Kheng Siang Joel Lim Sing Hui Low Jia Hui 4000766 4194032 4187490 4185948 4186448
Jxkhoo001@mymail.sim.edu.sg Wsang003@mymail.sim.edu.sg Ksgoh006@mymail.sim.edu.sg Shlim035@mymail.sim.edu.sg Jhlow010@mymail.sim.edu.sg

Supervisor: Mr Sionggo Jappit Assessor: Mr Tan Kheng Teck

Requirement Specification

[SS12/4B]

Document Control
Title: Document Name:
Owner Khoo JunXiang Distribution List Name Mr Sionggo Jappit Mr Tan Kheng Teck Khoo Jun Xiang Low Jia Hui Goh Kheng Siang Joel Lim Sing Hui Stephen Ang

Requirement Specification DSS-12-S4-03_RequirementSpeification.doc

Current Version V1.0 Last Change on Date 27-Dec-2012 Time 5pm Approved by Project Manager

Title/Role

Where

Supervisor Accessor Project Manager Software Architect Test Designer UI Designer Database Designer

SIM-UOW SIM-UOW SIM-UOW SIM-UOW SIM-UOW SIM-UOW SIM-UOW

Record of Revision Revision Date 23/11/2012 7/12/2012 7/12/2012 7/12/2012 8/12/2012 9/12/2012 10/12/2012 10/12/2012 10/12/2012 27/12/2012 Description Introduction & Glossary Update of Introduction & Glossary Added General Description Identification of Use Cases and Actors Update and finalize use case diagram Added textual description for use cases Identify and added non-functional requirements Identify and added other requirements and constraints Checking and finalizing document Added new functionality Section Affected Introduction/Glossary Introduction/Glossary General Description Functional requirements Functional requirements Functional requirements Non-functional requirements Other requirements, constraints All Functional requirements Changes Made by Low JiaHui Khoo JunXiang Khoo JunXiang Low JiaHui, Khoo JunXiang Low JiaHui, Khoo JunXiang Low JiaHui, Khoo JunXiang Khoo JunXiang Khoo JunXiang Khoo JunXiang, Low JiaHui ALL Version after Revision V0.1 V0.2 V0.3 V0.4 V0.5 V0.6 V0.7 V0.8 V0.9 V1.0

Page 2 of 20

Requirement Specification

[SS12/4B]

Contents
................................................................................................................................................................... 1 Document Control ..................................................................................................................................... 2 1. Introduction ....................................................................................................................................... 4 1.1 Purpose............................................................................................................................................ 4 1.2 Scope ............................................................................................................................................... 4 1.3 Approach ......................................................................................................................................... 4 2. 3. Glossary ............................................................................................................................................. 5 General Description ........................................................................................................................... 6 3.1 Main Product Functions .................................................................................................................. 6 3.2 Software Functions ......................................................................................................................... 6 3.3 Hardware Functions ........................................................................................................................ 6 4. Requirements Definition.................................................................................................................... 7 4.1 Functional Requirements ................................................................................................................ 7 4.2 Non-functional Requirements ....................................................................................................... 17 4.3 Other Requirements ...................................................................................................................... 19 5. 6. Main Constraints.............................................................................................................................. 20 Appendix ......................................................................................................................................... 20

Page 3 of 20

Requirement Specification

[SS12/4B]

1. Introduction
1.1 Purpose
Software Requirements Specification (SRS) is at the Inception phrase of the RUP projects. Continuous development of SRS can also be done In Elaboration phrase. This Software Requirement Specification states the detailed requirements and specification of developing the DB-Wrapper, a database wrapper that protects against inference attacks on statistical database. It describes the functionality and features of the Database Wrapper with much consideration on the interface design, design constraints and other constraints such as performance and consistency. This document is required to help to identify the Functional, Non-Functional and Other requirements that are essential to developing the DB-Wrapper. This requires several processes such as Requirement Gathering, Requirement Analysis and Requirement Specification before separating them into different categories like Functional requirement, non-functional requirement and other requirements. Requirement Gathering uses the different methods retrieve information of what the stakeholder expects from the database wrapper. Requirement Analysis includes the process of pre-processing the requirements gathered and determine if the requirement is achievable, measureable, testable, practical and applicable to the need of the system, if the requirement does not meet the criteria mention above it will be consider to be dropped or prioritized differently

1.2 Scope
The DS-Wrapper is intended to work as a query-filter like process process filter of queries that are not allowed. The wrapper will act as a inference protection mechanism to protect the statistical database against disclosure of confidential and sensitive information and applicable on Oracle SQLite database. As part of the project, the wrapper will provide Query Restrictions, Systematic Rounding, Query set-size control and Auditing to prevent inferences attack. This will provide data confidentiality and integrity to the database. An additional graphical user-interface (GUI) will created to allow better management of the DB-Wrapper and better ease of use. This GUI will be creating using Qt development framework which allow cross platform application of different programming languages along with the GUI created.

1.3 Approach
Our group used the Requirements Elicitation Approaches to gather requirements and identify key system functionality including use cases, role-playing, stakeholders, team meeting and prototyping. Meeting between team members are held to brainstorm and do an analysis on the requirements. Detailed key actors and use cases are being drafted so that all stakeholders can easily understand them the illustrations and our members can use them as direct input for our the different components that we have to do.

Page 4 of 20

Requirement Specification

[SS12/4B]

2. Glossary
EXPLANATION Requirements elicitation itself is a very complex process involving many activities, Requirements Elicitation Approaches with multiple techniques available to perform these activities. The multi-disciplinary nature of requirements elicitation only adds to this complexity. The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the stakeholder. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use-cases and roleplaying. Inference Attack Inference Attack is a data mining technique performed by analyzing data in order to illegitimately gain knowledge about a subject or database. Attackers derive sensitive data using queries that pose to reveal only non-sensitive data. The product this document is specifying. DB-Wrapper acts as a filtering wrapper around the database which provides inference protection. Software Requirement Specification Database transaction language Oracle Database 10g Express Edition is a free version of relational database. An intuitive, browser-based interface, to administer the database, create tables, views, and other database objects, import, export, and view table data, run queries and SQL scripts, generate reports, etc Database Administrator Graphical User interface, a type of user interface that allows user to communicate to electronic devices using graphical representation instead of command line A list of steps which define the interactions between a role and a system to achieve a function. Graphical representation of a users interaction with the system and depicting the specifications of a use case. Defines the capabilities and functions that a system be able to perform.

DB-Wrapper

SRS SQL Oracle XE 10g

DBA GUI

Use case

Use Case diagram

Functional requirements Non-Functional requirements

Criteria used to judge the operation of a system, rather than specific behavior.

Page 5 of 20

Requirement Specification

[SS12/4B]

3. General Description
3.1 Main Product Functions
1. Query Restriction Filter results of every user queries. Display those results which will not cause an inference attack in statistical database. Only allow aggregate queries: SUM, COUNT, AVG, etc. Do not allow overly selective queries : SELECT WHERE income = 2500 2. Query set size control Allows only those queries that is within a certain bound size. The lower and upper bound is set based on the properties of the database and on the preferences fixed by the source code implementer, after discussion with the database administrator. Default value is one. 3. Auditing Keeping up-to-date logs of all queries made by each user and constantly checking for possible disclosures of sensitive information to unauthorized personnel, whenever a new query is issued. 4. There will be 2 LOGFILES, ERROR LOGFILES and SUCCESS LOGFILES used to store error queries and success queries respectively. Administrator able to open log files in a new window. 5. Administrators are able to update lower bound size for Query set size control. 6. Administrators are able to define and manage the access control and range of values to the attributes of the table. 7. Data Dictionary meta modeling 8. User is able to generate statistical report.

3.2 Software Functions

DB-wrapper must at the minimum be able to be configured and integrated into Oracle Database Express Edition 10g. Users are able to use the DB-Wrappers graphical user interface as command line interpreter to access the Oracle database and execute queries commands.

3.3 Hardware Functions

Although it configuration and integration of DB-wrapper must be at all platform that is able to install and run Oracle database, the minimum requirement is to run DB-wrapper in Window operating system. User PC must have the capabilities to install and run Oracle.

Page 6 of 20

Requirement Specification

[SS12/4B]

4. Requirements Definition
4.1 Functional Requirements
Functional Requirements define all the services provided by DB-Wrapper to its users. The functional requirements will be described in use-case diagrams, which is essential in requirements elicitation. Use case modeling provides a clear view of the real system needs to its stakeholders. It shows clearly different interactions that can take place between a user and a system. Narrative text used in use case textual description will allow stakeholders to easily understand the functions. Use case diagrams also ease the development team when they are trying to spot what might go wrong. The below use case diagram shows the functions provided by an oracle database system that is integrated with a DB-Wrapper. Red color use cases are the functions of DB-Wrapper. Reason behind choosing the product boundary to be Oracle DB integrated with DB-Wrapper instead of just DB-Wrapper is to let end-users have a clear view of what improvements the products will provide to the user after integration.

Page 7 of 20

Requirement Specification

[SS12/4B]

Actor Description:
User: Administrator: All users of the database system. Having the privileges to do administrative stuffs.

Use Case Textual Description:

Use Case: Primary Actor: Description: Login User, Administrator This use case handles login for the user. Authentication will be done so that if admin entered an invalid username and password, error message will be displayed. System will recognized user as administrator or normal user based on the role associated with the username after successfully logged in. NIL

Pre-condition:

Main Success Scenario: 1. Open DB-wrapper program and user will be prompt enter authentication information. 2. If already has an account, then enter username and password. 3. System will authenticate login information. If the username and password is valid, error logged in message will be displayed. 4. Login details will be redirected from DB-Wrapper to Oracle database so that DB-Wrapper will be able to identify the user. Extensions 2a. Do not have an account. 2a1. Request for username and password from the administrator. Administrator will create new login details for the user in the database. Use case resume in step 1 of main success scenario. 3a. Invalid login information 3a1. System prompts again for login information. Use case resume in step 2 of main success scenario.

Use Case: Primary Actor: Description: Pre-condition:

Authentication User, Administrator Authenticate login details inputs. User must be logged in.

Main Success Scenario: 1. Reject/Accept users based on the login details. Extensions NIL

Page 8 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Redirect login User, Administrator Login details will be redirected User must be logged in.

Main Success Scenario: 1. Login details will be redirected from DB-Wrapper to SQLite Oracle database.

2. DB-Wrapper will be able to identify the user.

Extensions NIL

Use Case: Primary Actor: Description: Pre-condition:

Make Query User This use case handles submitting of query request for the user. Error messages will be displayed if SQL statement is not valid. User is successfully login to the system

Main Success Scenario: 1. User login to the system. 2. User browses into make query page. 3. User selects and enters the options from the SQL pages. Application name, Table name, Function, constraints. 4. Users confirm the queries made. Extensions 1a. Do not have an account. 1a Request for username and password from the administrator. Administrator will create new login details for the user in the database. Use case resumes in step 2 of Main Success Scenario. 1b. Invalid login information 1b1. System prompts again for login information. Use case resumes in step 2 of Main Success Scenario. 2a. Error in statement input 2a1 System will prompt that the input is a non-SQL statement. Use case ended.

Page 9 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Filter Query User This use case handles all the verification of query request for the user to determine if the query made is legal. Error message will be displayed if the query is illegal after checking. Queries will be logged if legal. Query is submitted to process for results

Main Success Scenario: 1. User login to the system. System will wait for query input. 2. User submits the query. 3. Various checks will be executed by DB-Wrapper if SQL statement is valid and does not contain any syntax error. 4. DB-wrapper ensures the query is not overly -Selective. (Use case: Check Overly Selective) 5. DB-wrapper ensures that the result of query set size is within the lower and upper bound limit. (Use case: Check Set-size) 6. Query is legal. Proceed to log query in logfiles. Extensions 3a Query is invalid and contains syntax error. 3a1 Error message is displayed. Use case resumes in Step 2 and Main Success Scenario. 8a Query is illegal. 8a1. Reject query and display error message. Recorded into the error logfiles if query is valid but illegal. Notes: Valid query is a proper SQL statement. Invalid query is unrecognizable SQL statement with syntax errors. Illegal query is proper SQL statement that does not pass the 4 checks indicated in Step 4 to 7 of Main Success Scenario. Legal query is proper SQL statement that passes the 4 checks indicated above. Check Overly - Selective User This use case handles all the verification of query request for the user to determine if the query made will result in having a overly selective result. Query will be rejected if so. Error message will be displayed. Query is submitted to process for results

Use Case: Primary Actor: Description: Pre-condition:

Main Success Scenario: 1. User login to the system. 2. Query is made and submitted for verification 3. Ensure the query is not overly -Selective. Extensions 3a. The query is identified with overly selective query results 3a1 The query will be rejected and log into the error logfiles for further uses. Use case ended.

Page 10 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Restrict Non-aggregations User. This use case handles all the verification of query request for the user to make sure query made consist only of aggregation SQL function calls. User have to select the function in a drop down box where there are only aggregate functions. Query is submitted to process for results

Main Success Scenario: 1. User login to the system. 2. Only Aggregate functions can be selected from a drop down box. 3. User selects aggregate function accordingly and submit.

Use Case: Primary Actor: Description: Pre-condition:

View Query Result User This use case handles user viewing result of queries made by them. System must first display the results before users can view them. User must be logged in. A query must be made by the user.

Main Success Scenario: 1. User made SQL query through DB-Wrappers Graphical user interface. 2. System will generate the result and display it on the screen. 3. Users view results successfully.

Use Case: Primary Actor: Description:

Pre-condition:

Check Set-size User. This use case handles all the verification of query request for the user to determine if the query set-size is less than the query set-size defined. Query will be rejected if so. Error message will be displayed. Query is submitted to process for results

Main Success Scenario: 1. User login to the system. 2. Query is made and submitted for verification 3. Ensure the query result will not return unless query set-size is larger than the set-size declared. Extensions 3a. Result of query is more than the upper bound or less than the lower bound size. 3a1 The query will be rejected and log into the error logfiles for further uses. Use case ended.

Page 11 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Log Query User. This use case handles all the verification of query request for the user to determine if the query made is allowed and if legal the system will process that result and record the SQL statement in a auditing. Query is submitted to process for results

Main Success Scenario: 1. User login to the system. 2. Query is made and submitted for verification 3. All verification have passed and the SQL statement in determine legal. 4. The SQL statement will log within the success LOGFILES to be allow identification of previous SQL statements Extensions 3a Verification have failed. 3a1 SQL statements will not be recorded in the success LOGFILES but will be recorded in the error LOGFILES if needed as shown in Check Set-size, Check Overly Selective use cases.

Use Case: Primary Actor: Description: Pre-condition:

Display Query Result User System will generate result from a query made by a user. Result returned is in a report format. A query must be made. System must determine whether to round up the result value display a range where the result will be in.

Main Success Scenario: 1. User enters SQL queries through DB-Wrappers Graphical user interface. 2. System generate results in report format.. 3. System display result to the DB-Wrappers Graphical user interface terminal. Extensions 2a. Query made is deemed to be rejected which will be indicated by the DB-Wrapper. 2a1. System display result rejected messages instead of the original result. Use case ended.

Page 12 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Generate Report User. This use case handles all the generation of report User made queries and viewed results.

Main Success Scenario: 1. User had made query. 2. User selects the table name, attributes name and the group by attribute from drop down lists. 3. User confirmed. Report generated and stored (outfile) in PC. 4. System generate Report success message. Extensions 3a Ranges for the attributes are not set yet. 3a1 Prompt users that attribute names are not set.

Use Case: Primary Actor: Description:

Pre-condition:

View LogFiles Administrator This use case handles auditing and viewing of log files by the administrator. Administrator need to view log files for maintenance and identify any indication of inherence attack that is not identified by the system. Follow-up actions such as improve the DB-Wrapper functionality then can be done accordingly. Administrator must be logged in as admin.

Main Success Scenario: 1. Administrator login to the system as admin. 2. Administrator will select Log file from the interface 3. Administrator will enter the username of the user that he wish to view 4. Administrator will be able to view successful and unsuccessful query executed by the user 5. Administrator view log file. Extensions 3a. Invalid Username 3a1. The system will prompt User do not exist in the system

Page 13 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Set bound size Administrator This allows Admin to set the query set-size to enable the query set-size control function of the system Administrator must be logged in as admin.

Main Success Scenario: 1. Administrator login to the system as admin. 2. Administrator choose to add constraints and enters the bound size into the input provided. 3. DB-Wrapper will then update the lower bound which is the minimum limits of the query set-size. Extensions 2a. Non-integer value entered. 2a1. System will prompt the admin that the set-size bound is not updated.

Use Case: Primary Actor: Description: Pre-condition:

Create User Administrator Create new user account to access the database. User must be logged in as administrator

Main Success Scenario: 1. Browse into Create User link and enter Username, password and role for the new user 2. System will validate if user is already exist within the system 3. System will insert the new user into the database. Extensions 2a. User exist within the database 2a1. The system will prompt the Administrator that the user is already existed. Use Case: Primary Actor: Description: Pre-condition: Read In Data Dictionary Administrator System will read in Data Dictionary. The Admin required to be login in to the system.

Main Success Scenario: 1. DB-Wrapper received the directory of the Database 2. DB-Wrapper will retrieve data dictionary from application database through sqlite_master and pragma. 3. Administrator will click on the checkbox to select which information is to be added 4. DB-Wrapper will generate information and insert information into the meta-data model (DB-Wrappers database). Extensions 2a. Unable to execute SQLite Database commands 2a1. System will prompt Unable to retrieve Database Dictionary information!!

Page 14 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Manage Constraint Administrator Manage the rules applicable to each of the attributes. Administrator required to be logged in to the system.

Main Success Scenario: 1. Administrator will select Create, Update or Delete Constraints from SubMenu 2. Create and Update Constraint a. Display the application names in the drop down list. b. Administrator will select the application name from the drop down list. c. Enter the New constraint name d. Update Constraints into the Database 3. Delete Constraints a. Display the application names in drop down list b. Administrator will select the application name from the drop down list c. Display Constraint names in drop down list d. Administrator will select the Constraint name from the drop down list e. Delete Constraint from the Database Extensions 2c. Constraint name already used. 2c1. Prompt to rename constraint Use case resume in 2c. 3a. 3a1. The rules are invalid. The rules will not be accepted. And the information will roll-back to previous state

Use Case: Primary Actor: Description: Pre-condition:

Manage Range Administrator Manage the Range applicable to each of the attributes in the table. Administrator required to login to the system.

Main Success Scenario: 1. Browse into manage range 2. Administrator will select the table, application and attribute from the drop down list. 3. Administrator will enter range label, minimum value and maximum value. 4. Administrator will the press confirm/update Extensions Nil

Page 15 of 20

Requirement Specification

[SS12/4B]

Use Case: Primary Actor: Description: Pre-condition:

Manage Roles Administrator Manage the rules applicable to each of the attributes. Administrator required to be login to the system.

Main Success Scenario: 1. Administrator will select Create, Update or Delete Constraints from SubMenu 2. Create and Update Roles a. Display the application names in the drop down list. b. Administrator will select the application name from the drop down list. c. Display the Table names in the drop down list. d. Administrator will select the Table name from the drop down list. e. Enter the Roles name. f. Display Attribute name from checkboxes g. Administrator will select the series of attribute from the checkboxes h. Update Roles into the Database 3. Delete Roles a. Display the Application names in drop down list b. Administrator will select the application name from the drop down list c. Display Roles names in drop down list d. Administrator will select the Roles name from the drop down list e. Delete Roles from the Database Extensions 2e. Role name already used. 2e1. Prompt to rename role Use case resume in 2e.

Page 16 of 20

Requirement Specification

[SS12/4B]

4.2 Non-functional Requirements

Non-functional requirements are critical for the products as it specified criteria used to judge the operation of a system. Those criteria will determine the quality of the system as well as the amount of assurances provided for users.

S/N

Non-Functional Requirements
Operational requirements

Explanation

DB-wrapper must be fully operational and will always be available when users access the oracle database to do queries. It is expected to at least operate fully in Window platform. DB-wrapper must not malfunction and display information that will lead to a success in inference attack from attackers. Deficiencies during the developing and implementing process must be noted down and be solved before releasing/submitting the product. All mission performance assumptions must be documented to assist in solving current faults and future maintenance. Requirement elicitation approach is used to identify what the system must accomplish and how well. Critical and desired user performance must be established and agreed by system stakeholders. DB-wrapper needs to be able to support significant amount of users. Response time should be as short as possible and variation should be kept to the minimum. Response time requirement should be meet as the workload scales. DB-wrapper is integrated into the oracle database and will not consume much memory space. The DB Wrappers graphical user interface will allow user to execution of SQL statement on the Oracle Database, as well as allowing administrator to perform administrative actions(create user, change set-size and view log files) on the system. The GUI provides simple access control to the database and improve on the ease-ofuse of the system. Page 17 of 20

Performance requirements

Interface requirements

Requirement Specification

[SS12/4B]

Safety requirements

Safety standards must be designed during the development process to ensure safety of products, and/or processes. Necessary activities must be well-described in the standard. DB-wrapper should be as robust as possible. Development and implementation teams should develop the system with good architectural principles and good practices standard. Escalation of privileges from unauthorized personnel should not be possible. All critical-level functions will be protected against and verified in security testing. Audit log must be verbose and clear. For example, we can hash the user password during logged in and creating user process. Password stored in the database can be hashed. DB-wrapper can be integrated into any window PC provided that Oracle Database is installed in the terminal. DB-wrapper and its source code must be available in the PC in order to do so. DB-wrapper and its source code can be transferred to different terminal through the internet or external storage devices. No unauthorized personnel are able to view source code of DB-wrapper. They are also not able to obtain the actual product and its configuration files. Users can request the source code from the administrator or the development team.

Security requirements

Portability requirements

Authorization requirements

Page 18 of 20

Requirement Specification

[SS12/4B]

4.3 Other Requirements

S/N
1

Other Requirements
Documentation requirements

Explanation
All documents required stated in the timeline of the project will be completed. Table of contents of all documents must be clearly defined. Various kinds of documentation will be used. For example, diagram (use case) is used in this requirement specification document. Comments and other notations will be included in the source during implementation as a form of documentation. There will be PowerPoint slides for all presentation.

Page 19 of 20

Requirement Specification

[SS12/4B]

5. Main Constraints
1. DB-Wrapper is implemented to integrate only into Oracle Database. 2. Checking of inference and data filtering should be as fast as possible. 3. Although it configuration and integration of DB-wrapper must be at all platform that is able to install and run Oracle database, the minimum requirement is to run DB-wrapper in Window operating system DB-Wrapper must run on all platforms that can install Oracle Database. 4. SQLite and QT must be pre-installed in user terminal. 5. A database script needs to be designed, with all its tables and data, and implemented into the database to test up DB-wrapper functionalities. 6. Constant review, analyses and measurement of database data must be done to measure the amount of protection needed for each attributes. 7. Severe restriction might occur and causes the database to be deemed as useless. Users will not be able to get the most amount of information from their queries.

6. Appendix
Nil

Page 20 of 20