dss 12 s4 03 requirementspecificationv0.9

7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9

http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 1/20

School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project

Requirement Specification10 December 2012

Group: SS12/4B

Khoo Jun Xiang 4000766 [email protected]

Ang Wencan Stephen 4194032 [email protected]

Goh Kheng Siang Joel 4187490 [email protected]

Lim Sing Hui 4185948 [email protected]

Low Jia Hui 4186448 [email protected]

Supervisor: Mr Sionggo Jappit

Assessor: Mr Tan Kheng Teck

Document ControlTitle: Requirement Specification

Document Name: Software Requirement Specification



Requirement Specification [SS12/4B]

of 20

Owner Current VersionLast Change on

Approved byDate Time

Khoo JunXiang V0.9 10-Dec-2012 8pm Project Manager

Distribution List

Name Title/Role Where

Mr Sionggo Jappit Supervisor SIM-UOWMr Tan Kheng Teck Accessor SIM-UOWKhoo Jun Xiang Project Manager SIM-UOWLow Jia Hui Software Architect SIM-UOWGoh Kheng Siang Joel Test Designer SIM-UOWLim Sing Hui UI Designer SIM-UOWStephen Ang Database Designer SIM-UOW

Record of Revision

Revision Date Description Section Affected Changes Made byVersion after

Revision

23/11/2012 Introduction & Glossary Introduction/Glossary Low JiaHui V0.1

7/12/2012 Update of Introduction & Glossary Introduction/Glossary Khoo JunXiang V0.2

7/12/2012 Added General Description General Description Khoo JunXiang V0.3

7/12/2012 Identification of Use Cases and

Actors

Functional

requirements

Low JiaHui, Khoo

JunXiang

V0.4

8/12/2012 Update and finalize use case diagram Functional

requirements

Low JiaHui, Khoo

JunXiang

V0.5

9/12/2012 Added textual description for use

cases

Functional

requirements

Low JiaHui, Khoo

JunXiang

V0.6

10/12/2012 Identify and added non-functional

requirements

Non-functional

requirements

Khoo JunXiang V0.7

10/12/2012 Identify and added other

requirements and constraints

Other requirements,

constraints

Khoo JunXiang V0.8

10/12/2012 Checking and finalizing document All Khoo JunXiang,

Low JiaHui

V0.9




of 20

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




of 20

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.




of 20

2. GlossaryEXPLANATION

Requirements

Elicitation Approaches

Requirements elicitation itself is a very complex process involving many activities,

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 role-

playing.

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.

DB-Wrapper The product this document is specifying. DB-Wrapper acts as a filtering wrapper

around the database which provides inference protection.

SRS Software Requirement Specification

SQL Database transaction language

Oracle XE 10g 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

DBA Database Administrator

SQL*Plus Oracle utility, basic command-line interface which helps users, administrators and

programmers to access data

Use case A list of steps which define the interactions between a role and a system to achieve a

function.

Use Case diagram Graphical representation of a user’s interaction with the system and depicting the

specifications of a use case.

Functional

requirements

Defines the capabilities and functions that a system be able to perform.

Non-Functional

requirements

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




of 20

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, beforedisplaying it to the user.

3. Query set size control – Allows only those queries that is within a certain bound size. The lower andupper 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 byentering 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 willopen 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 executequeries 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 musthave the capabilities to install and run Oracle.




of 20

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 casemodeling 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 descriptionwill 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 aDB-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.




of 20

Actor Description:

User: All users of the database system.

Administrator: Having the privileges to view LOGFILES and update bound size for “Query Set-Sizecontrol”. Default username is “admin”. Default password is “password123”.

Use Case Textual Description:

Use Case: Login

Primary Actor: User, Administrator

Description: This use case handles login for the user. Authentication will be done so that if adminentered 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.

Pre-condition: NIL

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.

Extensions2a. Do not have an account.

2a1. Request for username and password from the administrator. Administrator will create new login detailsfor 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.




of 20

Use Case: Authentication

Primary Actor: User, Administrator Description: Authenticate login details inputs.

Pre-condition: User must be logged in.

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

Extensions NIL

Use Case: Redirect login

Primary Actor: User, Administrator Description: Login details will be redirected

Pre-condition: 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: Make Query

Primary Actor: User

Description: This use case handles submitting of query request for the user. Error messages will bedisplayed if SQL statement is not valid.

Pre-condition: 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 information1b1. 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.




of 20

Use Case: Query Filter

Primary Actor: User Description: 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.Pre-condition: Query is submitted to process for results


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 anysyntax 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.

Extensions3a 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.




of 20

Use Case: Check Overly - Selective

Primary Actor: User Description: 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.Pre-condition: Query is submitted to process for results


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: Check Non-aggregations

Primary Actor: User.

Description: This use case handles all the verification of query request for the user to determine if thequery made consist of non-aggregation SQL function calls. Query will be rejected if so.

Error message will be displayed.

Pre-condition: Query is submitted to process for results


1.

User login to the system.2. Query is made and submitted for verification3. Ensure the query does not contain non-aggregation functions

Extensions3a. The query is identified to contain non-aggregation query.





of 20

Use Case: Check Set-size

Primary Actor: User.Description: 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 theupper bound set size. Query will be rejected if so. Error message will be displayed.Pre-condition: Query is submitted to process for results


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 bounddeclared in the set size.

Extensions

3a. Result of query is more than the upper bound or less than the lower bound size.


Use Case: Check Log

Primary Actor: User.

Description: 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 queriesshow signs of inference attack

Pre-condition: 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 pastqueries

Extensions3a The query that result in returning a result which will compromise the security by inference attack when

use along with previous queries3a1 The query will be rejected and log into the logfiles for further uses. Use case ended.




of 20

Use Case: Display Query Result

Primary Actor: NILDescription: System will generate result from a query made by a user. Result returned might be in a

range or might be rounded up.Pre-condition: A query must be made. System must determine whether to round up the result valuedisplay a range where the result will be in.


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: Return range value

Primary Actor: NILDescription: System will display a range where the result will be in.Pre-condition: 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.




of 20

Use Case: Systematic Rounding

Primary Actor: NILDescription: System will round up the result value.

Pre-condition: 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.


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: View LogFiles

Primary Actor: Administrator Description: 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 improvethe DB-Wrapper functionality then can be done accordingly.

Pre-condition: Administrator must be logged in as admin.


1. Administrator login to the system as admin.

2. Administrator enters command “OPEN Error LOGFILE” or “OPEN Success LOGFILE”. – DB Wrapper willopen the respective log files in a new window.3. Administrator view log file.

Extensions NIL




of 20

Use Case: Set bound size

Primary Actor: Administrator Description:

Pre-condition: 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




of 20

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

Explanation

1 Operational requirements 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.

2 Performance requirements 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.

3 Interface requirements There won’t be much user interface for the user as DB-

wrapper will only sit on top of its Oracle Database and

filter results or user queries. The main interface will comefrom 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




of 20

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.

5 Security requirements 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.

6 Portability requirements 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.

7 Authorization requirements 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.




of 20

4.3 Other Requirements

S/N Other Requirements Explanation

1 Documentation requirements 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.




of 20

5. Main Constraints1. 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

dss 12 s4 03 requirementspecificationv0.9

Documents