3.8 Requirements and Project Scope

In this section the findings from the analysis section have been grouped together to create the design requirements.

Purpose

The purpose of this is to:

• Set a development scope for the project based on the analysis outcomes
• Set out possible design considerations based on the professional issues
• Describe the functionality that will be required in the design

The Project Scope

The project will be focused in the following areas to ensure a working prototype can be completed within the project timescales.

• The product will be developed as an in-house tool, based on web technologies

This will reduce the development time in terms of security considerations by not developing a role based login system for the prototype and hardening the code from the protection of threats from the Internet. In a cloud based or a hosted full production version this will need to be addressed.

• Prototype to focus on the SoD (Segregation of Duties) core functionality of the system

This further reduces the development time in the design and implementation phases. The focus will be sense checking the core idea behind the product works and it is practical.

• Create prototype user account data to test the application in place of application connectors to extract the data from a live system.

Test data would be able to prove the idea is sound, and that the logic behind the application works as designed. This will reduce the development focus on developing application connectors to import the user data in with.

The Users of the Application

The possible users for the system are:

• Auditors
• Team Leads
• Users
• IT Security Teams
• Compliance Teams
  • HR
  • Application Owners

As the project scope is focusing on the SoD aspect of the system the prototype will be built with the compliance users only in mind. The system should be understandable from their perspective in setting the SoD rules and viewing the resultant output reports based on the prototype data pre-populated in the system.

Functions to Develop - Inside the Project Scope

• Self-service portal that is web based
• Role modelling
• SoD modelling
• Reports

Function to Exclude - Outside the Project Scope

• Role or device based polices - using application connectors to import data
• Delegated administration
• Role discovery
• Reporting histories - repeatable audit runs
• Any automation or connection to external applications to alter 3rd party data
• "Bingo Lists" to flag near compliance breaches

IT Security and Professional issues

The following items although important will not be covered in great detail due to time constraints, however would be required in a fully functioning production version.

• Database backup and encryption - This is possible to achieve however in the prototype stage not required as no sensitive data is being entered within the system. Encryption technologies include the use of SSL and code signed certificate encryption accounts for browser authentication by purchasing certificates. https://www.globalsign.co.uk/ssl/ The database encryption is a function of most database software http://technet.microsoft.com/en-us/library/cc278098(v=sql.100).aspx#_Toc189384672
• Application account rights reduction of the front end to database application account - An application account will be setup that has the minimal rights to ensure the application operates without the possibility of a hacker attempting data manipulation from the Internet, either by direct connection or script injection.
• User Guardian will not to be considered a complete solution to achieving ISO27001 - The design will only address one small part of the accreditation.
• Built to be used as a standalone application that could be hosted by the customer - This will avoid the organisational policy implications of linking the application to live 3rd party production environments.
• Prototype to use only test data - To avoid Data Protection Act issues during the development.

How User Guardian will Adopt a Differing Approach

The current IAM tools on the market rely on risk based scoring of user rights to determine where there could be possible compliance breaches in the organisation.

The reason all IAM providers do this is due to the way ISO27001 certification is awarded. To be compliant an organisation must show they are reducing the risks of security incidents by understanding and controlling the provisioning of accounts to applications.

There are a couple of negative points to this approach:

1. The risk scoring method
2. The risk scoring is only as good as the persons involved in the scoring. This tends to be done by a single department using risk assessments across the organisation. These can be time consuming and inaccurate if not repeated frequently.
1. Does not provide a "Least Privilege" approach
   1. The least privilege approach of removing access to only leave the access that's really required is the most effective method of securing an environment, and most cost effective in licensing.
   2. Application access is binary**
   3. What is meant by this is a user either has the ability to do, or not do something dependent on their access. In reality and practice there is no real middle ground. As a result using percentage risks scores based on combinations of access rights would not work. An organisation would either be in or outside compliance based on the application access settings provided to their users.

User Guardian will report on definitive breaches of access based on a transparent crowd checked and supported approach. The delegation of checking user's access at the management and user levels will support a clear, reliable, and timely resolution of any potential access issues.

Providing visibility to the users of their access would support better SoD mappings, users are more likely to report access issues where they feel personally uncomfortable with a given level of access.

In regulated banking and energy companies staff are very aware of the operational risks, and the personal fines that could be imposed on them. For this reason users would be more forthcoming to support this style of approach. A "show me what I have, and I will tell you where it's wrong" method.

**Note on point 3 - How User Guardian will adopt a differing approach

Information provided in the section "Application access is binary" are insights from the author's personal experiences as an IT Security consultant contracting within the energy sector.

Steve Hiscock IT Consultant, GrubbySoft Ltd

http://uk.linkedin.com/pub/steve-hiscock/1b/4a7/729