Session: Security Concerns, Issues and Setup (or the Good, the Bad and the Ugly)

1. Session: Security Concerns, Issues and Setup (or the Good, the Bad and the Ugly) Panelist: Mike Neely, City of Pasadena Date: Wednesday October 3, 2001

2. TIDEMARK SECURITYConcerns, Issues and Setup;..with restricted and view only fields -or- THE GOOD THE BAD & THE UGLY October 2001 Tidemark User's Conference

3. TIDEMARK SECURITY Should you be here? If you: • Have set up security at your organization using Restricted Field and View Only tables, • Are happy with your current Tidemark security set up, or • Have no security installed, but don’t feel you need it ..Then you probably don’t need to be here. October 2001 Tidemark User's Conference

4. TIDEMARK SECURITY What is it? For the purpose of this session security is the restriction or limiting of the users ability to perform functions (view, add, edit or delete) on the Tidemark system. October 2001 Tidemark User's Conference

5. TIDEMARK SECURITY What is it? • This includes: • Activities • Fees • Case information • Parcel information • People information • Valuation information For the purpose of this session security is the restriction or limiting of the users ability to perform functions (view, add, edit or delete) on the Tidemark system. October 2001 Tidemark User's Conference

6. TIDEMARK SECURITY What will we cover? This session will explore: • The initial stages of implementing Tidemark security. • Assignment of access levels. • The use of Restricted Field and View Privilege tables. • The Activity Department table (–vs- Activity User) table. • …and a group discussion following the presentation. October 2001 Tidemark User's Conference

7. TIDEMARK SECURITY THE GOOD: Why use it? • Security aids in automating your business/ government rules. • Security can impact data quality. • -Increases reporting validity. • -Saves YOU time. • Can avert potential disasters. October 2001 Tidemark User's Conference

8. TIDEMARK SECURITY THE GOOD:Why use it? • For auditing purposes. • -Almost all government agencies are required to submit to audits. • -Provides accountability • For legal purposes. • -Information from Tidemark is sometimes used as evidence; eg. code violations, etc. • -Information will be scrutinized. October 2001 Tidemark User's Conference

9. TIDEMARK SECURITY THE GOOD: Capabilities • Can authorize/prevent users’ ability to add, edit and delete certain functions on cases. • Can restrict users from viewing/editing specific fields on case screens. • Can provide varying security levels between casetypes……….(see UGLY). October 2001 Tidemark User's Conference

10. TIDEMARK SECURITY Incapabilities THE BAD: • Does not provide case-level security. (But didn’t I just say….) • If a user can add/delete an activity or fee for one type of case, he/she can do the same for any case (and probably much more…) • Requires a lot of effort and hours to create and maintain a reasonably thorough system. October 2001 Tidemark User's Conference

11. TIDEMARK SECURITY THE GOOD: Preparing for setup • Gather ALL users, departments or reps. who will be using the system. • Group them into logical units (depts., positions, etc.) October 2001 Tidemark User's Conference

12. TIDEMARK SECURITY THE GOOD:Preparing for setup • Discussion: • “What do you need to be able to do on the system (or, what do you do)?” October 2001 Tidemark User's Conference

13. TIDEMARK SECURITY The Good: Preparing for setup Determine what types of data to secure: For instance, Pasadena was concerned with: • Case screen information • Case activity information • Parcel data • People data • Fee data • Valuation data October 2001 Tidemark User's Conference

14. TIDEMARK SECURITY The Good: Recommendation: It is useful to create a matrix similar to this: October 2001 Tidemark User's Conference

15. TIDEMARK SECURITY The Good: Beginning the setup The Access Level table: • All functions are assigned to a level • Initially, all levels set to 30 JOB #1: Assign all functions to varying access levels based on the organizational authority required for the task October 2001 Tidemark User's Conference

16. TIDEMARK SECURITY The Good: Assigning Levels to Roles October 2001 Tidemark User's Conference

17. TIDEMARK SECURITY The Good:What you’ve done already What have you done at this point? • Identified and ranked functions performed by your organization. • Grouped users according to their functions and authority/level of importance. October 2001 Tidemark User's Conference

18. TIDEMARK SECURITY THE GOOD:What you’ve done already How does this help me? • Have a good understanding of the who, how when and why of organization’s activities. • Your system now reflects more of your business rules. • You already have a functional level of security. October 2001 Tidemark User's Conference

19. TIDEMARK SECURITY THE BAD: What you haven’t done • As it stands, no case-level security. • If you can add/edit/delete on one casetype, you can do it to all types. • This holds true for case screen information and case activity information. October 2001 Tidemark User's Conference

20. TIDEMARK SECURITY THE BAD: What this means • You have probably given users authority to do more than they need to / you want them to. • You’re relying on “ignorance security” • What they don’t know, they won’t try… October 2001 Tidemark User's Conference

21. TIDEMARK SECURITY THE BAD: Case-Level Security? • If you really want to provide some degree of case-specific security, it can be done. • How? October 2001 Tidemark User's Conference

22. TIDEMARK SECURITY THE BAD: Are you sure???? • Forward your phone to voicemail. • ‘Unvolunteer’ from any committees you’re on. • Lock your door, or seal yourself in your cubicle with additional walls. • Inform your family you’ll miss dinner for the next, oh month or so. • Open Tidemark Utilities and go to… October 2001 Tidemark User's Conference

23. TIDEMARK SECURITY THE UGLY: Restricted field and View privilege Tables October 2001 Tidemark User's Conference

24. TIDEMARK SECURITY THE UGLY: Restricted field and View privilege Tables What are they? • Allow you to prevent the viewing and editing of fields on any screen. • Allow you to give combinations of permissions to users in different departments/groups. • Allow you to create a certain degree of case-specific security levels in Tidemark. October 2001 Tidemark User's Conference

25. TIDEMARK SECURITY THE UGLY: Restricted field table How it works: • Any field on any case screen can be blocked to any user. • Once restricted to certain users, the field becomes blank all others. October 2001 Tidemark User's Conference

26. TIDEMARK SECURITY THE UGLY: Restricted field table What’s so hard? • Entries in the Restricted Field Table actually give permissions. • By placing placing a field/department combination in the table just once, it becomes restricted to everyone else until you make a similar entry using their group. October 2001 Tidemark User's Conference

27. TIDEMARK SECURITY THE UGLY: Restricted field table What does this mean? Hours… & Hours… & Hours… & Hours… & Hours… & Hours… & Hours… & Hours… October 2001 Tidemark User's Conference

28. TIDEMARK SECURITY THE UGLY: Good side, Bad side Good news: Bad news: • You’ve restricted access to ‘important’ fields to only those who need them. • You’ve already completed 10,000 entries or more! • You probably want others to be able to see the info that’s been restricted. • You haven’t yet secured activities. • You have, oh, 15,000 more entries to go…. October 2001 Tidemark User's Conference

29. TIDEMARK SECURITY THE UGLY: View privilege table What does it do? • Restricted fields are blank. • To make the field view-only, it must be added to the View Privilege Table. October 2001 Tidemark User's Conference

30. TIDEMARK SECURITY THE UGLY: View privilege table What does it do? Again, this means: • Restricted fields are blank. • Entering the field / department combos • To make the field view-only, it must be added to the View Privilege Table. • & creating another 10,000 entries…. • There is a small trick using linked files & MS Access. October 2001 Tidemark User's Conference

31. TIDEMARK SECURITY THE UGLY: A helpful trick… Try a linked table in MSAccess By linking to the restricted / view tables, you can use Microsoft’s copy command to create new entries… much more efficient! October 2001 Tidemark User's Conference

32. TIDEMARK SECURITY THE UGLY: Restricting Activities Activities can be restricted also ..to a degree • Groups can be prevented from ‘signing-off’ specific activities. • This is done via the Activity Department or Activity User table. October 2001 Tidemark User's Conference

33. TIDEMARK SECURITY THE UGLY: Restricting Activities Activities can be restricted also ..to a degree • Like the R.F. and V.P. tables, individual activities must be associated with each group separately. • Groups can be prevented from ‘signing-off’ specific activities. • This is done via the Activity Department Table. • Also, once an activity has been placed in the table, it becomes blocked to every group not included. October 2001 Tidemark User's Conference

34. TIDEMARK SECURITY THE UGLY: Good side, Bad side You Have: You Have Not: • Restricted the signing off of activities based on department or group. • Why signing off? • Added any restrictions concerning the addition or deletion of fees… • Those permissions are still based on the access level table. October 2001 Tidemark User's Conference

35. TIDEMARK SECURITY Summary to this point By completing these steps, you have: • Established access levels defined by data sensitivity. • Created role/department-based groups and assigned them specific access levels. • Restricted viewing and editing specific fields to specific groups or users. • Restricted signing off of specific activities to specific groups or users. October 2001 Tidemark User's Conference

36. TIDEMARK SECURITY Summary to this point By completing these steps, you have: • Established access levels defined by data sensitivity. • Created role/department-based groups and assigned them specific access levels. • Restricted viewing and editing specific fields to specific groups or users. • Restricted signing off of specific activities to specific groups or users. You do have a functional level of security. October 2001 Tidemark User's Conference

37. TIDEMARK SECURITY Summary to this point not By completing these steps, you have • Created user-specific access to activities. • Implemented true case-specific security. • Prevented users from adding/deleting cases, activities & fees for casetypes other than their own. • Utilized Security Groups • Prevented database access via other programs October 2001 Tidemark User's Conference

38. TIDEMARK SECURITY Summary to this point not By completing these steps, you have • Created user-specific access to tasks. • Implemented true case-specific security. • Prevented users from adding/deleting cases, activities & fees for casetypes other than their own. • Utilized Security Groups • Prevented database access via other programs Still have to rely upon “ignorance security”. October 2001 Tidemark User's Conference

39. TIDEMARK SECURITY Discussion: Where do we go from here? • Has anyone used Security Groups? • Is there a way to allow specific users access to individual tasks (take the Access Level to the next step)? • Can we restrict ability to run sensitive reports? October 2001 Tidemark User's Conference

40. TIDEMARK SECURITY GOOD LUCK October 2001 Tidemark User's Conference