School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project Requirement Specification 10 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

Document Control
Title: Document Name: Requirement Specification Software Requirement Specification

Requirement Specification

[SS12/4B]

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

Current Version V0.9

Last Change on Date 10-Dec-2012 Time 8pm

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 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 Section Affected Introduction/Glossary Introduction/Glossary General Description Functional requirements Functional requirements Functional requirements Non-functional requirements Other requirements, constraints 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 Version after Revision V0.1 V0.2 V0.3 V0.4 V0.5 V0.6 V0.7 V0.8 V0.9

Page 2 of 20

Requirement Specification

[SS12/4B]

Contents
Document Control .................................................................................................................................... 1 1. Introduction ....................................................................................................................................... 4 1.1 Purpose............................................................................................................................................ 4 1.2 Scope ............................................................................................................................................... 4 1.3 Approach ......................................................................................................................................... 4 2. Glossary ............................................................................................................................................. 5 3. 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. Main Constraints ............................................................................................................................. 20 6. 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-express edition 10G. 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.

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 Requirements elicitation itself is a very complex process involving many activities, 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 Oracle utility, basic command-line interface which helps users, administrators and programmers to access data 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 SQL*Plus

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 Only return the range it belongs to rather than exact values for sensitive data : Income ($2000-$3000) : 100-150 records found 2. Systematic Rounding Round query result, to the nearest multiple of a certain base b, before displaying it to the user. 3. 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. 4. 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.

5. 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 by entering command OPEN Error LOGFILE or OPEN Success LOGFILE in SQL *PLUS. 6. Administrator able to update upper and lower bound size for Query set size control by entering command SET UPPER BOUND = ____ or SET LOWER BOUND = ____. DB Wrapper will open update the upper or lower bound respectively.

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 SQL *Plus to as command line interface 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. Use Case Diagram:

The above 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 view LOGFILES and update bound size for Query Set-Size control. Default username is admin. Default password is password123.

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 login ID after successfully logged in. NIL

Pre-condition:

Main Success Scenario: 1. Open command prompt and type in SQL *Plus. - System will ask for username and password 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.

Page 8 of 20

Requirement Specification

[SS12/4B]

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 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 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 enters the SQL queries. System will verify if it is a valid SQL statement. 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. Input is not a valid SQL statement 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:

Query Filter 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 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 the query is Non-aggregation (Use case: Check Non-Aggregation) 6. DB-wrapper ensures that the result of query set size is within the lower and upper bound limit. (Use case: Check Set-size) 7. DB-wrapper checks against Log records that nothing can be infer from the query. (Use case: Check log) 8. 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.

Page 10 of 20

Requirement Specification

[SS12/4B]

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

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

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.

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

Check Non-aggregations User. This use case handles all the verification of query request for the user to determine if the query made consist of non-aggregation SQL function calls. 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 does not contain non-aggregation functions Extensions 3a. The query is identified to contain non-aggregation query. 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:

Check Set-size User. This use case handles all the verification of query request for the user to determine if the query made will return a result that is less than the lower bound set size or more than the upper bound set size. 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 will not return a query result that is out of the range of the upper and lower bound declared in the set size. 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.

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

Check Log User. This use case handles all the verification of query request from the user. It determine whether the query made when compared with other information of previous queries show signs of inference attack 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 will not return a query result which can be use to infer information with multiple past queries Extensions 3a The query that result in returning a result which will compromise the security by inference attack when use along with previous queries 3a1 The query will be rejected and log into the logfiles for further uses. Use case ended.

Page 12 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 Non-aggregations and Check Overly Selective use cases.

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 enter an SQL query through SQL *Plus interface. 2. System will generate the result and display it on the screen. 3. Users view results successfully.

Page 13 of 20

Requirement Specification

[SS12/4B]

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

Display Query Result NIL System will generate result from a query made by a user. Result returned might be in a range or might be rounded up. 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 enter an SQL query through SQL *Plus interface. 2. System randomly selects whether to display range value of result or rounded up value of result. 3. System display result to the SQL *Plus 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.

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

Return range value NIL System will display a range where the result will be in. A query must be made. System must select to return the range value where the result will be in instead of systematic rounding.

Main Success Scenario: 1. DB-Wrapper received SQL query from user input. SQL query is not rejected. 2. DB-Wrapper generated results and randomly selected to display a range where the result will be in. 3. DB-Wrapper generates the range. 4. DB-Wrapper display the range value to the SQL *Plus 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 14 of 20

Requirement Specification

[SS12/4B]

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

Systematic Rounding NIL System will round up the result value. A query must be made. System must select to do systematic rounding instead of selecting to return the range value where the result will be in.

Main Success Scenario: 1. DB-Wrapper received SQL query from user input. SQL query is not rejected. 2. DB-Wrapper generated results and randomly selected to display a range where the result will be in. 3. DB-Wrapper generates the range. 4. DB-Wrapper display the range value to the SQL *Plus 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.

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 enters command OPEN Error LOGFILE or OPEN Success LOGFILE. DB Wrapper will open the respective log files in a new window. 3. Administrator view log file. Extensions NIL

Page 15 of 20

Requirement Specification

[SS12/4B]

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

Set bound size Administrator Administrator must be logged in as admin.

Main Success Scenario: 1. Administrator login to the system as admin. 2. Administrator enters command SET UPPER BOUND = ____ or SET LOWER BOUND = ____. DB Wrapper will open update the upper or lower bound respectively. Extensions NIL

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
1

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. There wont be much user interface for the user as DBwrapper will only sit on top of its Oracle Database and filter results or user queries. The main interface will come from the Oracle Database itself using SQL *Plus utility. Integrate steps should be clear and simple for users with no technical knowledge to set up. User should be assumed to have no technical knowledge and able to use the Page 17 of 20

Performance requirements

Interface requirements

Requirement Specification

[SS12/4B]

program without any special training. 4 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. 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. SQL *Plus 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
None

Page 20 of 20