Implementing Security Cs Ps
Upcoming SlideShare
Loading in...5

Implementing Security Cs Ps



Implementing Campus Solutions Security as Part of Your Project

Implementing Campus Solutions Security as Part of Your Project



Total Views
Views on SlideShare
Embed Views



1 Embed 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • What decisions need to be made in the first month of the project plan? (3c, groups, si’s the whose & methodologies) Who should be making those decisions? Early tasks that should be taken prior to letting the users into the database environments? (process, mass change, primary, dda, query trees, baseline user profile for self-service. 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 (enrollment, actions
  • If using consultant, bring in early, get through 80% or so, then come back week or two before go-live through week or two after
  • Main Points- Get the leads behind this early on, separate security pieces, App security, data security, query security, process security, mass change, search match, and the list goes on! There can be more than one way to reach the same page, highway, freeway, side roads, take the subway. Will you use multiple paths, or do you want to limit it to one?
  • This is a good place to bring up query security again, who needs access to the joint tables in query? HCM- Identify campus users needing access into HCM for HCM’s approval, and HCM employees that need CS specific pages.
  • Points- less intimidating to users coming into the system Focus the attention on the pages that matter Remember, these pages aren’t gone forever (big fear of some users) they can always view them and play with them in Demo, and they can be added back into the mix in the future if needed Query- Set up a “all access” node on the tree for records that all modules will need access to
  • Security decisions- parameters mandated by policy (separation of duties, masking, no correct history, no generic userid’s, no multiple userid’s for any user)
  • Have the teams start on their modules security mapping first, as the security person can start building this while getting approvals for the “shopping lists” By handling the cross module pages this way, you can get approvals, suggestions for better pages, or in some cases decisions for no access to the requested pages, as well as people may realize that they also need access to a page another team is requesting
  • Schedule down time to refresh cache as this will be required once in a while. If it is scheduled, less impact to users. If you can get security tested prior to SIT or UAT, great
  • Determine ahead of time when the “god access: ID’s get locked in testing process, and production security becomes the name of the game.
  • Differentiate go to from earlier slide from modules go to person
  • Function- less personal, more flexible, less maintenance- pages exist in only 1-3 pemission lists, depending on the level of access needed Roles- less thought, less permission lists, more work to maintain the PL’s as pages may exist in many more PL’s during an upgrade, patch, update

Implementing Security Cs Ps Implementing Security Cs Ps Presentation Transcript

  • 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 <Insert Picture Here> 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?
    <Insert Picture Here>
    • 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
  • Decisions, Decisions
    • 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
  • Decisions, Decisions
    • 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
  • Design Non-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
    Design Production 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
    Design Production Security
  • Design Production Security
  • 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
  • Questions?
    • Contact us:
      • John Thompson-Haas – [email_address]
      • Denise Goin – [email_address]
    • For a copy of this presentation contact us at: [email_address]
    • Please complete the survey at: