<Project Name>

Security Tool and

Assessment

Security Tool/Assessment Template Instructions

(Please remove this section before completion of template)

The Security Tool and Assessment document should contain clear requirements that are the blueprint and main determinant of the quality of your software and system projects. The document should also define how secure your application is going to end up. This assessment should define the project’s security goals and operational controls. This assessment should also identify how the security will be tested.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Security Tool/ Assessment (SDLC)	R	R	O	This deliverable is mandatory for large and medium scale projects and optional for small scale projects unless requested by the Sponsor, Steering Committee or IT management.	The Security Tool and Assessment should be approved by the Sponsor, Steering Committee, Implementation Team, and the Information Security Office, at a minimum.

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	3

3.	Security Goals	4

3.1.	General Description and Goals	4

3.2.	Application and System Environment	4

3.3.	Laws or Regulations Affecting Application or System	5

4.	Application or System Identification	6

4.1.	Category	6

4.2.	Responsible Organization	6

4.3.	Sensitivity and Criticality Assessment	6

4.4.	Security Control Limitations	8

5.	Operational Controls	9

5.1.	Risk Assessment	9

5.2.	Personnel Security	9

5.3.	Password Authentication	11

5.4.	Administrative Access Controls	12

5.5.	Documentation	13

5.6.	Incident Response	13

5.7.	Audit Trails	13

5.8.	Change Control	13

6.	Security Testing	15

6.1.	Test Plan	15

6.2.	Tester Identification	15

6.3.	Test Results	15

7.	Approval	16

Introduction

Purpose

This security tool and assessment study has been conducted to determine the best course of action on the xxxxxxx. Possible statement:

Security requirements need to be very specific about the subsystems that should be protected in your application, what types of protection must be in place, and what types of application attacks must be specifically safeguarded in your system. Validating all inputs will prevent up to 80 percent of all application layer security attacks and should be explicitly required and tested in every project. Security requirements should also require that sensitive parts of the application be protected. All confidential and restricted access portions of the application should be protected. All critical-level application vulnerabilities should be protected against and verified in security testing, including command injection, SQL injection, cross-site scripting, parameter manipulation, etc. Security should address all portions of a system being developed, including backend systems such as databases and the access to them, integrated components, such as third party applications or plugins, the application being developed and even access to the code itself. Effective security requires not only prioritize security at the beginning of a project, but also increase its visibility throughout the SDLC. Clear requirements are the blueprint and main determinant of the quality of your software projects. They also define just how secure your application is going to end up. Your application may look good and run well, but it may not hit the mark if it doesn't meet the security needs of your company or your customers.

Assumptions

This document assumes.....

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Security Goals

General Description and Goals

Make sure to identify if the project is a new implementation, modification to an existing system, or a combination.

Describe the function or purpose of the application/system and the information processed.

Define requirements related to the storage, processing, or transfer of sensitive information.

Describe the processing flow of the application/system from input to output.

List user organizations (internal & external) and the type of data and processing provided.

Application and System Environment

Identify detailed system security requirements during system design.

Develop appropriate security controls with evaluation & test procedures prior procurement actions

Develop solicitation documents to include security requirements & evaluation/test procedures

Update security requirements as technologies are implemented

Identify security requirements for procurement of COTS applications components

Perform design review to ensure security controls are considered prior to production

Ensure security features are configured, enables, tested, and documented during development

Update, design, perform and document newly developed security controls

Document system security tests and risk assessment

Ensure compliance with Federal laws, regulations, policies and standards

Certify system and obtain system accreditation

Provide security training

Laws or Regulations Affecting Application or System

List any laws or regulations that establish specific requirements for confidentiality, integrity, or availability of data and/or information in the application and/or system.

Application or System Identification

Category

Indicate whether the application/system is a Major Application or a General Support System.

A Major Application is "an application that requires special attention to security due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application."

A General Support System is an "interconnected set of information resources under the same direct management control which shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people."

Responsible Organization

Contact Information

List the person(s) responsible for security of the application and/or system and an alternate emergency contact.

Name

Title

Address

Phone Number

Fax Number

E-mail Address

Responsibilities

Describe roles and responsibilities of each person(s) listed above

Sensitivity and Criticality Assessment

A description of the types of information handled by the application/system and an analysis of the criticality of the information is required. This description and analysis will assist in designing security controls, facilitating security audits, and implementing security countermeasures.

Describe, in general terms, the information handled by the application/system and the need for protective measures.

List the types of sensitive information the application/system accesses. Examples may include: administrative, financial, grant/contract, patient, proprietary, research, Privacy Act.

For each of the information types above, indicate if the sensitivity is classified as: High, Medium, or Low.

Low Sensitivity information requires a minimal amount of protection. This level includes information considered to be in the public domain.

Medium Sensitivity includes data important to NIH that must be protected from unauthorized alteration. This level includes information pertaining to correspondence and other document files whose release needs to be controlled.

High Sensitivity information requires the greatest safeguards at the user level. High sensitivity information includes but is not limited to: highly critical or proprietary information; financial or grant data; or records subject to the Privacy Act.

SAMPLE DETAILED APPLICATION/SYSTEM PROTECTION REQUIREMENTS CHART

Information Type	High	Medium	Low
Administrative
Financial
Grant/Contract
Patient
Proprietary
Research
Privacy Act
Other (specify)

Include a statement of the estimated risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information in the application/system.

Security Control Limitations

Describe any limitations that may be restricting the security of the application and/or system.

Operational Controls

Risk Assessment

Describe the risk assessment methodology used to identify the threats and vulnerabilities of the application/system. Be sure to include coding language best practices used, application risks, network risks, database risks, etc.

List the group that conducted the assessment, and the date(s) the review was conducted.

If there is no application/system risk assessment, include a milestone date (month and year) for completion of the assessment.

Personnel Security

Have all positions been reviewed for sensitivity level?

Is user access restricted to the minimum necessary to perform the job?

Include an example of the security access request form.

Is there a process for requesting, establishing, issuing, and closing user accounts? Demonstrate process (see picture below).

Describe roles and responsibilities of all types of users having access to the application and/or system. Include approximate number of authorized users.

User Level	User description	Role in Application or System	# of User
Administrator	Responsible for developing/managing certain module(s)	Capable of making all modification, deletion and alteration of Data, Templates and configuration.	9
Faculty Prov	Faculties provide treatment, supervises treatment, grade and edits & approves treatment plan	Add, review/edit and approve treatment. Supervise and Grade students work.	194
Financial 1	Responsible for managing all financial and insurance activities	Add, delete and modify all treatments and transactions; including financial adjustments. Update insurance information and submits electronic billing	1
Front Desk	Register and Schedule patient, manage patient appointments. Request chart from chart room	Register patient in Rolodex. Add, delete and edit patient schedule. Manage patient appointment as per Providers schedule. Check In and Out patients on day of treatment	6
Front DeskSuper	Same as Front Desk in addition to enter Transaction and collect payments	Same as above plus enters treatment, transactions, collect payment and allocate to treatment.	3

Password Authentication

Indicate the frequency of password changes, describe how changes are enforced.

Provide the following if an additional password system is used in the application and/or system:

password length (minimum, maximum)

allowable character set

number of generations of expired passwords disallowed for use

Describe the level of enforcement of the access control mechanism (network, operating system, and application/system).

State the number of invalid access attempts that may occur for a given user ID or access location (terminal or port) and describe the actions taken when that limit is exceeded.

Administrative Access Controls

Hardware

The access provided to the administrator for the hardware must be explained in detail in this section.

How is the access granted initially and to later administrators?

Provide the following if an additional password system is used in the application and/or system:

password length (minimum, maximum)

allowable character set

number of generations of expired passwords disallowed for use

Describe the level of enforcement of the access control mechanism (network, operating system, and application/system).

State the number of invalid access attempts that may occur for a given user ID or access location (terminal or port) and describe the actions taken when that limit is exceeded.

Software

The access provided to the administrator for the software must be explained in detail in this section.

How is the access granted initially and to later administrators?

Provide the following if an additional password system is used in the application and/or system:

password length (minimum, maximum)

allowable character set

number of generations of expired passwords disallowed for use

Describe the level of enforcement of the access control mechanism (network, operating system, and application/system).

State the number of invalid access attempts that may occur for a given user ID or access location (terminal or port) and describe the actions taken when that limit is exceeded.

Documentation

List the documentation maintained for the application/system. Examples may include:

vendor documentation of hardware/software

functional requirements

standard operating procedures

user rules/manuals

List the physical location of documentation.

Incident Response

Are there procedures for reporting incidents handled either by application/system personnel or externally?

Are there procedures for recognizing and handling incidents, i.e., what files and logs should be kept, who to contact, and when?

Who receives and responds to alerts/advisories, e.g., vendor patches, exploited vulnerabilities?

Audit Trails

Describe how the access control mechanism supports individual accountability and audit trails.

Does the audit trail support accountability by providing a trace of user actions?

Is access to online audit logs strictly enforced?

Is the confidentiality of audit trail information protected if it records personal user information?

Describe how frequently audit trails are reviewed and whether guidelines exist.

Change Control

Describe any formal change control process in place related to security.

Is there version control that allows association of application/system components to the appropriate application/system version?

Are all changes to the application/system software or application/system components documented?

Are there impact analyses to determine the effect of proposed changes on existing security control to include the required training for both technical and user communities associated with the change in hardware/software?

Are there change identification, approval, and documentation procedures?

Are there procedures for ensuring contingency plans and other associated documentation are updated to reflect application/system changes?

Does the change control process require that all changes to the application and/or system software be tested and approved before being put into production?

Security Testing

**Use for the Test Plan further in the methodology.

Test Plan

Provide the procedures for testing and/or approving security components prior to promotion to production.

Is test data live data or made-up data?

Do test plans trace back to the original security requirements?

Tester Identification

Identify who will be performing the test plans developed.

Test Results

Include proof that all testing scenarios were tested and approved. A table documenting results is below:

Role	Scenario	Action	Expected Result	Actual Result	Guidance
Approver	Assign an item in the folder to yourself	Click Home -> Desktop -> Click here to access the approvals page	The req should be identified as being assigned to you	You should see the reqs in your queue(s) and be able to click on them
Administrator

Approval

The individuals below agree that they have reviewed and approved the information documented in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Project Management Office

EXAMPLE

Security Tool and Assessment

Table of Contents

1.	Introduction	2

1.1.	Purpose	2

1.2.	Assumptions	2

2.	Version Control	2

3.	Security Goals	2

3.1.	General Description and Goals	2

3.2.	Application and System Environment	2

3.3.	Laws or Regulations Affecting Application or System	2

4.	Application or System Identification	2

4.1.	Category	2

4.2.	Responsible Organization	2

4.3.	Sensitivity and Criticality Assessment	2

4.4.	System Functionality	2

5.	Role Configurations	2

5.1.	Roles	2

5.2.	Permissions	2

5.3.	Password Authentication	2

5.4.	Administrative Access Controls	2

5.5.	Incident Response	2

5.6.	Audit Trails	2

6.	Security Testing	2

7.	Approval	2

Introduction

Purpose

The purpose of this plan is to outline the security framework for the SciQuest Supplies Manager module installed under the UH Material Management Module Implementation Project. This project includes additional functionality being installed in the existing Marketplace solution hosted by SciQuest.

Assumptions

This document assumes the reader is somewhat familiar with the existing Marketplace solution administered by the Supply Chain/Purchasing department and Banner. We refer the reader to the existing Marketplace solution Security document. This document is a supplement to the information found in that document.

Version Control

Version	Date	Person	Change
1.0	07-Mar-11	F. Haies	Initial Document Creation
1.1	27-May-11	R. Chandrasekharan L. D’Ambrosa	Updated and reviewed
1.2	31-May-11	D. Gabriele	Updated and reviewed
1.3	02-Jun-11	R. Chandrasekharan	Implementation team Review. Approval in Section 7
1.4	07-Jun-11	R. Chandrasekharan	SC team review. Approval in Section 7
1.5	13-Jun-11	R. Chandrasekharan L. D’Ambrosa	Changes made based on ISO and IA discussions.
1.6	14-Jun-11	R. Chandrasekharan	Implementation team Review. Approval in Section 7
1.7	17-Jun-11	R. Chandrasekharan	SC team Review. Approval in Section 7

Security Goals

General Description and Goals

This project is a modification to an existing system, therefore most security controls are already in place.

The purpose of this application modification is to provide inventory management capabilities at University Hospital WareHouse areas currently using legacy ‘MediClick’ system.

The scope of this implementation is limited to current users of MediClick. All net new departments and University users will be performed under subsequent implementation phases.

Inventory information is kept in the inventory module however, interdepartmental transfers and requisitioning information is integrated into the existing Marketplace solution. There are no NEW Banner integrations as a part of this project. IDTs will be handled in an automated (but not automatic) process outlined in this document.

Application and System Environment

The application module will be accessed by all users via the Luminus Portal using their Core log in information. Users will be required to have a Banner account with “inventory” roles assigned to them. The permissions in SciQuest are mapped to the Banner roles and can be found in section 5.1.

Application administration remains unchanged from the Marketplace solution. Administrative functionality is accessed using a separate URL outside of the Portal process. Administrator passwords use the University’s definition of “Strong” passwords configuration. SciQuest enforces the strong password requirements, has a maximum log in attempts set at 3 and requires changing of passwords every 90 days.

Application administration does not include Database administration. This is a service provided by SciQuest (as is the case with the Marketplace solution).

There are no network hardware (server) installations as part of this project.

Since the application needs to be accessed from UH Par Station locations, some wireless network connectivity is required. All locations have been tested for connectivity. Wireless network security is controlled by IS&T, CST.

System Flow diagram

Current E-procurement module Spend Director Requisition Manager Order Manager Supplies Manager Item Catalogs Inventory Locations Inventory Items Global product search Replenish inventory Inventory Order Fulfillment Stockroom Manager Order Manager

Refer to the Supplies Manager Handbook Lesson 1 [Page 4 onwards] for detailed Inventory Management process flow and narrative.

Laws or Regulations Affecting Application or System

SciQuest maintains a SAS-70 certification.

This system does NOT contain any patient health information.

Application or System Identification

Category

This project is to implement an additional module (Supplies Manager) to the existing Marketplace system. Marketplace and its modules are enterprise wide and considered a major application within UMDNJ. Critical units/departments using this system include University Hospital, EMS and other clinical settings. The work around for down time or fall back plan for non availability is to use the paper requisitioning process for requesting/ordering material and tracking receipts and product distribution via paper means.

Responsible Organization

Contact Information

Supply Chain Management under the direction of Thomas Kenyon, VP is the responsible department for the entire Marketplace application. The below person(s) are responsible for the daily maintenance:

Name: Larry D’Ambrosa
Title: Marketplace System Admin
Phone Number: 732-235-9529
E-mail Address:dambrol@umdnj.edu

Name: Mary Dowling

Title: System Analyst

Phone Number: 732-235-9478

Email Address: dowlinmm@umdnj.edu

Name: Ruth Reid
Title: Marketplace Support Contact
Phone Number: 732-235-5716
E-mail Address: reidrd@umdnj.edu

Name: Kimberly Satnowski

Title: Contract/Catalog Administration

Phone Number: 732-235-9486

Email Address: lundki@umdnj.edu

Responsibilities

Thomas Kenyon is responsible for the overall quality of the application, its functionality and overall effectiveness.

Larry D’Ambrosa is considered the system administrator and is responsible for the overall up time, issue rectification and vendor liaison.

Mary Dowling is Larry D’Ambrosa’s back up and runs reports and report extracts.

Ruth Reid is the first level support contact for MarketPlace helpdesk queries. She monitors the MarketPlace help mailbox; and resolves issues/calls related Market Place ids, index numbers etc.

Kim Satnowski helps with the system admin backup and helps with the catalog management tasks for hosted and punch-out vendors for the University.

Sensitivity and Criticality Assessment

In general terms, the information handled by this application is financial in nature. There are no additional integrations with our ERP Banner system. Information in this application is considered to be of Low Sensitivity however is not of public domain.

System Functionality

Since the system is inherently integrated with Banner, there are financial components to the basic functionality. Users are granted permission to perform certain inventory or purchasing functionality based upon their assigned role(s) in Banner. Procurement coordinators need access to the appropriate Banner indexes in order to place orders to external vendors.

Inter departmental transfers (IDTs) will take place between the warehouse(s) and other units of the hospital for order fulfilment. Under the direction of Invoicing Manager of Material Management, a report will be generated monthly by extracting data out of Supplies Manager module and into an Access database, where pertinent data will be filtered for submission to CA Finance for the execution of the IDTs in Banner. This is a process similar to that currently in place. Additionally, and at the same time, another similar data extraction will take place and put into an Access database for filtering to be included in the e-Print module of Banner. End users will then have access to e-Print using their Banner permissions/roles to access their department’s detailed IDT information.

For the implementation of purchase order to outside vendors for replenishment purposes, the General Stores and OR warehouses will be eliminating standing orders. Individual vendor purchase orders will be sent regularly using the same functionality as the Marketplace functionality with the exception of the fiscal office approval queues. Please note that this is for inventory replenishment orders only.

Managers in the warehouse will be approving all purchase orders before being submitted to vendors. All PO’s will continue to go through the budget authorization steps already in place.

Process/procedure to check security system activities such as system log:

Audit history is maintained in SciQuest system for all activities including system administration tasks.

Review/validation of the security system logs will be performed on an as-needed basis, post go-live. System process checks will be performed when event/issues are escalated/notified to the system admin team. Audit history will be analysed/resolved/reported on, based on the issue/event.

Role Configurations

Roles

All users of Marketplace, including the use of the Supplies Management Module, require Banner access.

For the use of this module the following roles have been developed in SciQuest which will map to existing Banner roles. Therefore, existing users of Marketplace will require an additional banner role in order to access the supplies module.

All other Marketplace roles remain unchanged.

New Marketplace Roles	Description	Permissions	Associated Banner Role	Notes
Distribution/Warehouse Manager	Supervisor/Warehouse manager	View orders, Export Search Results, Fulfill sales Orders, NO Assign Substitute Approver for Sales orders, Edit pending sales orders, View All sales orders, Close/Complete sales orders, Manage Locations Edit Items/Catalogs - Only edit no syndicate	SPD_STOREKEEPER1	Warehouse Managers and Supervisors, and departmental managers (IE, Radiology and/or Cath. Lab)
Do Inventory Search, Inventory Administration, Adjust Inventory, Cycle Counting DO NOT place orders create sales invoices/credit memos Approve/reject SO on behalf of another Approver Manage other Approver's SO Approval Folders [watch list]
Approval permissions: [SQ to create Workflow] - NO edit pending requisitions - approve/reject requisitions -NO Add lines to pending requisitions AP: Create/view receipts; view invoices/organizational invoices

New Marketplace Roles	Description	Permissions	Associated Banner Role	Notes
Material Handler	Material Handler - fills pick lists, delivers goods, completes sales order	View orders, Export Search Results, Fulfill sales Orders, NO Edit POs, Edit pending sales orders, View All sales orders only assigned to them, Close/Complete sales orders, Inventory Search, NO Replenishment, internal attachments	SPD_MATERIAL_HANDLER_STORES (do not use for UH Warehouse personnel)	Material Handlers for Non-UH staff (cannot place orders to ANY vendor)
View receipts; Cycle Counting print. Allow Adjustments [updated per SQ call on 5/4] view Index ONLY.
Procurement Coordinator	Purchases goods from outside vendors for warehouse/stockroom	Place Orders, View orders, Export Search Results, Inventory Search, Replenishment, view/use forms Edit Items/Catalogs - only edit no syndicate; NO view Credit cards; View Receipts; NO Create Receipts;	SPD_COORDINATOR_STORES	Can place orders to external vendors
Receiving Clerk	Receives orders into SciQuest	View Sales & Purchase orders, Export Search Results, NO Fulfill sales Orders, NO Edit pending sales orders, View All sales orders, NO Close/Complete sales orders, Inventory Search, Adjust Inventory, NO Replenishment, NO Cycle Counting Create/view receipts; Blind receipts	SPD_MATERIAL HANDLER_REC	Can receive replenishment orders only
Sales Order Invoicing Manager	Match invoices to POs for payments; prepare IDTs, , for charges to other departments. Additional Banner roles [Finance Query] may be necessary to view Banner invoice data.	View orders, Export Search Results, Create Sales Invoices/Credit memos (will not be used under current processing plans), View All sales orders	Currently not planning to use

New Marketplace Roles	Description	Permissions	Associated Banner Role	Notes
Catalog Manager	Has the ability to create new catalog items, remove current items, change prices on items, and edit other items details such as UNSPSC code, item category, URLs for images or other info, etc	Edit Items/Catalogs - Item details Syndicate Prices Hosted catalog Search; inventory search; NO inventory adjustment; NO Replenishment; NO Cycle count catalog mgmt - view hosted catalog, map new location to WH/fulfillment centers; NO Create location; View Punch-out; Access to all fulfillment centers	SPD_DATA_CONTROL_CLERK	Current plan is to use one catalog manager (from MMIS staff) for all catalog additions/edits
UH Stores Requestor	Fulfill and close sales orders, PLUS the ability to place orders FOR OTHER departments;	Place Orders, View my & Org orders, Export Search Results, Fulfill sales Orders, Edit pending sales orders, View All sales orders, Close/Complete sales orders, Inventory Search, NO Replenishment, NO Cycle Counting, NO Inventory Adjustments Search Hosted Catalog ONLY	SPD_SR_MATERIAL_HANDLER_STORES (UH Warehouse personnel only)	UH Staff only - Can place orders to UH Warehouse only through SciQuest permissions

Banner Roles Review: As part of the UMDNJ procedures, a banner re-certification review is sent to all Business offices [schools/units] for them to review/validate the applicability of the access granted to users belonging to the school/unit. Given that SciQuest roles are mapped to banner roles, this validation will check for any users who should not have access [terminated/position change etc.].

Additionally the standard process for Banner provisioning/de-provisioning is required to be followed by all areas within the University to validate and ensure that the access is valid and that access is removed for all terminated employees.

Permissions

Permissions allows/restricts access to functions of the system, navigation tabs, screens, and options are determined for users. Permissions are typically set up at the role level and updated for specific users when necessary.

Internal stockrooms are set up in the same manner as third-party suppliers, access to the hosted catalog items in the stockrooms. Access to stockrooms is restricted based on the areas that the user belongs to. Access to stockroom supplier is enabled through supplier class, then via product views control determining who has access to the supplier.

For detailed information on how to create product views, refer to the Advanced Administrator Handbook.

Tab/Section of Profile	Permission Name	Permission Description
Administration / System Administration
Catalog Management	This permission allows you to perform various supplier and supplier data-related functions. In terms of Supplies Manager, you need this permission enabled to add and set up a new stockroom as a supplier.
Edit Items/Catalogs	This permission is needed to manage inventory items including adding new items, removing items, and updating item data. If this permission is enabled, the item/price navigation menu is visible, which allows you to update item data, images, and prices in mass. Note: For more information on adding and editing hosted catalog data, refer to the Handbook provided by SciQuest Supplier Enablement.
Syndicate Items/Prices	This permission is used in conjunction with the one above and allows you to syndicate submitted content which applies the data to your site and users. Note: For more information on adding and editing hosted catalog data, refer to the Handbook provided by SciQuest Supplier Enablement.
Administration / User Administration
Edit Fulfillment Center Access	Allows edit access to the Materials Management Fulfillment Center Access tab via the user profile or by fulfillment center. This permission allows an administrator to determine which fulfillment centers stockroom personnel have access to.
Supplies Manager (NOTE: This is a new tab in 7.3)
Manage Locations	Allows you to create and manage locations in Supplies Manager, including manually creating/editing locations and using the import/export features. If this permission is enabled, the inventory management location mgt sub-tab displays on the users screen.
Inventory Search	This permission allows you to search inventory items and view inventory items and receipts associated with items. This is a fairly low-level permission in terms of Supplies Manager because there is little opportunity to make data changes

Inventory Administration	This permission allows you to perform a number of administrative tasks including exporting search results, using reports and the dashboard, importing inventory receipts, kiosk overages, and to set up inventory parameters at the item-level and fulfilment center level.
Adjust Inventory	This permission enables users to perform many day-to-day activities in the system, including receiving inventory, editing receipt information, incrementing inventory, and decrementing inventory.
Replenishment	This permission is typically granted for the individuals that are responsible for creating replenishment orders and creating the relationships between inventory items and supplier items. This permission allows a user to create and edit the relationship between an internal stores item and a supplier third-party item, allows you to view the replenishment report, create replenishment orders, and mark orders as replenishment orders. NOTE: Your approval workflow is still intact after orders are sent out; meaning if you require approval, the orders will not be sent directly to the supplier.
Cycle Counting	This permission allows a user to perform cycle counting tasks, including importing cycle counting results.
Orders/ Sales Order Fulfilment
Forward Sales Orders	This permission allows users to forward a sales order to another user that is allowed to fill sales orders. This permission is typically granted to stockroom personnel using Supplies Manager or individuals receiving orders initially for third-party suppliers.
Fulfil Sales Orders	This permission should be granted to any user that is responsible for viewing and filling sales orders.
Assign Substitute Approver for	Provides the user with the ability to assign a
Sales Order Approvals	substitute for a sales order approvals folder. This permission displays the Substitute link on the sales order fulfilment approvals list page.
Approve/Reject Sales Orders on behalf of another Approver	Provides the ability to approve or reject sales orders for another user. This is a very powerful permission and should be assigned with caution. This permission allows a user to open POs that are assigned to another user and continue them in the process. The “change of hands” is tracked in History. This permission does not allow a user to view other user’s folders. You must have the permission below (Manage Other Approvers SO Approval folders) to perform this task.
Manage Other Approvers SO Approval folders	Provides the ability to access and view another users Sales Order approval folders. With this permission, you can view another approvers workload. To be able to approve or reject the orders that you are reviewing, you must also have the permission listed above (Approve/Reject Sales Orders on behalf of another person).
Edit Any Pending Sales Orders	Provides the user the ability to edit any Sales Order that have not been completed/closed. This includes any Sales Order currently assigned to another approver for fulfilment.
Create Sales Invoices/Credit Memos	User is able to create a sales invoice or credit memo. The completed sales invoice/credit memo will be delivered to the customers Select Site / Higher Markets Settlement Manager module
View Sales Orders	The user can see the Sales Order Search screen, perform Sales Order searches, view Sales Order Search Results and view Sales Orders.
Close/Complete Sales Order	The user will be able to close the sales order once the sales order has been totally shipped.

Permissions Review: An annual documented review will be performed to ensure that the permissions granted to the role identified in (a) is accurate, complete and continue to be authorized.

Password Authentication

Password authentication is maintained through the single sign on process via the Luminus (my.umdnj.edu) Portal, for all users including ‘kiosk’ users (UH Stores Requestors).

System Admin access is via a separate URL into the SciQuest systems. SciQuest enforces strong password requirements.

Password history settings

SciQuest Password Configuration settings are as under:

The SciQuest Password configuration is used for local authentication methods only. This setting increases the security for logging into the application. Checking this box applies the following requirements for users' passwords:

Passwords must not contain significant portions of the user's account name or full name

Passwords must have a minimum length specified by the organization

Passwords must contain characters from at least three of the following categories:

Uppercase alphabetic characters

Lowercase alphabetic characters

Base 10 digits (0-9)

Special characters (anything that is not a number or letter)

Password expiration interval (days) 90 Notify of password expiration (days) 7 Show reset password [X] Minimum Password Length 8 Password must meet complexity requirements [X] Number of old passwords to remember to prevent password reuse 6 Max No. of failed login attempts 3 Time to wait before resetting the failed login count (sec) 1800 Session idle timeout (sec) 1800 Session max lifetime (sec) 0 Registration [ ] User Registrations Automatically Approved [X] Send New Users to Profile [X] Force users to change password on login after password reset by Admin [X] Show session timer during punch-out [ ]

Administrative Access Controls

Hardware

The Marketplace solution is a vendor web hosted solution. Access to SciQuest hardware is not permitted by any UMDNJ personnel (which includes the backend Database).

While there are no additional or new Banner integrations as part of the scope of this project, the existing IFEP (Banner Integration) hardware remains unchanged. The access to these servers is maintained and monitored by CST, CA-IS&T.

Software

Access is initially granted to the main administrator by the vendor, SciQuest. Larry D’Ambrosa of Material Management/Purchasing is considered the main system admin, with his back up being Mary Dowling (see section 4.2 for contact info)

See section 5.3 for Admin password authentication requirements.

Periodic System administration activity review: Bi-Annual documented review of the system admin activity will be conducted by Main System Administrator to ensure that all activity performed by system administrators are appropriate and authorized. Additionally an external member [outside the System admin] team will be nominated by T. Kenyon to review specific activity performed by Main System administrator on an annual basis.

This review will include review of permissions [grant/deny] for all roles related to the Supplies mgmt module.

Incident Response

Any and all potential security breaches will be reported to CA IS&T Information Security Office [ISO]. Since this is a web hosted solution, reports of security issues will be generated by SciQuest through the system administrator who has the responsibility to report incidents.

Audit Trails

The system inherently has audit trail functionality. It tracks all requisitions, purchase orders and inventory adjustments based upon the nature of the change, the person who made the change and when a change occurred. Approval information is also stored in the system.

Security Testing

**See the Section 2.3 Security Testing in the embedded sample Project Test Plan to see how Security Testing can be incorporated into an overall project test plan.

Approval

The individuals below agree that they have reviewed and approved the information documented in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date
Implementation Team	06-02-20xx
OIT ISO	06-07-20xx