2. 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

3. October 2001 Tidemark User's Conference2 TIDEMARK SECURITY Concerns, Issues and Setup;.. with restricted and view only fields THE GOO D THE BAD & THE UGLY - or-

4. October 2001 Tidemark User's Conference3 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 dont feel you need it..Then you probably dont need to be here.

5. October 2001 Tidemark User's Conference4 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.

6. October 2001 Tidemark User's Conference5 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. This includes: Activities Fees Case information Parcel information People information Valuation information

7. October 2001 Tidemark User's Conference6 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.

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

9. October 2001 Tidemark User's Conference8 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.

10. October 2001 Tidemark User's Conference9 TIDEMARK SECURITY THE GOOD: 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 ). Capabilities

11. October 2001 Tidemark User's Conference10 TIDEMARK SECURITY THE BAD: Does not provide case-level security. (But didnt 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. Incapabilities

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

13. October 2001 Tidemark User's Conference12 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)?

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

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

16. October 2001 Tidemark User's Conference15 TIDEMARK SECURITY The Good: 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 Beginning the setup

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

18. October 2001 Tidemark User's Conference17 TIDEMARK SECURITY 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. The Good : What youve done already

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

20. October 2001 Tidemark User's Conference19 TIDEMARK SECURITY THE BAD: 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. What you havent done

21. October 2001 Tidemark User's Conference20 TIDEMARK SECURITY THE BAD: You have probably given users authority to do more than they need to / you want them to. Youre relying on ignorance security What they dont know, they wont try… What this means

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

23. October 2001 Tidemark User's Conference22 TIDEMARK SECURITY THE BAD: 1.Forward your phone to voicemail. 2.Unvolunteer from any committees youre on. 3.Lock your door, or seal yourself in your cubicle with additional walls. 4.Inform your family youll miss dinner for the next, oh month or so. 5.Open Tidemark Utilities and go to… Are you sure????

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

25. October 2001 Tidemark User's Conference24 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.

26. October 2001 Tidemark User's Conference25 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.

27. October 2001 Tidemark User's Conference26 TIDEMARK SECURITY THE UGLY: Restricted field table Whats 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.

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

29. October 2001 Tidemark User's Conference28 TIDEMARK SECURITY THE UGLY: Good side, Bad side Good news:Bad news: Youve restricted access to important fields to only those who need them. Youve already completed 10,000 entries or more! You probably want others to be able to see the info thats been restricted. You havent yet secured activities. You have, oh, 15,000 more entries to go….

30. October 2001 Tidemark User's Conference29 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.

31. October 2001 Tidemark User's Conference30 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. Again, this means: Entering the field / department combos & creating another 10,000 entries…. There is a small trick using linked files & MS Access.

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

33. October 2001 Tidemark User's Conference32 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.

34. October 2001 Tidemark User's Conference33 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 Table. Like the R.F. and V.P. tables, individual activities must be associated with each group separately. Also, once an activity has been placed in the table, it becomes blocked to every group not included.

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

36. October 2001 Tidemark User's Conference35 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.

37. October 2001 Tidemark User's Conference36 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.

38. October 2001 Tidemark User's Conference37 TIDEMARK SECURITY Summary to this point By completing these steps, you have not 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

39. October 2001 Tidemark User's Conference38 TIDEMARK SECURITY Summary to this point By completing these steps, you have not 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.

40. October 2001 Tidemark User's Conference39 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?

41. October 2001 Tidemark User's Conference40 TIDEMARK SECURITY GOO D LUC K