Month: April 2015

Security analysis of system requirements and design

Nengjie Zhang Leave a comment

Overview:

  • Assess likely risks of the system and specific cost by analysing the requirements and design.
  • Identify drawbacks or improper security requirements.
  • System operation security.

For LessonPlan 2.0, as it is a social media platform for module reviews, the effective operation of the system is extremely important and the main secure factors are about the design and structure of the system, including the database that used to store the useful and updated information. The detailed contents of the system architecture design were posted by one of our group members (AHMED AL-BRASHDI) on April 27, 2015. Here is the flow chart of security analysis.

security

Actually, the main security analysis of the system will focus on the technology. The system can be divided into two parts: Front-end and Backend. For the Front-end, normally, the system can be used in a public network, such as the computer room in university, when one student log in the system successfully, the second one can not enter it when using the computer that has the same IP address, so the second one will not view the status of the module option for the previous. This is one point about users’ interaction.
For the Module Review Database, as the related information of modules is too much and it may cause confusion between several modules, such as the module leader, module place, module time, etc. Managing well the database is very essential for the system operates in a correct way.

Since the system has a login and user profile information, we think about how to overcome any vulnerabilities associated with each page.
As a web application, the main possible vulnerabilities as in OWASP top ten 2013 [1]:
1- Injection: will focus more on SQL Injection here. The login form and any other form has to prevent such attach. The danger comes when the attacker can trick sql statement and gets over authentication and authorization. He /she can then login as an admin and harm the entire application or database. Also, injecting delete or drop sql statement will remove table records or remove the entire table with its structure and definition. To overcome this, we should use parametrized interface or statement like using PrepareStatement in JDBC. Another way is to escape special characters using DBMS. Third option is to use stored procedure instead.
2-Cross-Site Scripting: if the user input has not been escaped correctly, the site might be vulnerable to cross-site scripting. To overcome this, we need to escape all untrusted data and use libraries like OWASP’s AntiSamy.

The other vulnerability might not have the same weight as these main two in LessonPlan 2.0. However, the proper prevention strategy will be applied in all of them to ensure the highest security possible. This include hashing session ids, using secure HTTP and hashing user password [2].

——–
[1] The OWASP Foundation, “OWASP Top 10 for 2013″, 2013
[2] Provided by Ahmed Al-Brashdi, 2015

Cost Breakdown

Sam Leave a comment

Running costs of Lessonplan are predicted to be rather low. Primary costs will be time spent creating the system, the the time spent installing it at customer universities and any relevant support related costs.

Our service will be offered to numerous universities across the UK (for now) as a white label software solution. It is a web-application that will need to be hosted on web servers.

Two options will exist for client universities: hosting on their existing servers or an external provider. The latter will cost more for the university but will not cost any extra for us. Both of these options cost us nothing. If the customer wishes for us to provide external hosting, we will use a cloud server from DigitalOcean at a cost of £52 per month (all of which is forwarded to the customer).

Because we are a team containing web developers, the development costs will be very low, we will be using open source frameworks rather than proprietary software to develop the product. We also anticipate that support for the system will be minimal due to a test driven design methodology, designed to minimise the number of bugs that make it into production installations. Once the product is developed however, running costs drop off significantly further and the profit increases exponentially as we roll the system out to more universities very cheaply (with a typical set-up time of 6 man hours).

We don’t require any office space as we can work remotely and communicate via Skype and project management platforms such as Trello.

We may invest variable amounts of money in marketing the platform. This will involve travelling for meetings at potential universities to discuss our solution. This figure could range anywhere from £30 to £150 per visit.

We expect universities themselves will promote the use of the system by their students once they have purchased it. This negates any cost for us to perform this promotion ourselves.

User Experience

Ahmed Al-Brashdi Leave a comment

To add the value for game theory and interface design, some elements for user experience and engagements are considered when developing LessonPlan 2.0. These elements will include for example:

  1. Simplicity and speed of loading and navigation. By designing a simple landing page, the browser will load the page for the user very quickly.
  2. Use of customized and representative logo and brand for LessonPlan 2.0.
  3. Progress bar for the percentage of completion of reviews and engagement in module.
  4. Using eye-tracking technique and following F shape style [1], the main navigation for ratings, review, courses are set on the first horizontal line of F. The main contents will be on the left side on the main panel as users spend 69% of their time of the left side of a page [2]
  5. Each time a user complete a review, he/she will get a score. When scores gets to certain level, a batch will be awarded to the user.
  6. Using RSS and letting the students subscribe for fees.
  7. Search box at the start with drop down list for registered courses.

By doing so, we ensure user engagement with rich experience in LessonPlan 2.0. Some of these elements are illustrated clearly in mockup figures.

———–

[1] Nielson Jakob, “F-Shaped Pattern For Reading Web Content”: http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/, Apr 17, 2006 [Apr. 29, 2015].

[2] Porter, Joshua, “Testing the Three-Click Rule”: http://www.uie.com/articles/getting_confidence/, Apr 16, 2003 [Apr. 29, 2015]

Main User (Student) Use Case Diagram v1.0

Ahmed Al-Brashdi Leave a comment

One of the main feature of a system is the interactivity between it and its users. The interaction is illustrated by using use case diagram. Here we represent the main actor of the system where the entire system is mostly used and interacted with by this user, student actor.

The diagram shows how the student will interact with module review social network and what actions he/she will perform. The other actors are not included in this version of use case diagram because at this point their interactivity with the system is very limited at this stage. These actors are the lecturer who can comment on review or reply on a comment. The system which analyze the student input as preferences and generate a suggestions or a list of suitable module based on student grade, pre-set preferences, rating and difficulty level of a module.

UseCase

Entity Relation Diagram

Ahmed Al-Brashdi Leave a comment

Entity Relation Diagram is used to illustrate a unified view of a system data [1]. This entity relation diagram shows the main entities in LessonPlan application and how these entities relate to each others. By ensuring the correct entities data types and relation, we enforce the integrity of the database. The relationship between two tables is ensured by referencing its primary key like userid in Module_Feedback table which reference the user id who provided that feedback. If a user id does not exists in user table, it can not be stored in any other table which reference it. This is to enforce the referential integrity in database. To enforce the entity integrity, a primary key in each table has been identified. These primary key might be single attribute like userid in users table or composite primary key (consists of multiple attributes together) like mode_program table.

In ERD, U stands for unique in that table and N stands for nullable (can be null). To ensure that an email address is not used by two or more users, the attribute constraint is set to be unique. Same for school name, module name and program name as we can not have the same name which represent two schools, modules or program. The grade in user table is set nullable so the user will have the ability to choose between giving it or not.

These tables represents only LessonPlan database without the integration with university database in which the system can query from using remote procedure calls.

ModuleReview

 

———-

[1] Chen, P. P. S. (1976).The entity-relationship model toward a unified view of data. ACM Transactions on DatabaseSystems (TODS), l(1), 9-39.

Class Diagram v1.0

Ahmed Al-Brashdi Leave a comment

The class diagram of LessonPlan 2.0 social network illustrate the structure of this application by illustrating the classes and their attributes and operations.

LessonPlan 2.0 project consists of multiple classes in which some of them depend on others. The main class User is a generalization for both students and lecturer/module leaders. Both of them (student class and lecturer class) have something in common which is represented in User class. The other attributes and operations that distinguish student from lecturer are set in student class, same for lecturer.

The dependencies between classes are represented with doted arrows. Each class represent class name, number of attributes which set to be private by assigning – sign before them, and public constructors and operations with plus + sign before them.

Social Network Class Diagram

System Architecture Design

Ahmed Al-Brashdi Leave a comment

LessonPlan 2.0 system is built from different parts and components. As the size of the system will increase over time, these components should be separated from each other for more maintainability and scalability. When dealing with software architecture and design, it is very critical to get the architecture right in order to prevent system disaster. Also, when an engineer understand the software architecture and organization, he/she ca make correct choices between design alternatives [1].

After looking at different architecture choices and alternatives, Model-View-Architecture has been adopted for the proposed system.The reason for choosing this architecture/pattern for the software design is to separate the concerns. Also, since most of web development frameworks and languages offers mature implementation of MVC, it will be easier for developer to adopt it and build on it in future.

Model in module review system consists of entity classes which deals with the database. These models notify the view (web pages) when a change on the data has been made. The controller takes the request and process all the application logic.

The system might need to get some data from university student records database. This could be done using remote procedure calls from module review database to student records database. Module description pages will be fetched from university using RDF and XML.

Here is the abstract software architecture of module review system using MVC:

Social MVC Diagram——————

[1] Garlan, D., & Shaw, M. (1994). An introduction to software architecture. Carnegie Mellon University

Non-Functional Requirements

Tun-Ya Yu 2 Comments
ID Description Rational
01 The system should be available and operable for at least 99% of the time. Availability
02 The database of the system should be protected. Security
03 The system should be backed up every 24 hours. System Backup
04 The system should be designed with direct and indirect accessibility consideration. Accessibility
05 The system should support the most common browsers and also be able to be used from a mobile device. Platform compatibility.
06 The system should meet the legislation of this kind of application. Legal and licensing issues
07 The system design should be clear to understand. User Friendliness
08 The system should respond in under 5 seconds for every request. Effectiveness