School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project Requirement Specification 27 February 2013

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 Ksgoh007@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 Jun Xiang 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.3 Last Change on Date 27-Feb-2013 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 26/01/2013 15/02/2013 27/02/2013 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 Checking and finalizing document Review the document Finalized the document Section Affected Introduction/Glossary Introduction/Glossary General Description Functional requirements Functional requirements Functional requirements Non-functional requirements Other requirements, constraints All Functional requirements All All All 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 Lim Sing Hui All All Version after Revision V0.1 V0.2 V0.3 V0.4 V0.5 V0.6 V0.7 V0.8 V0.9 V1.0 V1.1 V1.2 V1.3

Page 2 of 19

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 ....................................................................................................... 16 4.3 Other Requirements ...................................................................................................................... 18 5. 6. Main Constraints.............................................................................................................................. 19 Appendix ......................................................................................................................................... 19

Page 3 of 19

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 filter of queries that are not allowed. The wrapper will act as an 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 allows 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 with the illustrations and our members can use them as direct input for the different components that we have to do.

Page 4 of 19

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 19

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 LOGFILE and SUCCESS LOGFILE used to store error queries and success queries respectively. Administrators are 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 minimum able to configure and integrate 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 19

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 diagram below shows the use case diagram of 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 19

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 to 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 a 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 19

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:

View Report 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. A list of generated reports is displayed accordingly. Reports displayed are based on the role the use has. 2. Click on the Report name to view the report. 3. A report will be displayed in a pop up window. 4. Click Export button and export to excel file 5. Click Cancel button to reject Extensions NIL

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

Delete Report 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. A list of generated reports is displayed accordingly. Reports displayed are based on the role the use has. 2. User selects delete report button Only owner can delete the report he generated. 3. New list of reports is displayed. Extensions 2a. User is not the owner of the report. 2a1. System rejects deletion.

Page 9 of 19

Requirement Specification

[SS12/4B]

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

Export Report User This use case can handle the exporting of reports to excel files. User is successfully login to the system

Main Success Scenario: 1. A list of generated reports is being viewed. 2. Click on the selected report 3. Selected report is open and click the Export button and generate to text or excel file

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

Create Report 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. Select Application name from the drop down list 2. Select Table name from the drop down list Click the black button to add to the Tables Label Box 3. Select Function: COUNT, SUM or AVG Select Attribute (Depends on selected Table above, display different attributes) Click the black button to add to the Attributes Label Box 4. First drop down list: WHERE command with drop down list for either AND, OR. - Second drop down list: Depends on the selected Table above, display different attributes - Third drop down list: Sign for greater, lesser or equals to range. - Textbox to enter the range number. Click the black button to add to the Constraints Label Box 5. Select the Group by attribute from the Drop down list. 6. Select the attributes wanted from the three Label Boxes on the right column 7. Click the Add button 8. Query will be created and shown at the bottom label box. 9. Click OK button 10. A popped up dialog box to view query result 11. Click Generate button or Cancel button Extensions 2a More than 1 table is selected. Join is required. 2a1 Click and select another Table name from the drop down list 2a2 Repeat steps 3, 4, 5, 6 and 7 2a3 A popped up dialog box Join Option for request to join more than one table selected. JOIN required. 2a4 Select from drop down list: JOIN, CROSS JOIN, LEFT OUTER JOIN or NATURAL JOINT 2a5 Select from the two drop down lists, the two wanted tables to join.

Page 10 of 19

Requirement Specification

[SS12/4B]

2a6 2a7 2a8 2a9

Join Statement is formed and press done to confirm. Click Back button and the query that is joined will be displayed. Click Create button to generate report and store in DB wrapper Click Cancel button to return

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. Dropdown selection is provided by DB-Wrapper so that SQL statement is valid and does not contain any syntax error. 4. DB-wrapper ensures the query range input is not out of bound 5. DB-wrapper ensures that the result of query set size is within the lower and upper bound limit. 6. Query is legal. Proceed to log query in log files Extensions 6a Query is illegal. 6a1. Reject query and display error message. Recorded into the error log files if query is valid but illegal. Notes: Valid query is a proper SQL statement Illegal query is proper SQL statement that does not pass the 2 checks indicated in Step 4 and 5 of Main Success Scenario Legal query is proper SQL statement that passes the 2 checks indicated above

Use Case: Primary Actor: Description:

Pre-condition:

View Log Files 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. Enter a valid username 2. There are two columns shown empty, SUCCESSFUL and UNSUCCESSFUL buttons. 3. Click on either one for log information.

Page 11 of 19

Requirement Specification

[SS12/4B]

Extensions 1.1 Entered invalid username. 1.2 Display prompt message User not found! 1.3 Use case resume in step 2 for a main success scenario.

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

Manage Application Administrator System will read in Data Dictionary. Administrator required to be logged in to the system

Main Success Scenario: 1. Enter the Application Database 2. Click OK button 3. Display message prompt Please select a Table 4. Tick the checkboxes for attributes of the Table 5. Click Submit button 6. Proceed to read in Meta-Data 7. Display message Meta-Data read in successfully! 8. Default value for set size constraint is added for the application. Extensions 1a Display message prompt Invalid Database! 1a1 Re-typed the correct Application name

1a2

Use case resume in step 4 for a main success scenario.

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. Select Application name from the dropdown list 2. Select Table name from the dropdown list 3. Select Attribute name from the dropdown list 4. Enter the minimum and maximum value 5. Click OK button Extensions Nil

Page 12 of 19

Requirement Specification

[SS12/4B]

Use Case: Manage Constraint Primary Actor: Administrator Description: Manage the rules applicable to each of the attributes. Pre-condition: 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 Constraint a. Select Application name from the dropdown list b. Select Constraint name from the dropdown list c. Enter a value number d. Click OK button e. Proceed to add constraint in database f. Display message Constraint added for selected Application 3. Update Constraint a. Select Application name from the dropdown list b. Select Constraint name from the dropdown list c. Enter a value number (This is to set bound size) d. Click OK button (Execute the set bound size step) e. Proceed to update constraint in database f. Display message Constraint updated for selected Application 4. Delete Constraint a. Select Application name from the dropdown list b. Select Constraint name from the dropdown list c. Click OK button d. Proceed to delete constraint in database e. Display message Constraint deleted for selected Application Extensions NIL

Page 13 of 19

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 login to the system.

Main Success Scenario: 1. Administrator will select Create, Update or Delete Constraints from SubMenu 2. Create Role a. Enter a new role name b. Tick the associated application database in the check box c. Click OK button d. A scroll box column will popped up on the right side e. According to selected application, tick associated table f. Click Create button g. Proceed to add role in database h. Display message Role: new role name successfully added. 3. Update Role a. The new role name is directly updated at the role name dropdown list b. Select a role name from the role name drop down list c. Tick the associated application database in the check box d. Click OK button e. A scroll box column will popped up on the right side f. According to selected application, there are selected tick associated table shown g. Proceed to update role in database by ticking the wanted tables h. Display message Role: role name successfully updated. 4. Delete Role a. Updated role names are at the role name dropdown list b. Select a role name from the role name drop down list c. Proceed to delete role in database d. Display message Role: role name successfully deleted. Extension3 4b Delete unsuccessful due to user associated with role 4b.1 Users with the selected role from drop down list are displayed in the box 4b.2 Click the user that is displayed in the box and a popped out window is shown 4b.3 Reselect the user role from dropdown list and click OK button 4b.4 Use case resume in step 4c for a main success scenario.

Page 14 of 19

Requirement Specification

[SS12/4B]

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

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

Main Success Scenario: 1. Administrator will select Create, Update or Delete Constraints from Sub Menu 2. Create User a. Enter a new username (length must be more than 7) b. Enter a password (Must contain upper case) c. Retyped to confirm the password d. Select the role from the drop down list (Normal user or Administrator) e. Click OK button f. Proceed to create username in database g. Display message Account: new username successfully added. 3. Update User a. The new username is directly updated at the username dropdown list b. Select a username from the username drop down list c. Tick the required checkbox either to change password, role or both. d. Click OK button e. Proceed to update user in database f. Display message Account: username successfully updated. 4. Delete User a. Display the usernames in drop down list b. Select a user from the drop down list c. Click OK button d. Proceed to delete user in database e. Display message Account: username successfully deleted. Extensions 3c. Different update option. Change role or password. 3c.1 - Tick checkbox for change of new password - Re-typed to confirm new password 3c.2 3c3 - Tick checkbox for change of role - Select role from dropdown list Use case resume in step 3d in main success scenario.

Page 15 of 19

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 16 of 19

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 17 of 19

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 18 of 19

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 19 of 19