Implementing Security Cs Ps

<Insert Picture Here>

Implementing CS Security as Part of Your Project

Introductions

• Denise Goin– 3 years of experience with Oracle Public Sector/Higher Ed• 14 years of experience with the PeopleSoft software in Higher

Ed, City Government, K-12 and Public/Private Commercial sector.

• John Thompson-Haas– 12 Years with PeopleSoft/Oracle Public Sector/Higher Ed– 11 years Consulting experience with PeopleSoft Campus Solutions• 5 years experience with PeopleSoft Consulting implementing

Student Financials• 6 Years with Oracle Consulting as a Project Manager

implementing Campus Solutions

• Both of us have worked on a number of different types of implementation, with a number of different types of schools – state schools, private, for-profit and web based.

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions.The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Safe Harbor


Overview

During any implementation or upgrade, security becomes a huge project task. The typical project will run into resource issues as the functional teams are trying to accomplish their testing and configuration. Security tends to get put on a back burner, or even forgotten about as pressing deadlines start to loom closer and closer.

How do you plan security tasks into a project, so that you are better prepared, and what considerations should be prepared for early on in the project to help pave the way down the road?


Agenda

• What decisions need to be made in the first month of the project plan?

• Who should be making those decisions?• Early tasks that should be taken prior to letting the users

into the database environments? • Mapping pages- Who and How?• PeopleTools, Reporting Tools and other misc. page permissions• Designing, Building, and Testing permissions• Row Level security, Defining SACR, Functional teams responsibilities

for Security Config pages• When do the teams give up “God Access” and start using “production

access” in testing• Tips for Success

Decisions, Decisions

• You never get a second chance to make a first impression– No matter how good a job you do on the implementation, if on

the first morning in production, users can’t log on to do their job, or they can’t get to a process they need to do their work – they will think the implementation a failure no matter how smoothly things go that afternoon and in following days


• Before you Begin– Identify who will handle security• Identify ONE person. Security needs to be coordinated

between modules. Having one person ensures that happens

• This person should not have a major commitment to other aspects of the project

– This will be a 4-6 month commitment– This person should be trained in security and PeopleTools– It is very helpful if this person has shown the ability to work

across a number of departments– This person should understand how security works in the

legacy system


• Security should be treated just like a module– Divide your tasks accordingly • Fit-Gap• Design• Build• Test• Transition• Deploy

Fit-Gap

• The more you put into the Fit-Gap and design sessions up front the easier the build and test will go and the smoother the transition and deploy phases will be.

Fit-Gap

• Have all your module leads involved– The initial goal is to understand each area’s security needs.

They are different.• What are those unique needs?• What data does each area need to see? What data

shouldn’t people see?• What are the needs for Student Workers? For Library,

Campus Police and Health Center?– Once requirements have been gathered discuss the

approach for structure• Will your institution focus on the user’s roles or their job

functions

Transition from Fit-Gap to Design

• Which area controls access to which data?– For joint owned data, configuration, tools establish cross

module meetings early to make decisions about this security access. Not just cross module within Campus Solutions, but also HCM.• Personal Data, configuration as well as the data– Address– Social Security– Phone Numbers– Email addresses

• SETID configuration, HCM tables are needed for CS to allow fields like Deptid to work properly

DesignNon-Production Security- Design security for initial testing and configuration of the system• Create a minimized menu permission list for teams to use in

development and testing– Remove foreign pages– Remove menus from modules not being used (If a CS

implementation, take off HCM pages)– Remove pages that are replaced every year (Financial Aid previous

years pages)– Remove Installation pages from general users, they will not need

them in production– Remove Tools pages that are not going to be used

• Create a display only permission list based on the above– this will come in handy in future months, especially in Configuration

database.

• Create Custom Query Tree(s)– Start off right- get the tree set up as you want it in production

• Start with a kick off meeting– Introduce the teams to the different layers of security • Define what each part is, and use examples that will map

the “new security terms” to the legacy system– Determine a “go-to” person for each module that the security

person/team can go to for decisions– Introduce the concept of the cross module meetings– Explain the difference between non-production and

production security– Introduce any security decisions that are already made as

defined by policy now- before they decide on another course of action

DesignProduction Security

• The Security Lead documents these decisions and begins the hard work of design.– Create a spreadsheet for each module to start mapping

specific pages to the roles in their offices and external offices• Split the spreadsheet up by modules pages- the users can

map their own module• Create a “shopping list” for pages they think they need

from the other modules– In the cross module meetings, go through the shopping

lists– Introduce this spreadsheet in the Kick Off meeting, with a

hands on demonstration as well as instructions



Transition Design to Testing

• Teach the testers how to report security issues• “This page doesn’t work”• “I am opening Maintain Students, and getting no results on

the search page”– Get the navigation as well as the page name- Sometimes there

are multiple paths to the same page• Main Menu > Campus Community > Personal Information (Student) >

Add/Update a Person • Main Menu > Campus Community > Personal Information > Add/Update

a Person

– Refresh their minds of the differences between Application Security, Data Security and other SACR Security issues

• Don’t try to combine testing security for the first time with a first run of SIT or UAT

Testing

• Create Role-Based Production Security UserID’s• Create “Module AllPage” UserID’s– One per module– Allows “Go-To” person access to log in in case of security

issues and keep testing if Security testing is taking place during additional SIT/UAT testing

– Makes the transition from “God Access” to Production access easier to bear

• Use Realistic Row Level Security • Use Production Query Security• Don’t forget regression testing with each module as it

goes live

Testing

• Document, Document, Document– Who authorizes changes to the security design originally

requested?• Functional testers should go to their modules “Go-To”

person• Only changes from the “Go-To” person for each module

will be implemented during testing process• The security from the Cross Module meetings must go

back to the Cross Module meetings for change approval– After testing• Send out a new matrix of the security showing the pages

in each permission list/role for final sign off

Transition from Testing to Production

• Determine a cut off date for changes to security• Move security to Configuration database as it is

signed off• If there is already a “Live” database, move the roles

(without permission lists!) to production early• Build UserID’s before database is copied for Go-Live– Create UserID’s using the “empty” roles already moved– Keep Locked until go-live– If UserID is a user already in production, adding empty roles

will not impact user

Production

• Go-Live– Move Permission Lists– Unlock UserID’s– Run Security Processes– Have your all pages permission list from testing and your all

pages read only permission list moved into production before go-live, so that when the security processes are run, these permission lists will be ready to be assigned “just in case”

• Have a plan for critical and non-critical security changes already in place, who can authorize, who needs to be notified?

Tips for Success

• Create Test and Training ID’s initially. This helps the testing and training process move forward without locking down in production security too soon– Security Lead should test security before it is released to

users for testing– No matter how much time you spend up front it won’t be

perfect. You will find new requirements as you test, and as more constituents are brought on.

Tips for Success

• PS Security is complex and multilayered– EVERYONE at your institution will impacted– You will need to develop a design that has contradictory

goals: It is secure, It is flexible, It can be put it in the time you have

– Decide your security approach

By roles or by function

Advantages to each

Tips for Success

• Creating Security takes longer than you think it will. It is never too early to start!– Someone on your team needs to be dedicated to putting in

security. • It is a full time task for 4-6 months.

– This person must be trained before they begin - this is not something that you can pick up reading PeopleBooks as you go along.

– Remember that functional resources will also have to devote time throughout this process• The module teams will say “We have to have the process

working or security will not matter” • Without security, the module teams will not have access to

the pages for their processes!

Tips for Success

• Project Management MUST Support the process• Time has to be allocated early in the project plan• PM Must support the Security Lead in getting the

information they need. Users will push back and will tell you they don’t have time. • PM Must ensure these tasks are taken care of and

the Security Lead has the information they need

Tips for Success

• Security needs will not stop after go-live• As more and more users start logging into the system,

adjustments will be requested• New Hires, transfers, row level, new query security

requests, new pages, customizations, patches/updates/upgrades

• THE LATER YOU START THE HARDER IT WILL BE!

Questions?

Contact us:• John Thompson-Haas – [email protected]• Denise Goin – [email protected]

• For a copy of this presentation contact us at: [email protected]

• Please complete the survey at: http://www.heug.org/p/su/rd/sid=283

Documents

Implementing Security Cs Ps