sony pictures entertainment inc. - wikileaks · sony pictures entertainment inc. ... spe’s...

SONY PICTURES ENTERTAINMENT INC.

EXHIBIT A

WORK ORDER

WORK ORDER to the Agreement dated 27 May 2009, by and between Sony Pictures Entertainment Inc. (the "Company" or “SPE”) and FishNet Security Inc. ("Consultant" or “FishNet Security”).

1. SERVICES:

See Attached Exhibit 1

2. TERM:

From date of last signature below until a date to be determined, or until earlier termination pursuant to Section 11 of the Agreement, whichever is first.

3. COMPENSATION:

See Attached Exhibit A

4. MANAGER:

Project Manager: Kunal Mittal

5. PERSONNEL:

Consultant employees: See Exhibit 1

AGREED AND ACCEPTED this 18th day of November 2013

FISHNET SECURITY, INC. SONY PICTURES ENTERTAINMENT INC.

By: __________________________ By: ____________________________

Its: __________________________ Its: ____________________________

Date: __________________________ Date: ____________________________

Securely Enabling Business

Proprietary and Confidential pg. 1 v.5

Scope of Work

Scoping Considerations Specific details relating to the scope are listed below. Scoping details were provided by SPE through documents and/or interviews; and some assumptions may have been made based upon industry best practices. Significant variance from this information may result in a Change Order. FishNet Security will not perform any additional work outside of the scope described in this Statement of Work (SOW) without a signed Change Order.

SPE’s existing IDM system is Lighthouse Waveset Identity Manager and it will be end-of-life by 2014. Recently, SPE has completed a current state assessment with a third party advisory firm and found opportunities for improvement in both process and technology. In additions, SPE has also evaluated multiple vendor solutions and is considering SailPoint IdentityIQ product, as well as add-on modules, to replace Lighthouse Waveset Identity Manager.

SPE has defined this engagement scope as:

• Phase 0: Lighthouse Waveset Identity Manager Replacement – This phase will mostly focus on replacing existing Lighthouse Waveset Identity Manager with SailPoint IdentityIQ product. All Phase 0 “As is” requirements and customizations should be replaced by the new IDM system, as it relates to the scope and functionality as outlined, which may not warrant a 1-to-1 replacement approach. (See “Scope for Phase 0” for detailed task deliverables)

General Project Scope:

1. Existing IDM System

Lighthouse Waveset Identity Manager (Version 8.0.0.2)

2. Proposed New IDM System

SailPoint IdentityIQ based product (Version 6.0) and Add-on Modules:

• IdentityIQ Lifecycle Manager • IdentityIQ Provisioning Engine • IdentityIQ Service Desk Integration (for ServiceNow) • IdentityIQ Compliance Manager • IdentityIQ SIM Provisioning Integration Module (for low risk migration; see “Detailed Tasks and

Approach”)

3. Authoritative Sources

• Pinnacle – phone number (domestic and international) • Archibus – location (domestic and international) • Workday – Global HR System: US and international employees (non-union) • Time and Attendance System(TAAS) – Backlot and union employees



4. User Populations

As of Feb 2013, SPE has about 38,000 users in various workforce types in both US and international locations.

Workforce Type Description Users

Regular Workforce type representing employees on SPE Payroll administered by P&O through Workday Example: Corporate blue-badge employees, Imageworks employees

6,821

Joint Venture Workforce type representing Sony Joint venture employees Example: SPTI-Colombian TV partnership in Teleset, etc

298

Sony non-SPE Workforce type representing non-SPE Sony workers Example: SCA, SEL, SNEI, DADC, etc

830

Regular TAAS

Workforce type representing employees on SPE Payroll, managed in TAAS by Payroll Example: Backlot employees or union employees supporting productions on studios lots

691

Production Workforce type representing workers on the Production side using SPE facilities or systems Example: Digital Series, Term Deals, Columbia Pictures, SPT, etc

2,877

Consultant

Workforce type representing someone not on SPE/Sony payroll, who either works at an SPE facility or requires SPE system access in a consulting or contractual capacity. Example: Wolfgang Puck, Tentek, TCS, etc

2,575

Intern (non-paid) Workforce type representing limited-time internship hires Example: AXN, Animax

206

Temporary Someone not on SPE payroll brought in for a temporary short-term assignment. Example: Staff Management

575

External Workforce type usually representing ‘customer’ population (quadrupled in the last 3 years) Example: B2C customers accessing mySPT, etc

22,912

Test/Srvc Accounts Test accounts and service accounts 46

TOTAL 37,831

Scope for Phase 0:

Existing IDM system will be replaced by the new IDM system (SailPoint IdentityIQ Platform) according to existing functionality and “as-is” requirements listed in RFP section 2.6. (For a list of applicable requirements covered by phase 0, please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details)

1. Authoritative Sources Integration

• Workday (bi-directional and US interface only in Phase 0) • TAAS (bi-directional) • Pinnacle (Telecom attributes – read only) • Archibus (Location attributes – read only)



2. Automatic Provisioning and Deprovisioning

New IDM system will provide user provisioning and deprovisioning to the following systems: (please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details)

• SunOne LDAP • Active Directory • IBM Domino • Novell eDirectory • Exchange Server (integrated via PowerShell Script) • GateWorks and ServiceNow (integrated via web services)

3. Identity Management

Based on specific requirements listed in RFP section 2.6 (Phase 0 and As-Is), identity management in the new IDM system will include: (please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details)

• IAM Admin Roles

• Search Identity • Create Identity • Reactivate Identity • Update Identity • Terminate Identity

4. Identity Services

Based on specific requirements listed in RFP section 2.6 (Phase 0 and As-Is), identity services in the new IDM system will include:

• Password Management • Login • Access Control • Forgotten Password • Self Service

(Please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details.)

5. Other Requirements

Please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details.

• Reporting • Batch jobs and Background Scans • Availability (fault tolerance, monitoring, and load-balancing) • Audit and Support • Privileged Accounts (password related) • Audit of Accounts (audit report)



6. User Interfaces

• Lighthouse Waveset Identity Manager Native User Interface will be replaced by the new IDM (SailPoint) interface. Global Account Administration (GAA) will be able to create and maintain accounts in IDM on the new interface.

• Custom applications and interfaces will be able to make web service calls to new IDM system to handle user management operations (create/modify).

7. Migration (Data Migration and Conversion Strategy)

Please note that even though migration requirements are marked as “Phase 1” in the RFP, these requirements will be fulfilled in Phase 0 if our approach is selected.

SailPoint Sun Identity Manager Provisioning Integration Module (SIM PIM)

By leveraging SailPoint SIM PIM, FishNet Security recommends SPE to migrate from Lighthouse Waveset Identity manager to SailPoint IdentityIQ in multiple sub-phases within Phase 0.

SailPoint Provisioning Integration Modules (PIMs) are request/response interfaces between IdentityIQ and provisioning applications. IdentityIQ PIMs allow IdentityIQ to use the existing connector infrastructure deployed through the 3rd-party provisioning solution to aggregate users, accounts and entitlements, as well as, push changes resulting from compliance and lifecycle management processes down to connected resources.

By using the out-of-the-box SailPoint SIM PIM, IdentityIQ can be integrated with SPE’s existing IDM system in the beginning and gain visibility to users, accounts, and entitlements in production with ease. Instead of migrating data from one system to another system at the end of the project, this approach allows both systems to co-exist and communicate with each other in a relatively early stage. Therefore, data will be in sync at all time and there is no risk in data migration during production cutover. (For more information on our approach, please refer to “Approach and Methodology”.)

Scoping Assumptions

• Any special conditions, not stipulated at the time of this quotation, such as late evening/early morning hour requirements (Monday-Friday 5PM-8AM and weekends), or any other special testing windows not stated during the initial scoping, may result in additional fees and may require a Change Order.

• All FishNet Security IIQ architects and engineers will require the following access: o Administrative access to their workstations (if using a customer asset) o Connection to the customer’s network o SSH or RDP access to the Development and Test environment servers on which IdentityIQ is

installed o Administrative access to the servlet container to load new web-application (war files) o Ability to stop/start/restart the servlet container o Access to the “IdentityIQ” database, for SELECT/INSERT/UPDATE/DELETE access to table content

• If SPE workstation is provided to the FishNet Security engineer(s) or architect(s), the following hardware specs are required/recommended: o Two (2) GB RAM (minimum), four (4) GB RAM recommended o 80 GB hard drive space o One of the following OS – Windows XP/Vista/7, Linux (RedHat), MacOS



• If SPE workstation is provided to the FishNet Security engineer(s) or architect(s), the following software will be installed: o Sun Java JDK 1.6 (or equivalent for the OS) o Apache Tomcat 6.0 (latest patch) for Windows, Linux, or MacOS o 7zip Archive Program o Eclipse Java IDE and text editor o Notepad++ for Windows, TextWrangler for MacOS, GEdit and Vi for Linux o TortiseSVN Subversion Client for Windows, Native SVN command line clients for Mac/Linux o Tail for Win32 for Windows systems, native tail command for Linux o D Server client o Squirrel SQL Client or similar for JDBC DB querying and testing

• For any delimited file/flat file feeds (applications), IdentityIQ will require FTP or SCP access to the systems/servers/folders were these files will be located

• All applicable firewall rules will be implemented to allow communication between IdentityIQ and any in-scope target systems (applications) where direct connection is in play (read-only or read/write): o For the Development environment, this should be completed prior to the commencement of the

engagement.

• Custom applications make web service calls via standard SPML 1.0 (Service Provisioning Markup Language) to handle create and modify user operations.

• SPE will provide a QA resource(s) to be involved starting in the Analysis phase of the project. SPE QA Resource(s) will be responsible for test plan strategy, test case definitions, test environment set up and maintenance, end user testing, and the overall SPE user acceptance process.

• FishNet will provide assistance to SPE during the Functional and/or User Acceptance Testing (In QA) in the form of reviewing test plan and test cases, assisting in test case staging in the QA environment, as well as general support with inquiries about the FIM solution in support of enabling the SPE QA resources to complete the Functional Testing/UAT efforts.

Exceptions

• In order to confine the scope to a more manageable size, all requirements marked as “Phase X” or “Phase 1 or Phase X” are out of scope for Phase 0 and Phase 1 unless the requirements are explicitly included in this response. Please refer to “Appendix B-1 FishNet Security Phase 0 and Requirements Mapping” for details.

• This SOW only covers identity management products, the design, development, management, and/or replacement of the following systems/products are out of scope: o CA SiteMinder o RadiantOne Virtual Directory Servicer o All authoritative sources o All target resources/applications



Project Approach and Methodology

Sun Migration Approach Identity Management often represents one of the most ambitious enterprise solutions an IT organization will deploy. Consequently, IAM is an organizational, process, data, and cultural challenge first, and a technology challenge second. FishNet Security’s experience with IAM has led to the following rules for success:

• Incremental wins of high value and least pain are essential • Incremental go-live quick-wins are essential milestones prior to executing a full-scale business

process reengineering effort

Based on our IAM experience and pervious Sun replacement projects, FishNet Security recommends that SPE use a sub-phase approach for SPE Phase 0 in order to minimize migration risk and build momentum with deployment wins along the way.

Approach to Phase 0

Phase 0 of this project is the most critical juncture of the whole IAM initiative and the success of the replacement is vital to all the following phases. Due to the sheer volume and complexity of this project, FishNet Security proposes a 5 sub-phase approach within Phase 0 to reduce risk and gain quick wins in Lighthouse Waveset replacement:

• Sub-Phase 0-A: Planning and Analysis – This phase ensures that FishNet Security and SPE will focus on deploying a new solution that will meet the current business needs, challenges, and priorities rather than focusing on a technical 1-for-1 functional replacement of Sun Identity Manager. A 1-for-1 replacement approach may have created a situation where a number of the current challenges would have still occurred or customizations would have been required in the current solution to “look like” Sun.

• Sub-Phase 0-B: SailPoint Deployment and Normalization – The goal of this sub-phase is to put SailPoint in place and have it leverage the existing Sun infrastructure through the use of the SailPoint SIM Provisioning Integration Module (PIM). The advantages to this approach is to: o Reduce the need to focus on the development of connectors immediately o Allow for time to normalize the roles in SailPoint and focus on UI designs while leveraging the

current provisioning processes o Aggregate and centralize all existing Sun IdM data into IIQ

• Sub-Phase 0-C: Authoritative Identity Source Migration – This phase will start the migration process from the identity source; we will deploy connectors for authoritative sources in IIQ – TAAS, Workday, Archibus, and Pinnacle. Once IIQ has a view to all the ID sources, the Sun connectors to these ID sources can then be retired.

• Sub-Phase 0-D: Lighthouse Waveset UI and Workflow Replacement – By leveraging the SailPoint SIM PIM, our team can focus on cloning the current workflows and UI components and migrate the functionality onto the new user interface. This approach reduces the risk by limiting changes at a manageable pace.

• Sub-Phase 0-E: SailPoint/Lighthouse Waveset Connector Transition – This final sub-phase of the transition allows FishNet Security and SPE to build new connectors to resources and de-commission the legacy Sun connectors over time.



Key Activities

Phase 0 – Lighthouse Waveset Identity Manager Replacement Key Activities

Sub-phase 0-A: Planning and Analysis

• Review SPE Current State Requirements and Documents • Translate SPE requirements into SailPoint specific Requirements • Create SailPoint Technical Design Document • Create detailed project plan, activities, and milestones for IDM replacement project • Install/configure development SailPoint environment

Sub-phase 0-B: SailPoint Deployment and Normalization

• Install/configure QA SailPoint Environment • Install/configure production SailPoint Environment • Install/configure SailPoint SIM Provisioning Integration Module (PIM) on each environment • Provide visibility to IdentityIQ by populating the Identity Warehouse with Lighthouse Waveset IDM

data

• Aggregate and normalize Identity Warehouse data • Harden operation systems in development, QA, and production environments • Performance-test the system prior to implementing more phases • UAT Testing

Sub-phase 0-C: Authoritative Identity Source Migration

• Deploy SailPoint connectors for TAAS, Workday, Archibus, and Pinnacle

• Integrate SailPoint with authoritative ID sources in parallel with Lighthouse Waveset • Configure attributes mapping on the SailPoint connectors • Testing of new SailPoint connectors • Import identity data to IIQ from ID sources • Integrate ID sources with SailPoint SIM Provisioning Integration Module (PIM) • SailPoint connector production go-live

• Sun ID source connector retirement • Production Stabilization and Monitoring • Develop Attribute Mapping Matrix for Target Systems • UAT Testing • Convert MIIS ID correlation rules to SailPoint correlation rules

Sub-phase 0-4: Lighthouse Waveset UI and Workflow Replacement

• Migrate UI components and forms • Migrate workflows and approval processes



• Migrate roles, account and password policies, and rules

• Migrate automatic user provisioning • Configure login, password management, access control, forgotten password, and self-services • Configure Reporting, batch jobs, and audit • Migrate and configure complex Admin Roles from Sun to SailPoint • Convert Express Rules from Sun to SailPoint Rules • Migrate custom and complex Sun approval processes

• UAT testing • Performance testing • UI and workflow production go-live • Production Stabilization and Monitoring

Sub-phase 0-5: SailPoint/Lighthouse Waveset Connector Transition

• Develop new SailPoint connectors for: o Sun One LDAP o AD o IBM Domino o Novell eDirectory o Exchange Server o GateWorks o Service Now o SAP (FishNet Security will test the custom call via BAPIs, but there may be a SAP restriction to

prohibit a third-party password update.)

• Replace the Sun connectors with the above new SailPoint connectors • Retire SailPoint SIM Provisioning Module once all Sun connectors have been replaced

Deliverables The following deliverables encompass a methodical, step-by-step process designed to break down the divisional, process, and technical barriers and create a well-defined IAM plan that can be delivered on time and on budget. Documentation Deliverables will be provided in electronic (Adobe PDF) format.

Task-Based Deliverables • Completion of the installation and configuration of the SailPoint IIQ software product in the

Development, Test, and Production environments based on the Detailed Design and Requirements

• Completion of the developed IAM functionality per the approved Design in the Development, QA, and Production environments

• Assistance, on an advisory basis only, with the acceptance testing of the developed IAM functions that support the requirements and design documents prior to transition to production

• Migration of Production-ready IAM functions into the Production environment



Project Management Deliverables FishNet Security will provide the following documents:

• Detailed Project Plan: This will govern tasks, resources, milestones, dependencies, and task duration required to successfully complete the other deliverables associated. This project plan is a living document and will continue to be managed by FishNet Security throughout the project duration. This plan will be built jointly with SPE and will be mutually accepted by both parties prior to execution.

• Weekly Status Dashboards • Weekly AIRDA Logs (Actions, Items, Risks, Decisions, Acceptance)

Requirements and Analysis Deliverables FishNet Security will create a Requirements and Use Case specification, which is a document that captures all of the key user lifecycle-related business and technical requirements, and use cases required in this implementation.

Architecture and Design Deliverables FishNet Security will build a System-Level Architecture Diagram to represent the major components in the overall IdentityIQ deployment.

• Detailed Design Document: A document that features all architectural and IdentityIQ specific configurations, data mappings, and key decision points required to successfully deploy IdentityIQ, per the developed requirements and use cases.

Functional Deliverables FishNet Security will deploy SailPoint IdentityIQ Manager, Compliance Manager, and Provisioning Manager in three (3) formal environments as required throughout the project lifecycle. The deployment will reflect the general scope contained and the requirements and use cases defined specifically as part of this implementation.

Deliverable Acceptance All Documentation Deliverables defined in this SOW are subject to inspection and acceptance by the designated SPE Point of Contact (POC). SPE will agree upon and document any specific acceptance criteria with FishNet Security during the Kick-Off Call, prior to commencement of the associated work. Any special requests (such as additional content or non-standard templates) not stated within this SOW will require a Change Order.

There will be two (2) rounds of draft deliverable review, during which SPE will be given an opportunity to review and comment to ensure the deliverable is complete and accurate, and meets SPE’s expectations. Upon completion of the draft-review rounds, FishNet Security will provide a finalized deliverable for SPE acceptance or rejection. In the event that the Deliverable does not conform to the agreed-upon acceptance requirements, SPE shall so notify FishNet Security in writing, setting forth SPE rejection and the basis of the nonconformity. FishNet Security shall correct such nonconformity within a mutually agreeable timeframe.

SPE will accept or reject the Deliverable within ten (10) business days of the completion of each iteration, unless otherwise mutually agreed upon by the SPE and FishNet Security project managers and documented in the project plan. If SPE does not accept or reject the Deliverable within this period, the Deliverable(s) shall be considered accepted by SPE.



Project Management

Project Management Overview Maintaining clear channels of communication will be necessary to ensure any project success. FishNet Security will conduct status meetings, which may include updates on project status and issues identified and addressed (such as schedule, deliverables, project quality, and team interaction). In addition, FishNet Security will provide immediate notification of issues requiring SPE’s attention. FishNet Security expects that any issues identified will be resolved promptly to avoid impacting the project timelines.

FishNet Security Project Management Activities FishNet Security offers project management services for engagements that require additional oversight, control, coordination, and ownership. These services are standard for certain projects, and clients can add this service to an engagement where it may not be initially included. FishNet Security’s Project Management Activities include:

• Single Point of Contact (POC) throughout service(s) engagement

• Project initiation and kickoff meeting (on-site or remote) • Project plan and Work Breakdown Structure development and dissemination • Issue and risk identification, quantification, and mitigation • Full ownership of project budget, schedule, deliverables, and change management • Detailed project reporting with full visibility into scope, budget, and schedule adherence • Timely and regular project audits and milestone management

• Project meetings and key stakeholder communication (on-site or remote) • Project close-out and final deliverable acceptance

SPE Responsibilities FishNet Security requires time commitments from SPE resources of an estimated 960 hours to effectively meet estimated deadlines; the hours below are SPE personnel hours only.

SPE Member Total Hrs

Project Advocate 80

Program Manager 160

Enterprise Architect 160

Deployment Shadow 80

System Architects/Admins 160

Application Owners 160

Quality Assurance 160

Client Total Hours: 960

SPE Resource Types

• Project Advocate: This role is acting as the owner of the project who will provide executive sponsorship and leadership to the project.



• Program Manager: The Program Manager is responsible to maintain high-level program schedules, activities, and facilitate critical decision making.

• Enterprise Architect: This role will provide technical support and knowledge of the overall environment within the organization.

• Deployment Shadow: The Deployment Shadow from SPE will receive training and acquire knowledge on how to maintain, update, and monitoring the system from FishNet Security.

• System Architects/Admins: The role will provide specific technical details of each particular system for IAM integration.

• Application Owners: The Application Owners within SPE will be able to provide business details, current processes, and future enhancements and roadmap information for the workflow related discussion.

• Quality Assurance: This role ensures that the new system will meet all requirements by testing the functionality, performance, and processes.

The following list details SPE’s responsibilities for this engagement:

• SPE will designate one (1) employee to serve as a primary POC for the project. The POC will be responsible for scheduling SPE resources for required meetings, interviews, and other needs deemed necessary to complete the project work as scoped. The POC will participate in weekly status meetings and will serve as the first point of escalation for any project-related requests or issues.

• SPE is responsible for notifying impacted personnel of the testing as needed, and said testing will be conducted with the expressed authority of management (with full right, power, and authority to consent to services described within this SOW).

• It is SPE’s responsibility to perform backups of data on all devices connected to SPE’s IP addresses and/or domain names prior to invoking the use of the services described within this SOW. SPE further assumes the risk for all damages, losses, and expenses resulting from use of the Service.

• SPE will provide access to all proprietary information, applications, and systems necessary to the success of this project.

• FishNet Security assumes that all client data gathering activities will be executed in an efficient manner and data promptly submitted to FishNet Security consultants within a reasonable response time. Any delays incurred in acquiring this information may result in the need for a Change Order and rescheduling of the project, at the discretion of FishNet Security.

Project Change Control In the process of an engagement, additional work may be required based upon on-site discovery or changes requested by SPE. If variations from the original SOW are deemed necessary, a mutually agreed-upon Change Order will be created. FishNet Security will provide a Change Order for SPE to review and sign before any work outside the original scope is performed or additional expenses are invoiced to SPE.

The Change Order will specifically address the work, software, or other items added to the SOW and the associated costs. A brief explanation of the requirements for the changes will also be included.

Communication Plan

Issue Resolution and Escalation

The Project Manager is the client conduit for any issues experienced during project delivery. The Account Executive is also an available point of communication as needed. Issues that are not addressed to client satisfaction can be escalated using the points of contact shown below.



Professional Services Escalation Path • PMO Hotline • Michael Robbins: Director, Project Management Office • Practice Area Director

• Bernard Batang: Vice President, Professional Services • Aaron Shilts: Executive Vice President, Services

Risk Mitigation

Critical Success Factors/Risk Mitigation

The following factors could contribute to project delays and are considered a risk for service delivery:

• Scheduling and availability on the part of the Client, including availability of primary Point of Contact and team for interviews.

• Additional applications and/or systems found during the discovery phase of the engagement, not stated in scope of work, will incur additional scoping, services, or fees and may result in a delay.

• FishNet Security assumes that all client data gathering activities will be executed in an efficient manner and data promptly submitted to FishNet Security consultants. Any delays incurred in acquiring this information may result in the need for more time to complete the project.

Open lines of communication offset these risks, as well as manage expectations of both the client and FishNet Security consultants, in order to achieve successful project delivery.

Quality Assurance

The FishNet Security approach to quality assurance is a combination of several factors. First, we make it a priority to recruit and retain top talent. Additionally, we maintain requirements for outside training that each employee must meet in order to keep their knowledge and skills current.

Our Project Management process goals are to staff appropriately and promptly and satisfactorily handle any issues that may arise. A peer review process helps to facilitate accurate reporting, and our escalation path provides the necessary backbone to oversee all anomalies and meet client needs.

Post engagement, FishNet Security performs a project closing meeting to gain immediate feedback on the success of the project. That will be followed by a customer survey used to track individual and team performance.

Project Cost Controls/Management

Project Managers monitor project costs throughout the engagement. Costs controls include selection of resources based on geographic location and availability, remote meetings/consulting when possible, minimizing travel expenses by booking as far in advance as possible, etc.

Training Plan

Knowledge Development and Sharing

Knowledge is maintained by the following methods:

• Bi-weekly meetings for each Practice area (knowledge transfer, issue discussion, ongoing training) • Knowledge collaboration through internal SharePoint integration

• Internal Wiki Sites



• Training for new certifications

• Project shadowing • Practice area roundtable meetings

Estimated Timelines Detailed timelines will be determined upon signature of this SOW. FishNet Security will not begin to provide the Services as described until SPE has returned the signed SOW. FishNet Security is committed to completing the project within a timeframe that is agreed upon with SPE.

Estimated Project Schedule

Phase 0: Lighthouse Waveset IDM Replacement Estimated Duration* Estimated Due Date* (Tentative Start Date: 1/13/2014)

Sub-Phase 0-A: Planning and Analysis 5 Weeks 2/21/2014

Sub-Phase 0-B: SailPoint Deployment and Normalization 4 Weeks 3/28/2014

Sub-Phase 0-C: Authoritative Identity Source Migration 4 Weeks 4/25/2014

Sub-Phase 0-D: Lighthouse Waveset UI and Workflow Replacement 7 Weeks 6/13/2014

Sub-Phase 0-E: SailPoint/Lighthouse Waveset connector transition 4 Weeks 7/11/2014

Estimated Total for Phase 0: 24 Weeks

*Please note – time estimates include all labor and documentation. The above timeline is an estimate used for example purposes only. The estimate represents total level of effort for services; it does not represent total duration, as many of these services may be performed simultaneously or by multiple resources. The specific schedule will be determined collaboratively between FishNet Security and SPE at engagement commencement and may vary based on client availability and environment.

Rescheduling or Cancellation

One (1) week’s written notice in advance of the engagement start date is required for cancelling or rescheduling any services. Nonrefundable and/or nontransferable travel expenses will be billed to and paid by SPE at actual cost.



Project Team and Organization

Team Members Each FishNet Security engagement includes involvement of the following team members:

• Account Executive • Strategic Services Director (technical direction)

• Practice Area Director (for oversight) • Project Manager • IAM Security Consultant

FishNet Resource Types

• SailPoint Practice Area Director: SailPoint Center of Excellence (COE) Lead is FishNet Security technology expert in Identity and Access Management. This role will provide SailPoint technical oversight of the project.

• IAM Consulting Practice Area Director: IAM Consulting Center of Excellence (COE) Lead is our IAM business process leader who is experienced in IAM methodology, IAM program execution, and requirements gathering and analysis. This role will provide business/analysis oversight of the project.

• SailPoint IAM Consultant: SailPoint IAM Consultant is a highly trained IAM professional who has the ability to implement a successful IAM deployment based on specific requirements.

• IAM Business Consultant: IAM Business Consultant is responsible to provide business analysis on data, information, and requirements gathered and translate business related IAM processes and procedures into technical design.

• PMO: Project Management Office will manage the project, create project plan, weekly issues log and status report. The role will also interact with stakeholders and facilitate interactions among the team.

Key Points of Contact

FishNet Security Points of Contact

Darrin O’Hanlon Account Executive Office: 310.706.4010 Mobile: 310.266.8271 Email: [email protected]

Ray Tam

Director of Strategic Services, IAM

Phone: 626.500.9180

Email: [email protected]



Pricing The SOW provided by FishNet Security is fixed-fee; all pricing is in US Dollars:

Phase 0 Pricing: Milestone Sub Phase Price Estimate

Week 5 Sub-Phase 0-A: Planning and Analysis $72,816.00

Week 9 Sub-Phase 0-B: SailPoint Deployment and Normalization $72,816.00

Week 13 Sub-Phase 0-C: Authoritative Identity Source Migration $72,816.00

Week 20 Sub-Phase 0-D: Lighthouse Waveset UI and Workflow Replacement $72,816.00

Week 24 Sub-Phase 0-E: SailPoint/Lighthouse Waveset connector transition $72,816.00

Sub Total – Consulting-Only Pricing for Phase 0: $364,080.00

Estimated Travel and Expenses – 20%: $72,816.00

Estimated Total for Phase 0 with Estimated Travel and Expenses: $436,896.00

Consulting-Only Pricing for Phase 0 (without estimated travel and expenses): $364,080.00

Total Estimated Pricing for Phase 0 (including estimated travel and expenses): $436,896.00

Invoice $72,816.00 upon completion of each sub-phase. All travel and expenses will be incurred and invoiced in accordance with SPE’s travel policy.

FishNet security Op. #194396-5

Termination of this SOW for any reason does not release either party from any liability which, at the time of termination, has already accrued to the other party.

Payment of undisputed amounts shall be made by SPE within thirty (30) days after SPE’s receipt of FishNet Security’s invoice. SPE will provide written notification of any disputed invoice within five (5) days of receipt. Disputed amounts shall be paid within ten (10) days of resolution.

This quote is valid for 120 days from the date of the SOW.

Please e-mail/fax signed SOW in its entirety to FishNet Security at [email protected], or 800.878.6115.

mailto:[email protected]


Proprietary and Confidential pg. a v.5

Appendix A-2 – Reserved


Proprietary and Confidential pg. b v.5

Appendix B-1: FishNet Security Phase 0 and Requirements Mapping This appendix arranges SPE’s requirements by various phases proposed. The following requirements will be covered in Phase 0.

FishNet Security Phase 0 Requirements

IAM Admin Roles

# Requirement Priority Phase As-Is /To-Be

2.6.1.1.1 Ability to group one or more actions - like user interface, data update actions - into a role definition.

Must Have 0 As Is

2.6.1.1.2 Ability to define actions within a role at the most granular level - fields within a screen, resource adapter OR columns within a table.

Must Have 0 As Is

2.6.1.1.3 Ability to assign either one role or multiple roles to a user. Must Have 0 As Is

2.6.1.1.4 Ability to delete a role if is not assigned. Must Have 0 As Is

2.6.1.1.5 Ability to create IAM Admin roles that can be assigned to users in order to perform any combination of the following functions. For example, for one role, Admin can perform one of these functions to a specific set of users only (specific workforce types and/or specific territories/regions) and also perform another function to a different set of users only.

• Ability to search all accounts or a filtered set of accounts (i.e. one role can only search external users, another role can only search Europe users) ( As Is)

• Create any account or specific types of accounts only (i.e. can only add external accounts or can only add accounts in Europe). (As Is)

• Provision any resource or specific resources only (i.e. only Europe Admins can provision Cardinus application). (As Is)

• Unlock accounts (As Is) • Enable any account (As Is) but leave them in a terminated state. • Edit any accounts or specific types of accounts only (i.e. can only

edit non-Workday owned accounts, can only edit accounts in Europe).(As Is)

• Edit any attribute or specific attributes only (i.e. can only edit end date). This applies to specific workforce types only, so can only edit attributes for a “Regular FTE” if the workforce type changes to something else. (As Is)

• Manage values in the drop down lists for specific attributes (i.e. Joint Venture company names) (As Is)

• Manage values in the production table (i.e. production name, Line of Business, end date) (As Is)

• Disable specific accounts, depending on attributes (i.e. can only disable non Regular, non TAAS accounts in Europe). (As Is)

• Delete specific accounts, depending on attributes (As Is)

Must Have/ Should Have

0/I/X As Is/To-Be


Proprietary and Confidential pg. c v.5


2.6.1.1.5 (cont.)

• Rename any account or specific accounts, depending on attributes (As Is)

• Move any account or specific accounts, depending on attributes (As Is)

• Reset password (As Is)Ability to do bulk updates to any attribute.(As Is)

• Run any report globally (As Is) • Run bulk updates (i.e. update an ldap attribute for 2,000 users)

(As Is) • Allow access to web services through SPML (As Is)

Allow access to all IDM functionality as a super Admin (As Is)

Must Have/ Should Have

0/I/X As Is/To-Be

2.6.1.1.7 For a list of specific, existing Admin roles that must be implemented. Must Have 0 As Is

Search Identity


2.6.1.2.1 Ability to manually search for users, using various search criteria such as name, company, etc.

Must Have 0 As Is

2.6.1.2.2 Ability to select which attributes will be displayed in the search results (i.e. display email address but not VIP flag).

Must Have 0 As Is

2.6.1.2.3 Ability to filter the search results based on the specific role doing the search (i.e. if user’s Territory = France, include France terminated users. If user’s Territory = North America, exclude France terminated users).

Must Have 0 As Is

2.6.1.2.4 Ability to search for a non-SPE paid internal user by name, Responsible Party or production.

Must Have 0 As Is

2.6.1.2.5 Ability to display search results (active non SPE accounts only) and attributes associated to the results (i.e. organizational info, company info, etc).

Must Have 0 As Is

2.6.1.2.6 Ability to retrieve only accounts in your region. Must Have 0 As Is

2.6.1.2.7 Ability to search by Responsible Party and retrieve list of people reporting to that Responsible Party.

Must Have 0 As Is

2.6.1.2.8 Ability to search by production name and retrieve list of people associated to that production.

Must Have 0 As Is


Proprietary and Confidential pg. d v.5

Create Identity


2.6.1.3.1 Ability to create accounts in IAM automatically whenever an account is created in another system

• Ability to populate specific attributes based on another attribute from the source system

• Ability to populate specific attributes from the source system • Ability to automatically determine if an account already exists in

IAM system based on matching attribute such as employee id. • Once account is created, ability to send data back to the source

systems (i.e. department, title, location, phone, email address)

Must Have 0 As Is

2.6.1.3.2 Ability to generate a unique MIIS id, Userid, and Global ID for each user using current conventions and ingest existing ones into the system.

Must Have 0 As Is

2.6.1.3.3 Ability to automatically create accounts in downstream systems whenever a certain type of account is created in IAM (Gateworks, AD, LDAP, ServiceNow, Web Services, Archibus).

Must Have 0 As Is

2.6.1.3.5 Ability for people to manually create accounts in IAM based on their assignment of a role or assignment of an attribute and restrict the type of account that can be created (based on role, workforce type, region, etc.).

Must Have 0 As Is

2.6.1.3.6 When creating an account, ability to populate a different set of attributes that are specific to each workforce type.

Must Have 0 As Is

2.6.1.3.7 When creating an account, ability to have some fields be drop down values and some fields be free form text depending on the workforce type.

Must Have 0 As Is

2.6.1.3.8 When creating an account, ability to require and not require certain fields for each workforce type.

Must Have 0 As Is

2.6.1.3.9 Ability to manage a table that populates an attribute based on another attribute set from another table (ex. Production table with end dates and User Table with end dates).

Must Have 0 As Is

2.6.1.3.10 Ability to add new attributes. Must Have 0 As Is


Proprietary and Confidential pg. e v.5

Reactivate Identity


2.6.1.4.1 Ability to reactivate accounts in IAM automatically whenever an account is reactivated in another system

• Ability to populate specific attributes based on another attribute from the source system

• Ability to populate specific attributes from the source system • Ability to automatically find a matching account in IAM system

based on a matching attribute such as employee id • Once account is reactivated, ability to send data back to the

source systems (i.e. department, title, location, phone, email address)

Must Have 0 As Is

2.6.1.4.2 Ability to automatically reactivate/create accounts in downstream systems whenever a certain type of account is reactivated in IAM (Gateworks, AD, LDAP, ServiceNow, Web Services, Archibus).

Must Have 0 As Is

2.6.1.4.3 Ability to automatically reactivate/create accounts in downstream systems whenever a certain type of account is reactivated in IAM (Open DJ, Workday, Ariba, Trintech, Oversight, SAP eGRC, JD Edwards, Databases including Oracle DB, MS SQL Server, and SOX applications).

Must Have 0 To Be

2.6.1.4.4 Ability for people to manually reactivate accounts in IAM based on their assignment of a role or assignment of an attribute and restrict the type of account that can be reactivated (based on role, workforce type, region, etc.). Option 2: No reactivation of existing inactive account - instead a new account is created.

Must Have 0 As Is

2.6.1.4.5 When reactivating an account, ability to require that a different set of attributes be populated that are specific to each workforce type. Depending on workforce type, some fields will be pre-populated with existing account’s information and some fields will be blanked out and require the user to enter new information the same way it would be entered if the account was newly created.

Must Have 0 As Is

2.6.1.4.6 Ability for the person’s hire date to take effect on a particular day, time (i.e. activate account on day the person starts. Production user accounts should be active but disabled).

Must Have 0 To Be

Update Identity (includes End Date Extension)


2.6.1.5.1 Ability to edit one’s own identity attributes and be forced to edit/verify those attributes prior to changing one’s password. Which attributes are editable and how they are changed in the source system depends on the workforce type and data owner.

Must Have 0 As Is

2.6.1.5.2 Ability to audit the changes made to any attribute. Must Have 0 As Is

2.6.1.5.3 Ability to restrict edit feature to certain subset of the population. Must Have 0 As Is


Proprietary and Confidential pg. f v.5


2.6.1.5.4 Ability to automatically change account attributes in IAM based on the change of accounts in other systems (Workday, AD, SAP, Pinaccle, Archibus, and ServiceNow or Ariba).

Must Have 0 As Is

Terminate Identity (includes Inactivate)


2.6.1.6.1 Ability to automatically disable/terminate accounts in IAM based on the termination of accounts in other systems (Workday, TAAS, etc.).

Must Have 0 As Is

2.6.1.6.2 Upon termination, ability to populate a termination date into IAM (or other data) and remove resources (i.e. user is terminated and AD and Service Now is removed).

Must Have 0 As Is

2.6.1.6.3 Ability to terminate accounts in IAM manually – accounts of any type or of specific types only (i.e. only interns, only accounts in France, only external accounts, etc.).

Must Have 0 As Is

2.6.1.6.4 Ability to terminate a user account for any integrated downstream system that contains terminated user within 24 hours.

Must Have 0 As Is

Reporting


2.6.2.1 System provides standard reports for: user accounts, entitlements, activity on accounts (including administrative accounts), access certifications, system.

Must Have 0 As Is

2.6.2.2 Audit report showing all accounts created, updated, deleted and inactivated between a certain period deleted and by whom for a specified timeframe for a specified resource.

Must Have 0 As Is

2.6.2.4 Report of all users in IAM which can be filtered by various attributes such as Region, Territory, Status, etc. Must Have 0 As Is

2.6.2.5 Report of all accounts terminated and by whom for a specified timeframe based on one, multiple or no filtered attributes. Must Have 0 As Is

2.6.2.6 Audit report showing change in identity attributes and source of those changes. Must Have 0 As Is

2.6.2.7 Report of all IDM Administrators and the IAM roles assigned to them. Must Have 0 As Is

2.6.2.8 Report of all users added to a resource for a given period of time. Must Have 0 As Is

2.6.2.10 Log of all password changes for a specified period of time. Must Have 0 As Is

2.6.2.11 Report of all errors or notifications that failed to be sent. Must Have 0 As Is

2.6.2.13 Report of all users added and by whom. Must Have 0 As Is


Proprietary and Confidential pg. g v.5

Integration (includes Provisioning/Deprovisioning Applications, Connectors)


2.6.3.1 Ability to connect to/from (bi-directional) Workday HCM for autoprovisioning/deprovisioning (US interface As Is).

Must Have 0, I As Is/ To

Be

2.6.3.2 Ability to connect to/from (bi-directional) Service-Now for automatic provisioning and receiving/sending data see Data Requirements section).

Must Have 0 As Is

2.6.3.4 Ability to connect to/from (bi-directional) Workbrain/TAAS for user ID – autoprovisiong to IAM.

Must Have 0 As Is

2.6.3.5 Ability to connect from Pinnacle for Telecom specific authoritative data attributes (see Data Requirements section).

Must Have 0 As Is

2.6.3.6 Ability to connect from Archibus for Location specific authoritative data attributes.

Must Have 0 As Is

Password Management


2.6.5.1.1 Ability for a general user to manage secret tokens like: (1)password (and resets) (2) secret tokens (3) a set of challenge questions and hint answers.

Must Have 0 As Is

2.6.5.1.2 Ability to apply restrictions on the structure and usage of tokens like: (1)password (and resets) (2) secret tokens (3) a set of challenge questions and hint answers.

Must Have 0 As Is

2.6.5.1.3 Ability to adhere to GISS Requirements on how passwords should be managed including business rules listed within this document (Section 2.6.7 Compliance Requirements).

Must Have 0 As Is

2.6.5.1.4 Ability to set different password policies for user and Elevated accounts (i.e. 6 character minimum for user accounts, 8 character minimum with special characters for elevated accounts).

Must Have 0 As Is

2.6.5.1.5 Ability for user to reset a forgotten password by answering three hint questions correctly.

Must Have 0 As Is

2.6.5.1.6 Ability for a user to update their hint questions. Must Have 0 As Is

2.6.5.1.7 Ability for a user to update their four digit PIN number. Must Have 0 As Is

2.6.5.1.8 Ability for user to reset their own password to a password conforming to specific guidelines (i.e. at least 6-8 characters, alphanumeric, can’t use “password”, etc.).

Must Have 0 As Is

2.6.5.1.9 Ability to display a "Statement of Understanding" and require that the user accept it prior to allowing them to reset their password the 1st time they login.

Must Have 0 As Is


Proprietary and Confidential pg. h v.5

Batch Jobs and Background Scans


2.6.5.2.1 Automatically delete resource accounts (i.e. AD, Domino, NDS) after 30 days of being terminated – by Region.

Must Have 0 As Is

2.6.5.2.2 Automatically terminate accounts based on specific attributes (workforce type, end date passed, password expired, region, etc.).

Must Have 0 As Is

2.6.5.2.3 Automatically disable resource accounts after specific number of days of inactivity.

Must Have 0 As Is

2.6.5.2.4 Automatically trigger notifications to user when their end date is approaching (15 days prior and every day until expiration date).

Must Have 0 As Is

2.6.5.2.5 Automatically trigger notifications to user when their password is expiring (15 days prior and every day until expiration date).

Must Have 0 As Is

2.6.5.2.6 Ability to retrieve data from previous report/scans and export the data from any report or scan into an Excel, pdf or csv file that can be viewed and printed in an easy to read format.

Must Have 0 As Is

2.6.5.2.7 Ability to trigger any report/scan to run on demand. Must Have 0 As Is

2.6.5.2.8 Ability to filter the results of a report/scan based on any attribute and select which attributes are included (i.e. a report might include only Regular, only North America, or only people with AD resource. One report might show name, userid, workforce type and end date; another report might show name, userid, email address and location.).

Must Have 0 As Is

Availability (fault tolerance, load balancing, monitoring, etc)

Requirement Priority Phase As-Is /To-Be

2.6.5.3.3 Provisioning - can alert admins on errors. Must Have 0 As Is

2.6.5.3.4 Monitoring - Detect hung batch jobs (reports, scans, data sync jobs, etc.). Must Have 0 As Is

2.6.5.3.5 Monitoring - Detect and report/alert when downstream systems are not available.

Must Have 0 As Is

2.6.5.3.7 Load balancing – provisioning to downstream systems must be able to scale horizontally.

Must Have 0 As Is

Audit and Support


2.6.5.4.1 Ability to support trace/debug of form-level calculations. Must Have 0 As Is

2.6.5.4.2 Ability to support trace/debug of workflow steps, actions. Must Have 0 As Is


Proprietary and Confidential pg. i v.5


2.6.5.4.4 Ability to support SPML, DSML, SCIM. Must Have 0,I As Is/ To

Be

2.6.5.4.6 Ability to provide unicode support for multi-language display. Must Have 0 As Is

2.6.5.4.7 Ability to support for locale based message display (localization for English, Japanese, German, Spanish, French, Italian Portuguese, Chinese, Dutch).

Must Have 0 As Is

2.6.5.4.8 Ability to encrypt some or all data in the repository. Must Have 0 As Is

2.6.5.4.9 Ability to secure data in transit (i.e. https). Must Have 0 As Is

Privileged Accounts


2.6.7.2.3 Passwords of privileged accounts for the IAM system must be at least 8 characters long.

Must Have 0 As Is

2.6.7.2.4 Privileged account passwords must be a combination of uppercase alphabet characters, lower case alphabet characters, numeric characters and special characters.

Must Have 0 As Is

Audit of Accounts


2.6.7.3.2 Ability to run an audit report on any IAM account for a specified time period and retrieve all actions taken on the account, who made the changes, the date of the changes and whether the change was a success or failure. (i.e show password reset or LDAP attribute changes for ted smith during the past 30 days and who made the changes).

Must Have 0 As Is

Login


2.6.7.4.1 IDM Logo must be displayed. Must Have 0 As Is

2.6.7.4.2 SPE Logo must be displayed. Must Have 0 As Is

2.6.7.4.3 SPE User ID and password must be used to logon. Must Have 0 As Is

2.6.7.4.4 Ability to navigate to “Forgot Password” page must be available. Must Have 0 As Is


Proprietary and Confidential pg. j v.5


2.6.7.4.5 In order to access “Forgot Password”, SPE UserID must be required. Must Have 0 As Is

2.6.7.4.6 Help must be displayed with the ability to see the content as a separate popup.

Must Have 0 As Is

2.6.7.4.7 User should be able to select any of the languages: English, Japanese, German, Spanish, French, Italian Portuguese, Chinese, Dutch and IDM self-service tool should default to the selected language.

Must Have 0 As Is

2.6.7.4.8 A message should be posted on the screen either before or after a user logs into the IAM system discussing the misuse of Sony information.

Must Have 0 As Is

2.6.7.4.9 If the warning message is presented to the user immediately after they have successfully logged in, then the user must indicate his/her authorization by selecting "Yes".

Must Have 0 As Is

Access Controls


2.6.7.5.1 When the number of login attempts has exceeded 10 within a 30 minute period, the user’s account should be locked.

Must Have 0 As Is

2.6.7.5.2 User identification and authentication must be completely processed by the system prior to displaying any failed attempt indicator.

Must Have 0 As Is

2.6.7.5.3 All failed login messages should be non-descriptive (e.g. the message should not indicate what part of the log-in failed).

Must Have 0 As Is

2.6.7.5.4 Any user ID that has been inactive for a period of 90 days or more shall be disabled. Activity should be determined by a user logging into any application using that userid.

Must Have 0 As Is

2.6.7.5.5 With the approval of a business owner, a user ID that has been inactive for a period of 90 days or more can remain active. Activity should be determined by a user logging into any application using that userid.

Must Have 0 As Is

2.6.7.5.6 User should be forced to log in again if they have been inactive on the application longer than 30 minutes.

Must Have 0 As Is

2.6.7.5.7 Password must be encrypted using SSL or other encryption method when transmitted.

Must Have 0 As Is

2.6.7.5.8 Passwords for user accounts must be at least 6 characters long. Must Have 0 As Is

2.6.7.5.9 Passwords must be alphanumeric, using only numbers or alphabet is prohibited.

Must Have 0 As Is

2.6.7.5.10 For all temporary passwords, user should be required to change the password when they first log into IAM and system should require the user to create hint question answers, create a PIN and update their Self-Service Profile.

Must Have 0 As Is


Proprietary and Confidential pg. k v.5


2.6.7.5.11 The following passwords should be prohibited: • The person’s SPE Userid or a sequence that includes characters

of their ID (e.g., not suzukia, if the user ID is suzuki) • When an e-mail address is registered, the sentence before @

(e.g., not xsuzuki, if the e-mail address is [email protected]) • Last name, first name, initial of name, or mixture of them • Substituting only a single character in the old password (e.g.

ac8g?qo1 èac8g?qo2) • Using the sequence of the old password backwards (e.g.

ac8g?qo1 è1oq?g8ca) • The system should force the user to enter the password twice to

prevent entry errors • The word “password” cannot be included in the password string

Must Have

0 As Is

2.6.7.5.12 All passwords sent through email must be encrypted. Must Have

0 As Is

2.6.7.5.13 Permanent passwords displayed on a website must be encrypted. Must Have

0 As Is

2.6.7.5.14 Prior to changing their password, user should be forced to log in. Must Have

0 As Is

2.6.7.5.15 System should require that password be changed every 90 days and a notification should be sent to each user starting 15 days prior to the password expiring reminding them to change their password.

Must Have

0 As Is

2.6.7.5.16 Once the password has expired, user’s account should be locked. Must Have

0 As Is

2.6.7.5.17 Previously used passwords must not be re-used. Must Have

0 As Is

2.6.7.5.18 Require that user passwords be alphanumeric, not include their userid, email address, name, the word “password”, or previous passwords.

Must Have

0 As Is

2.6.7.5.19 Require user to re-login if application has been inactive for 30 minutes. Must Have

0 As Is

2.6.7.5.20 Disable/terminate user account on a user’s end date (based on Workforce Type)- all populations except External and Productions.

Must Have

0 As Is

2.6.7.5.21 Require that temporary passwords expire immediately and require that the password be changed immediately. When initially changing a temporary password, require that the user enter hint question answers, a Pin number and the Self-Service attributes such as location and phone.

Must Have

0 As Is

2.6.7.5.22 Automatically trigger notifications to user when their end date is 15 days prior expiration date, and every day until expiration date.

Must Have

0 As Is

2.6.7.5.23 Automatically trigger notifications to user when their password is expiring 15 days prior to expiration and every day until expiration date.

Must Have

0 As Is

mailto:[email protected]


Proprietary and Confidential pg. l v.5

Forgotten Password


2.6.7.6.1 Users should be able to reset their password, if they have answered their hint questions.

Must Have 0 As Is

2.6.7.6.2 Users must be presented with any random three questions that user must answer correctly(all three) in order to reset the password.

Must Have 0 As Is

2.6.7.6.3 Answers to hint questions should not be case sensitive. Must Have 0 As Is

2.6.7.6.4 There should not be a time limit to answer the three mandatory questions.

Must Have 0 As Is

2.6.7.6.5 After 3 attempts of incorrect answers, account must be locked. Must Have 0 As Is

2.6.7.6.6 If user account is locked due to failed attempts, account must be locked for reset password for 30 mins.

Must Have 0 As Is

2.6.7.6.7 When resetting a password, users should be forced to enter their new password twice.

Must Have 0 As Is

2.6.7.6.8 After changing their password, user should be notified, by email, that their password has changed (the email should include a request to the user to contact the system operator if the user is unaware of the change).

Must Have 0 As Is

2.6.7.6.9 If hint questions are not set up, message must display redirecting user to the Global Service Desk to reset password.

Must Have 0 As Is

Self-Service


2.6.7.7.1 Users must be forced to enter PIN if they have not previously entered one when they login to IDM self-service tool.

Must Have 0 As Is

2.6.7.7.2 PIN can only be numeric and 4 digits long. Must Have 0 As Is

2.6.7.7.3 Users must confirm the PIN they enter before submitting. Must Have 0 As Is

2.6.7.7.4 PIN should never be visible in clear text (while adding). Must Have 0 As Is

2.6.7.7.5 Users must select from the list of 10 questions provided and should not be allowed to type their own question.

Must Have 0 As Is

2.6.7.7.6 Users answers to the Hint Questions are not visible on edit. Must Have 0 As Is

2.6.7.7.7 After successful login using SPE credentials, users should have the ability to do the following: change password.

Must Have 0 As Is


Proprietary and Confidential pg. m v.5


2.6.7.7.8 User should have the ability to do the following to their own account: Answer or edit their Hint Questions, change PIN, change Language Preference, inactivate an IDM account, update identity attributes, manage delegated Responsible Parties.

Must Have 0 As Is

2.6.7.7.9 When users are changing their password, SPE Password Policy must be displayed.

Must Have 0 As Is

2.6.7.7.10 When users are changing their password for the first time, the SPE Statement of Understanding message must be displayed.

Must Have 0 As Is

2.6.7.7.11 When users are changing their password , user must click “I Accept” to the SPE Statement of Understanding message in order to proceed and system must store this acceptance date.

Must Have 0 As Is

2.6.7.7.12 When users are changing their password , must be required to enter their current password in order to change their password.

Must Have 0 As Is

2.6.7.7.13 When users are changing their password , must be prompted to confirm their new password.

Must Have 0 As Is

2.6.7.7.14 When users are changing their password , change in password must sync user’s password across all IAM managed resources and applications.

Must Have 0 As Is

Migration (Please note that the followings are listed as Phase 1 but will be covered in Phase 0 instead)


2.6.5.5.1 Ability to exist in parallel with Sun IDM. Must Have I To Be

2.6.5.5.2 Ability to ingest historical activity logs. Must Have I To Be

2.6.5.5.6 Must migrate all users from current IDM/ Sun solution. Must Have I To Be