DSS 12 S4 03 Design Specification

School of Computer Science & Software Engineering
Bachelor of Computer Science (Digital Systems Security)
CSCI321- Project Design 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
Design Specification
[SS12/4B]
Document Control
Title: Document Name:
Owner Khoo Jun Xiang
Design Specification Design Specification

Current Version V1.5 Last Change on Date 27-Feb-2013 Time 8PM Approved by Project Manager
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 Record of Revision Revision Date 10/12/2012 12/12/2012 13/12/2012 13/12/2012 15/12/2012 15/12/2012 16/12/2012 17/12/2012 17/12/2012 18/12/2012 18/12/2012 20/12/2012 20/12/2012 27/12/2012 15/02/2013 27/02/2013 Description
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

Version after Revision 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
Section Affected All All Introduction System Design System Design Modules Design Modules Design Modules Design Modules Design Modules Design, Sematic Data Database Design Sematic Data Model Modules Design , Sematic Data ALL ALL ALL
Changes Made by Khoo Jun Xiang ALL Khoo Jun Xiang ALL Lim Sing Hui, Stephen Ang Low Jia Hui Goh Kheng Siang, Jia Hui, Jun Xiang ALL Goh Kheng Siang Khoo Jun Xiang Stephen Ang Goh Kheng Siang ALL ALL Lim Sing Hui Khoo Jun Xiang
Document Creation- Briefing and assign tasks Added all section. A draft of proposal. Added Document Preview, Project Overview, Project Scope Added System Architecture, Detailed Components, Modules Design System Architecture Component Produce Use Case Diagram Produce Activity Diagram and explaination, ERD Produce Sequence, State Diagrams Design User Interface Update of Diagram Design Database Update on Design User Interface Update on all Diagrams Final Review - Preliminary Update on diagrams Finalize the document
1.1 1.2 1.3 1.4 1.5
Page 2 of 48
[SS12/4B]
Contents
...................................................................................................................................................................1 Document Control .....................................................................................................................................2 1. Introduction ........................................................................................................................................4 1.1. 1.2. 1.3. 2. Document Preview ......................................................................................................................4 Project overview .........................................................................................................................4 Project Scope...............................................................................................................................4
Systems Design ..................................................................................................................................5 2.1. 2.2. 2.2.1. Systems Architecture ..................................................................................................................6 Detail Components / Modules Design ......................................................................................11 Use Case Diagram .................................................................................................................11
2.2.2 Sequences Diagram ....................................................................................................................12 2.2.3 Activity Diagram ........................................................................................................................22 2.2.2 State Diagram .............................................................................................................................32 2.3. 2.4. User Interface ............................................................................................................................34 Semantic Data Model ................................................................................................................39
2.5.Database .........................................................................................................................................40 1. Appendix ..........................................................................................................................................48
Page 3 of 48
[SS12/4B]
1. Introduction
1.1.Document Preview
Design Specificaion is used to explicit information about the requirements for a product and how the product is to be put together. It is organized in the format that introduces the project overview and scope. Followed by the System Desgin which includes System Architecture, Design Componets/Model Design, User Interface and Semantic Data Model. More details of each component of System Design will be covered in their respective sections.
1.2.Project overview
The task is to developing the DB-Wrapper, a database wrapper that protects against inference attacks on statistical database. The software provide as a filter in the connection between the user application and the database to verify if the query compromised the confidentiality of the system. The software has a two layer hierarchical structure which allows dynamic setting up of the Database Wrapper.
1.3.Project Scope
The DS-Wrapper is intended to work as a query-filter like process that filters out the 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 setsize control and Auditing to prevent inferences attack. This will provide data confidentiality and integrity to the database.
Page 4 of 48
[SS12/4B]
2. Systems Design
This section describes how the DB-Wrapper is being implemented and how it interacts with the Client Application and the statistical database. The following diagram below explain the structure and use of the Database Wrapper.
The user have to be first authenticated to the Statistical database (Oracle XE 10g) and when user are to make a query to the statistical database query it will be passed through the database wrapper and verified if it is a possible inference attack. If inference attack occurs the query will be rejected and stored under inference history and query result will not be return to the user, else the result will be return in a Range format or systematically rounded.
Page 5 of 48
[SS12/4B]
2.1.Systems Architecture
Our project employs a 3 Tier Architecture approach. It consist of Presentation, Logic and Data Tiers. Presentation Tier consist of the user interface. Interaction with stakeholders/ clients will be held in this tier. The role of this tier is to translate the request and results from stakeholders/ clients to something understandable. Logic Tier is in the middle of the 3 tiers. Logic Tier moves and process data between the other tiers. For example, Logic Tier will inform the Presentation Tier what is to be displayed. And tells the Data Tier what is to be retrieve within the storage. Meaning to say, Logic Tier process commands, and makes decisions and evaluation for the software. This is the tier where all the processing data is achieved. Lastly, Data Tier is where data are stored and retrieved. This tier can only be interacted through the Logic Tier by the use of SQL commands. Diagram below would explain the 3 Tier Architecture in an more abstract form. 3 Tier Approach:
Source: http://edn.embarcadero.com/article/images/10343/3tier.gif
First/Presentation Tier consist of Graphic User Interface, and would be covered in 2.3 User Interface section of this document.
Page 6 of 48
[SS12/4B]
Second Tier Approach Second/Logic Tier illustration would consist of Process-Flow, Data-Flow, State and Transition. Tools such as Process-Flow Diagram, Data-Flow Diagram, State Diagram, Transition Diagram, Use-cases. These will be covered in the 2.2 Details Component/ Modules Design of this document. Three main techniques are used in second tier approach. 1. Conceptual Approach: Lattice Model In Second Tier for application server, our team used conceptual model that provides a framework to investigate the security problems at the conceptual-data-model level. One of the popular approach in conceptual model is lattice model. This model represents a framework for greater investigation of statistical database security problems although it gives many constraints for users. The lattice model relates to statistical database information in tabular form with different levels of aggregation. Metadata modeling/Data dictionary is used to implement Lattice model. Metadata modeling is similar to lattice model and with used of fet-size control that elimates chances of inference attack.
Source: http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page 4]
To illustrate, a sample of lattice was given above. The database has attributes of Age, Gender and Position (A, G, P). The detailed way to show this database is in tabular form which consist of a three-dimensional table AGP.
Page 7 of 48
[SS12/4B]
Below shows report generated by the attice models. A, G and P represent Age, Gender and Position respectively.
Source: http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page 4]
Lattice model has been proved to be a powerful and effective model for analysing inference problem and to come up with solutions. In transactional database system, the number of entries can be either zero or any number of records stored in database. Therefore, it is possible to infer that protected information can be put together as the results of several statistical queries into session. Every query returning nonindividual results is expected in the behaviour of statistical queries. Therefore, they are not revealing data with single records.
Page 8 of 48
[SS12/4B]
Query restriction methods imposed extra restriction on queries which includes restricting the query set size, controlling of the overlap among successive queries, auditing, partitioning and suppressing cells. Some of the methods cannot guarantee high security assurances while others also limit usefulness of the Statistical Databases. The team uses Query-Set-Size-Control method for this approach.
2. Query-Set-Size-Control method: It is worked by setting upper and lower bounds for the size of the query that is based on the properties of the database and on the preferences fixed by the database administrator. When the number of returned records did not lie within these bounds, the information request is rejected and query answer is denied. For each query, this method can restrict the number of individuals |C|. The database system respond to the query answer only if |C| satisfies the condition. K: lower limit C: result size L: size of database K: parameter set by the database administrator. K C L K L is the size of the database ( number of individuals represented in the database) and K is a parameter set by the database administrator. K should satisfy the condition. 0 K L/2 , otherwise no query can be answered. Main advantage of query-set-size control method is easily implemented so that this scheme is suitable for dynamic Statistical Databases.
Page 9 of 48
[SS12/4B]
3. Restrict Non-Aggregation Query GUI of DB-Wrapper is implemented in a way that only aggregate function are allowed. Combining the 3 techniques above, DB-Wrapper is able to prevention four different types of inference attacks. Arithmetic Means(infer size), Single Match, Addition Aggregate and Partitioning.
Arithmetic Means: When computing the average of a field, table size must vary the attributes of average computation. This is the beginning of the several inference attacks. The arithmetic function considered as important and secure because they could not compromise individual data. Single Match: It is a successful method for usage of queries matching exactly one data item. This method enable to access data pertaining to those reduced groups by creating queries which match the records we want to disclose and include other conditions that disguise the real intention of the query. Addition Aggregate: This attack implements SUM aggregrate to infer a value from a reported addition of records.When generating a query Q1 which returns N as the total SUM on a field of a data table, second query can be created with the value N to disclose information about a particular entity within system. When SUM on a field is M, the difference between N and M produces a value which is not stored on database and can be used to infer restricted data. Partitioning: Statistical databases hide data when a small number of entities makes a large proportion of the data revealed. Hence, the attacker able to locate desired data by using multiple queries which gives minor results. The attacker will combine additional records to retrieved other different aggregate queries. Third/Data Tier in our project would be in the Oracle SQLite database which we will implement towards the end of the project. Our project will be using SQLite as the embedded database in our program. SQLite Manager/Browser will be used to manage the SQLite database in the computer. These will be covered in the 2.2 Details Component/ Modules Design of this document.
Page 10 of 48
[SS12/4B]
2.2.Detail Components / Modules Design

UML diagrams will be used to specifies and defines services of DB-Wrapper.
2.2.1. Use Case Diagram

Following use case diagram is extracted from requirement specification document. This diagram will describes the main functionality provided by DB-Wrapper in actors point-of-view, their goals represented as use cases, and any dependencies among those use cases.
Note: Textual Descriptions of the above use cases are written in requirement specification document.
Page 11 of 48
[SS12/4B]
2.2.2 Sequences Diagram

Following UML sequences diagrams will act as process flow diagrams to provide the project team with a dyamic view of the flow of messages, events and actions between the objects or components of DBWrapper. Sequence diagrams for main use cases were drawn as shown below. User Login
Page 12 of 48
[SS12/4B]
User Create Report
Page 13 of 48
[SS12/4B]
User View, Delete Report
Page 14 of 48
[SS12/4B]
User Export Report
Page 15 of 48
[SS12/4B]
Administrator - View Log Files
Page 16 of 48
[SS12/4B]
Adminstrator Manage Application
Page 17 of 48
[SS12/4B]
Administrator Manage Constraint
Page 18 of 48
[SS12/4B]
Administrator - Manage Range
Page 19 of 48
[SS12/4B]
Administrator Manage Roles
Page 20 of 48
[SS12/4B]
Administrator Manage Users
Page 21 of 48
[SS12/4B]
2.2.3 Activity Diagram

Following UML activity diagrams will show the workflows of actions done by user throught the user interface with support for choice and iteractions. It provides project team members with views of the stepby-step workflows of component in DB-Wrapper system. It also shows how the user interface reacts in the flow of the activity. User Login
Page 22 of 48
[SS12/4B]
User Create Report
Page 23 of 48
[SS12/4B]
User View, Delete and Export Report
Page 24 of 48
[SS12/4B]
Administrator View Log Files
Page 25 of 48
[SS12/4B]
Page 26 of 48
[SS12/4B]
Administrator Manage Range
Page 27 of 48
[SS12/4B]
Administrator Manage Roles
Page 28 of 48
[SS12/4B]
Administrator Create User
Page 29 of 48
[SS12/4B]
Administrator Update, Delete User
Page 30 of 48
[SS12/4B]
Admin ManageApplication
Note: SQL commands are executed.
Page 31 of 48
[SS12/4B]
2.2.2 State Diagram

Following UML state diagrams are used to provide the project team with abstract description of the behavior of the system. It shows and decides what an object should do when a message is received. We will be analyzing the states of DB-Wrapper system, User and Query object classes. Different states of these object will be tracked throughout the system. Query
Page 32 of 48
[SS12/4B]
User
DB-Wrapper
Page 33 of 48
[SS12/4B]
2.3.User Interface
Interfaces among the sub-systems and other external systems will be described in this section. Below structure shows the basic breakdown of the interface design of DB-Wrapper. Structure might be expanded if there is sufficient time for the project team to implement more features. Once the user or an administrator has logged in, they will be directed to their respective page for a normal user or an administrator. They will then be able to perform the functions that are on their respective menu.
DB-Wrapper
Admin
User
View Logfiles
Manage Range
Manage Application
Manage User
Manage Role
Manage Constraints
Create Report
View Report
Export Report
Delete Report
Page 34 of 48
[SS12/4B]
Login page will be displayed to users at the beginning of the program. Users will be prompt to enter their username and password. Login information will then be validates and matches against the information in the database. DB-Wrapper will then determine whether the user is a normal user or administrator and they will be directed to their respective pages (User or Administrator)
Page 35 of 48
[SS12/4B]
Login user will be directed to their respective page based on their role indicated in the database upon login. Interface for Normal Users is shown below. Normal user can only create report and view report. The screenshot below shows the Create Report Tab.
Page 36 of 48
[SS12/4B]
The screenshot below shows the View Report tab. The report can be delete if unwanted.
Page Description Create Report To make queries, create/generate report and save report in database. View Report To view report together with the option to delete or export (txt or xls).
Page 37 of 48
[SS12/4B]
Below shows the interface for Administrator. The six different tabs are View Log, Range, Application, User, Role, Constraint.
Page Description View Log View log file based on the username indicated Range Define the minimum and maximum range of attributes. Application Enter a correct database and select the table with the attributes to read in meta-data successfully. User Create, update or delete a user from database of DB-Wrapper. Role Create, update or delete a role from the database of DB-Wrapper. Constraints - Create, update or delete a constraint from the database of DB-Wrapper. Note: Screenshots of other pages can be found in the user manual. Page 38 of 48
[SS12/4B]
2.4.Semantic Data Model

In this section, UML class diagram is used to describes the object and information structure of our product application. Our project analysts will make use and reference to it throughout the software development cycle. Entities and relationship among them are identified in the system.
Top Part of Class Diagram
Page 39 of 48
[SS12/4B]
Bottom Part of Class Diagram Note: To help in reading of the class diagam, a JPEG image file of the class diagram is included in softcopy submission.
Page 40 of 48
[SS12/4B]
2.5.Database
Below shows the conceptual model of DB-Wrapper inference protection database. It consist of user, roles and data dictionary (metadata repostiory). Instead of directly accessing the application database, user will access the data dictionary.
Page 41 of 48
[SS12/4B]
Relational Database Description of inference protection database. Application (AppNum, AppName) Primary Key: (AppNum) Attribute (AppNum, TableNum, AttributeNum, AttributeName) Primary Key: (AppNum, TableNum, AttributeNum) Foreign Key: (AppNum, TableNum) REFERENCES [Tables (AppNum, TableNum)] Constraint_Associate (ConstraintNum, AppNum, Value) Primary Key: ConstraintNum, AppNum Foreign Key 1: ConstraintNum REFERENCES [Constraint(ConstraintNum)] Foreign Key 2: AppNum REFERENCES [Application(AppNum)] Constraint (ConstraintNum,CostraintName) Primary Key: (ConstraintNum) Range (AppNum, TableNum, AttributeNum, RangeNum, Label, Mininum, Maxinum) Primary Key: (AppNum, TableNum, AttributeNum, RangeNum) Foreign Key: (AppNum, TableNum, AttributeNum) REFERENCES [Attributes(AppNum, TableNum,AttributeNum)] Report (ReportNum, ReportName, UserName, AppName, ReportAddedDate) Primary Key: (ReportNum) Foreign Key: (UserName) REFERENCES [User( UserName)] Foreign Key 2: (AppName) REFERENCES [Application(AppName)] Candidate Key: (ReportName) Report_Query (QueryNum, ReportNum, ReportName, ReportCategory, Data) Primary Key: (QueryNum, ReportNum) Foreign Key: (ReportNum, ReportName) REFERENCES [Report(ReportNum, ReportName)] Report_Table (ReportNum, ReportName, TableUsed) Primary Key: (ReportNum, TableUsed) Foreign Key: (ReportNum, ReportName) REFERENCES [Report(ReportNum, ReportName)], Foreign Key 2: (TableUsed) REFERENCES [Tables (TableName)] Role_Associate (AppNum, TableNum, RoleNum, Association) Primary Key: (AppNum, TableNum, RoleNum) Foreign Key 1: (AppNum, TableNum) REFERENCES [Table (AppNum, TableNum)] Foreign Key 2: (RoleNum) REFERENCES [Roles (RoleNum)] Page 42 of 48
[SS12/4B]
Roles (RoleNum, RoleName) Primary Key: (RoleNum) Table (AppNum, TableNum, TableName,) Primary Key: (AppNum, TableNum) Foreign Key: (AppNum) REFERENCES [Application (AppNum)] User (UserNum, UserName,UserPassword, UserCreatedDate, RoleNum) Primary Key: UserNum Foreign Key 2: (RoleNum) REFERENCES [Roles (RoleNum)]
Page 43 of 48
[SS12/4B]
Database Description Application Application table consists of Application number (AppNum), Application name (AppName) and Application date (AppDate). AppNum - Application number is to record each application entry. AppName Application name is to differentiate each entry and their category. AppDate Application date is to keep track of the creating of data. Attributes Attributes table consists of Attribute name (AttributeName). AttributeName Ensure each attribute has a name. Constraint_Associate Constraint has association of Boolean. Association It has Boolean to identify if each application has any constraints.
Constraints Constraint table consists of Constraint number (ConstraintNum), Constraint name (ConstraintName) and Set size (SetSize). ConstraintNum Constraint number is to uniquely identify constraint. ConstraintName Constraint name is to differentiate each constraint. SetSize Set size is to set lower bound. Range Range table consists of Range number (RangeNum ID), header name (Label), Minimum and Maximum range define the label. RangeNumID Range number ID uniquely identify the different range Label Label indicates the header name Minimum and Maximum The value of the attribute Report Report table consist of Report name (ReportName), user name (UserName), application name (AppName), Report added date( ReportAddedDate) Report_Query Report query table consist of Query number(QueryNum), Report number(ReportNum), Report name(ReportName), Report category(ReportCategory), Data (Data) Page 44 of 48
[SS12/4B]
Report_Table Report table consist of Report number(ReportNum), Report name(ReportName), Table name( TableName)
Role_Associate Role associate table consist of Application number(AppNum), Table number(TableNum), Role number(RoleNum), Association(Association) Roles Roles table consists of Role name (RoleName) and a primary key of Role number (RoleNum ID) RoleName Each role has a name for the user. Label Header name of the range of attributes. Minimum Define the lowest possible value of the attribute for particular table. Maximum Define the highest possible value of the attribute for particular table. Tables A table consists of Table name with a primary key Table number (TableNum ID). TableName Ensure each table has a name. User User table consists of User number (UserNum), User name (UserName), User password (UserPassword) and User created date (UserCreatedDate). UserNum User number is to allow different user having a unique number identification. UserName Each user will have an identity. UserPassword User will need to have password for authentication. UserCreatedDate The date must be recorded when each user is created.
Page 45 of 48
[SS12/4B]
Data Dictionary Database created in SQLite. Left column shows the tables in the database. Content of the tables (user) information is in the main frame as shown:
Page 46 of 48
[SS12/4B]
One example of our Application Database (SIM Staff)
Relational Database Description
University (University#, Name) Primary Key: University# Course (University#, Course#, Name) Primary Key: Course#, University# Foreign Key: University# ref [University University#] Staff (Staff#, Name, DOB, Age, Gender, Address, Date_Join, PostName, Salary, Password) Primary Key: Staff#
Page 47 of 48
[SS12/4B]
Created in SQLite
1. Appendix
NIL
Page 48 of 48

DSS 12 S4 03 Design Specification

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DSS 12 S4 03 Design Specification

Uploaded by

Copyright:

Available Formats

School of Computer Science & Software Engineering

Bachelor of Computer Science (Digital Systems Security)

CSCI321- Project Design Specification

Supervisor: Mr Sionggo Jappit Assessor: Mr Tan Kheng Teck

Design Specification Design Specification

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

1.1 1.2 1.3 1.4 1.5

Source: http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page 4]

Source: http://dsns.csie.nctu.edu.tw/ssp/paper/29.Information%20Protection%20in%20Dynamic%20Statistical%20Databases.pdf [page 4]

2.2.Detail Components / Modules Design

2.2.1. Use Case Diagram

2.2.2 Sequences Diagram

User Create Report

User View, Delete Report

User Export Report

Administrator - View Log Files

Adminstrator Manage Application

Administrator Manage Constraint

Administrator - Manage Range

Administrator Manage Roles

Administrator Manage Users

2.2.3 Activity Diagram

User Create Report

User View, Delete and Export Report

Administrator View Log Files

Administrator Manage Constraint

Administrator Manage Constraint

Administrator Manage Range

Administrator Manage Roles

Administrator Create User

Administrator Update, Delete User

Note: SQL commands are executed.

2.2.2 State Diagram

2.4.Semantic Data Model

Top Part of Class Diagram

One example of our Application Database (SIM Staff)

Relational Database Description

You might also like